19:10If all you had was an email address, would it not be nice to be able to have a mechanism to find someone's home page or OpenId from it? Two proposals have been put forward to show how this could be done. I will look at them and add a sketch of my own that hopefully should lead us to a solution that takes the best of both proposals.
The explains what webfinger is very well:
Back in the day you could, given somebody's UNIX account (email address), type
$ finger email@example.com
and get some information about that person, whatever they wanted to share: perhaps their office location, phone number, URL, current activities, etc.
The new ideas generalize this to the web, by following a very simple insight: If you have an email address like henry.story@sun.com, then the owner of sun.com is responsible for managing the email. That is the same organization responsible for managing the web site So all that is needed is some machine readable pointer from to a lookup giving more information about owner of the email address. That's it!
The WebFinger proposal
The WebFinger proposed solution showed the way so I will start from here. It is not too complicated, at least as described by "" post.
John suggests that there should be a convention that servers have a file in the root location of the HTTP server to describe metadata about the site. (This seems to me to break web architecture. But never mind: the resource can have a link to some file that describes a mapping from email ids to information about it.) The WebFinger solution is to have that resource be in a new file format. (not xml btw). This would have mapping of the form
Link-Pattern: < >;
rel="describedby";type=" application/xrd+xml"
So if you wanted to find out about me, you'd be able to do a simple HTTP GET request on , which will return a representation in another new format about the user.
The idea is really good, but it has three more or less important flaws:
- It seems to require by convention all web sites to set up a /host-meta location on their web servers. Making such a global requirement seems a bit strong, and does not in my opinion follow web architecture. It is not up to a spec to describe the meaning of URIs, especially those belonging to other people.
- It seems to require a non xml application/host-meta format
- It creates yet another file format to describe resources the application/xrd+xml. It is better to describe resources at a semantic level using the Resouces Description Framework, and not enter the format battle zone. To describe people there is already the widely known ontology, which can be clearly extended by anyone. Luckily it would be easy for the XRD format to participate in this, by simply creating a mapping to the semantics.
- It seems to require a non xml application/host-meta format
All these new format creation's are a real pain. They require new parsers, testing of the spec, mapping to semantics, etc... There is no reason to do this anymore, it is a solved problem.
But lots of kudos for the good idea!
The FingerPoint proposal
, co inventor of , authored the , which avoids the problems outlined above.
Fingerpoint defines one useful relation relation (available at the namespace of the relation of course, as all good linked data should), and is defined as
sparql:fingerpoint
a owl:ObjectProperty ;
rdfs:label "fingerpoint" ;
rdfs:comment """A link from a Root Document to an Endpoint Document
capable of returning information about people having
e-mail addresses at the associated domain.""" ;
rdfs:subPropertyOf sparql:endpoint ;
rdfs:domain sparql:RootDocument .
It is then possible to have the root page link to a SPARQL endpoint that can be used to query very flexibily for information. Because the link is defined semantically there are a number of ways to point to the sparql endpoint:
- Using the up and coming HTTP header,
- Using the well tried html < link > element.
- Using RDFa embedded in the html of the page
- By having the home page return any other represenation that may be popular or not, such as rdf/xml, N3, or XRD...
Toby does not mention those last two options in his spec, but the beauty of defining things semantically is that one is open to such possibilities from the start.
So Toby gets more power as the WebFinger proposal, by only inventing 1 new relation! All the rest is already defined by existing standards.
The only problem one can see with this is that , though not that difficult to learn, is perhaps a bit too powerful for what is needed. You can really ask anything of a SPARQL endpoint!
A possible intermediary proposal: semantic forms
What is really going on here? Let us think in simple HTML terms, and forget about machine readable data a bit. If this were done for a human being, what we really would want is a page that looks like the site, which currently is just one query box and a search button (just like Google's front page). Let me reproduce this here:
Look Up
Here is the html for this form as its purest, without styling:
< form action='/lookup' method='GET' >
< img src='' / >
< input name='email' type='text' value='' / >
< button type='submit' value='Look Up' >Look Up< /button >
< /form >
What we want is some way to make it clear to a robot, that the above form somehow maps into the following SPARQL query:
PREFIX foaf: < >
SELECT ?homepage
WHERE {
[] foaf:mbox ?email;
foaf:homepage ?homepage
}
Perhaps this could be done with something as simple as an RDFa extension such as:
< form action='/lookup' method='GET' >
< img src='' / >
< input name='email' type='text' value='' / >
< button type='submit' value='homepage'
sparql='PREFIX foaf: < >
GET ?homepage
WHERE {
[] foaf:mbox ?email;
foaf:homepage ?homepage
}" >Look Up< /button >
< /form >
When the user (or robot) presses the form, the page he ends up on is the result of the SPARQL query where the values of the form variables have been replaced by the identically named variables in the SPARQL query. So if I entered henry.story@sun.com in the form, I would end up on the page
, which could perhaps just be a redirect to this blog page... This would then be the answer to the SPARQL query
PREFIX foaf: < >
SELECT ?homepage
WHERE {
[] foaf:mbox "henry.story@bblfish.net";
foaf:homepage ?homepage
}
(note: that would be wrong as far as the definition of foaf:mbox goes, which relates a person to an mbox, not a string... but let us pass on this detail for the moment)
Here we would be defining a new GET method in SPARQL, which find the type of web page that the post would end up landing on: namely a page that is the homepage of whoever's email address we have.
The nice thing about this is that as with Toby Inkster's proposal we would only need one new relation from the home page to such a finder page, and once such a sparql form mapping mechanism is defined, it could be used in many other ways too, so that it would make sense for people to learn it. For example it could be useful to make web sites available to shopping agents, as I had started thinking about in before RDFa was out.
But most of all, something along these lines, would allow services to have a very simple CGI to answer such a query, without needing to invest in a full blown SPARQL query engine. At the same time it makes the mapping to the semantics of the form very clear. Perhaps someone has a solution to do this already. Perhaps there is a better way of doing it. But it is along these lines that I would be looking for a solution...
(See also an earlier post of mine )
How this relates to OpenId and foaf+ssl
One of the key use cases for such a Web Finger comes from the difficulty people have of thinking of URLs as identifiers of people. Such a WebFinger proposal if successful, would allow people to type in their email address into an OpenId login box, and from there the Relying Party (the server that the user wants to log into), could find their homepage (usually the same as their OpenId page), and from there find their FOAF description (see "").
Of course this user interface problem does not come up with , because by using client side certificates, foaf+ssl does not require the user to remember his . The browser does that for him - it's built in.
Nevertheless it is good that OpenId is creating the need for such a service. It is a good idea, and could be very useful even for foaf+ssl, but for different reasons: making it easy to help people find someone's foaf file from the email address could have many very neat applications, if only for enhancing email clients in interesting new ways.
Updates
It was remarked in the comments to this post that the format for the /host-meta format is now XRD. So that removes one criticism of the first proposal. I wonder how flexible XRD is now. Can it express everything RDF/XML can? Does it have a GRDDL?