Semantic Web

Fingerpoint

Buzzword.org.uk Draft 22 August 2009

This version:
http://buzzword.org.uk/2009/fingerpoint/spec-20090822
Latest version:
http://buzzword.org.uk/2009/fingerpoint/spec
Editor:
Toby Inkster

Abstract

Fingerpoint is a protocol allowing people to associate data (such as their name, homepage link, etc) with their e-mail address, and allowing third parties to discover that information. It is similar in spirit to the finger protocol and the webfinger project.

Status of this Document

This document is published by buzzword.org.uk, a web site that hosts various specifications, articles and tools of use to web publishers. This is not a W3C recommendation. It is not even a buzzword.org.uk recommendation yet.

The author welcomes feedback on this draft by e-mail to [email protected].

Licence

This document is available under a licence which allows the creation of derivative works under certain conditions. For the purpose of licensing, implementations of the ideas considered in this specification shall not be considered derivative works.

Table of Contents

  1. 1 Publishing Data
    1. 1.1 Mailbox Addresses Usable with Fingerpoint
  2. 2 Discovering the SPARQL Endpoint from an E-mail Address
    1. 2.1 Discovery via HTTP Link
    2. 2.2 Discovery via HTML <link/>
  3. 3 Querying the SPARQL Endpoint
  4. Appendix A: References
  5. Appendix B: Implementations
    1. Clients
    2. Service Providers

1 Publishing Data

The data a person wishes to share is published to a triple store that exposes a public SPARQL Protocol endpoint (see [SPARQL]). This data must contain at least a foaf:mbox or foaf:mbox_sha1sum predicate, as defined by [FOAF].

That is, assuming that the e-mail address the data is to be associated with is [email protected] then at least one of the following two triples must be included in the data:

<WEBID> foaf:mbox <mailto:[email protected]> .
<WEBID> foaf:mbox_sha1sum "9bbb06b3bb947843d3ee37048284926bbebfe8b5" .

1.1 Mailbox Addresses Usable with Fingerpoint

The use of an e-mail address to identify a person for the Fingerpoint protocol does not necessarily imply that the address may be used to send e-mail via SMTP to that person. The address is used as an arbitrary identifier, however people choosing identifiers that are not their e-mail addresses must ensure that the identifier is not, and could not be, somebody else's e-mail address.

That is, Joe can use [email protected] only after ensuring (by checking with the example.com domain owner) that there is not a person with the e-mail address [email protected] and never will be (assuming a reasonable definition of "never").

It is recommended that if an identifier is not usable for sending e-mail via SMTP, then only a foaf:mbox_sha1sum is provided in the data, not a foaf:mbox.

2 Discovering the SPARQL Endpoint from an E-mail Address

To locate the SPARQL endpoint from an e-mail address, a convention needs to be applied. The host name of the e-mail address is extracted, and an HTTP request is made for the root URL at that host. In the previous example, the HTTP request would be made to http://example.com/.

Clients hoping to find the SPARQL endpoint(s) associated with that domain should look for HTML <link> elements or HTTP Link headers with a rel attribute with value http://ontologi.es/sparql#fingerpoint — this relationship value is defined by [ENDPOINT-DISCOVERY]. They can then follow those links to the SPARQL endpoints (which may be on a different host) and query the endpoints for the data they were looking for.

2.1 Discovery via HTTP Link

HTTP Link headers must be formatted according to [HTTP-LINK] and include a rel value of http://ontologi.es/sparql#fingerpoint.

An example HTTP Link header that satisfies this requirement is:

Link: <http://example.net/sparql>; rel="http://ontologi.es/sparql#fingerpoint"

Another is:

Link: <http://sparql.org/sparql?default-graph-uri=http://example.net/data.rdf>;
    title="Public SPARQL Service"; rel="http://ontologi.es/sparql#fingerpoint"

Note that the latter includes a query string. Implementations must be careful to preserve the query string.

2.2 Discovery via HTML <link/>

In order that client implementations do not have to include full HTML or XML parsers, discovery via <link/> elements is performed via a simple regular expression match. Clients must attempt to match the following case-sensitive regular expression:

<[Ll][Ii][Nn][Kk]\s*[Rr][Ee][Ll]="[^"]+http://ontologi\.es/sparql#fingerpoint[^"]+"\s*[Hh][Rr][Ee][Ff]="([^"]+)"\s*/?>

The matched subexpression represents the discovered link. Clients must not use any other mechanism (e.g. parsing HTML and inspecting the DOM; parsing as RDFa) to extract the link.

In particular, this will match the following fragments of (X)HTML, which are what people wishing to publish Fingerpoint data are recommended to use:

<link rel="http://ontologi.es/sparql#fingerpoint" href="URL" />
<link rel="http://ontologi.es/sparql#fingerpoint" href="URL">

3 Querying the SPARQL Endpoint

Once the address of the SPARQL endpoint has been discovered, it can be queried. Consumers should make sure to check for data, not just by mbox, but also by mbox_sha1sum. An example query is:

SELECT DISTINCT ?person
WHERE {
	{ ?person <http://xmlns.com/foaf/0.1/mbox> <mailto:[email protected]> . }
	UNION
	{ ?person <http://xmlns.com/foaf/0.1/mbox_sha1sum> "9bbb06b3bb947843d3ee37048284926bbebfe8b5" . }
}

Appendix A: References

ENDPOINT-DISCOVERY
SPARQL Endpoint Discovery Terms, Toby Inkster. <http://ontologi.es/sparql#>.
FOAF
FOAF Vocabulary Specification 0.91, Dan Brickley and Libby Miller, Namespace Document 2 November 2007. <http://xmlns.com/foaf/spec/20071002.html>. Latest version: <http://"http://xmlns.com/foaf/spec/>.
Web Linking, Mark Nottingham. <http://www.mnot.net/drafts/draft-nottingham-http-link-header-07.txt>.
SPARQL
SPARQL Protocol for RDF, Kendall Grant Clark, Lee Feigenbaum and Elias Torres, W3C Recommendation 15 January 2008. <http://www.w3.org/TR/2008/REC-rdf-sparql-protocol-20080115/>. Latest version: <http://www.w3.org/TR/rdf-sparql-protocol/>.

Appendix B: Implementations

Clients

Service Providers