> Seems like it would be isomorphic to a SPARQL query like:
>
> @prefix : <http://xmlns.com/foaf/0.1/> .
>
> SELECT ?profile WHERE {
>
> ?person :mbox "mailto:joe.l...@example.com" .
> ?profile a :PersonalProfileDocument ;
> :primaryTopic ?person .
> }
>
> Which suggests implementation would be pretty easy as a little wrapper
> on any online RDF store which contains relevant data.
Indeed, but more to the point, once you've got the e-mail address and
a SPARQL endpoint, why do you need to even find the profile document?
Just ask the SPARQL endpoint for the data you actually want. e.g. you
want to find their name and homepage:
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?name ?homepage
WHERE {
?person foaf:mbox <mailto:joe.l...@example.com> ;
foaf:name ?name ;
foaf:homepage ?homepage .
}
The sticking point is figuring out which SPARQL endpoint to query.
This could be as simple as finding the host name from the e-mail
address and doing an HTTP request:
HEAD / HTTP/1.1
Host: example.com
Then looking for a response:
HTTP/1.1 200 OK
Content-Type: text/html
Link: </employee-data>; rel="http://xmlns.com/foaf/0.1/fingerpoint"
(Assuming that FOAF defined a term "fingerpoint" which pointed from a
host's root document to a SPARQL endpoint that could be used to find
data about employees.)
I've just implemented this for my own domain experimentally. Given
that I already had a SPARQL endpoint, it took roughly 30 seconds to
implement.
--
Toby A Inkster
<mailto:ma...@tobyinkster.co.uk>
<http://tobyinkster.co.uk>
On 15 Aug 2009, at 11:02, Danny Ayers wrote:
> Interesting, and with some support from Google -
> [[
> WebFinger, aka Personal Web Discovery.
>
> i.e. We're bringing back the finger protocol, but using HTTP this
> time.
> ]]
> http://code.google.com/p/webfinger/
>
> Seems like it would be isomorphic to a SPARQL query like:
>
> @prefix : <http://xmlns.com/foaf/0.1/> .
>
> SELECT ?profile WHERE {
>
> ?person :mbox "mailto:joe.l...@example.com" .
> ?profile a :PersonalProfileDocument ;
> :primaryTopic ?person .
> }
This is not quite isomorphic. Using this approach, there is nothing
that stops anyone from associating http://evil-site.com/ with danny...@gmail.com
.
In the WebFinger proposal, only the admin of gmail.com gets to make
the association (but can delegate the power via an appropriate
system). So it's not easily gamed.
I think that's crucial to making the system worthwhile.
Best,
Richard
>
> Which suggests implementation would be pretty easy as a little wrapper
> on any online RDF store which contains relevant data.
>
> - though I guess for performance a more direct mbox -> profile index
> would be desirable (maybe a cache of results to a similar query with
> ?mbox ?profile across multiple stores).
>
> I'm guessing Sindice could easily do this already.
>
> Regarding interface, Brad Fitzpatrick just posted:
> [[
> Given bradf...@gmail.com,
>
> discovery on the host:
> http://gmail.com/.well-known/host-meta
>
> discovery on the email:
> http://www.google.com/s2/webfinger/?q=bradf...@gmail.com
>
> Some readable info in the 'foo' format:
> http://www.google.com/s2/webfinger/?q=bradf...@gmail.com&fmt=foo
> ]]
>
> See also:
> http://www.techcrunch.com/2009/08/14/google-points-at-webfinger-your-gmail-address-could-soon-be-your-id/
>
> Cheers,
> Danny.
>
> --
> http://danny.ayers.name
i.e. We're bringing back the finger protocol, but using HTTP this time.
]]
http://code.google.com/p/webfinger/
Seems like it would be isomorphic to a SPARQL query like:
@prefix : <http://xmlns.com/foaf/0.1/> .
SELECT ?profile WHERE {
?person :mbox "mailto:joe.l...@example.com" .
?profile a :PersonalProfileDocument ;
:primaryTopic ?person .
}
Which suggests implementation would be pretty easy as a little wrapper
> rel="http://xmlns.com/foaf/0.1/fingerpoint"
I've changed this to <http://ontologi.es/sparql#fingerpoint> to avoid
minting URIs on danbri's domain name!
> I've just implemented this for my own domain experimentally. Given
> that I already had a SPARQL endpoint, it took roughly 30 seconds to
> implement.
Attached is a quick implementation of the client side in Perl. It
uses the standard Digest::SHA1, JSON, LWP::UserAgent and URI modules
from CPAN, plus an HTTP::Link::Parser module that I threw together
out of old bits of parsing code I had lying around, and is bundled
into the file so you don't need to download it separately.
Excluding the HTTP::Link::Parser module, the script is about 50 lines
of code.
It can be run from the command line like this:
perl SemWebFinger.pl ma...@tobyinkster.co.uk
And returns my WebID, easy-peasy
It's reasonably well-commented so it should just take a little SPARQL
knowledge to hack it into to returning other data about me, like my
name, my weblog URL, etc.
And as I said earlier, all the server needs to do is include this
HTTP header in requests for "/":
Link: </SPARQL_ENDPOINT>; rel="http://ontologi.es/sparql#fingerpoint"
+1
since webfinger also works off JID, you'd probably want a
foaf:jabberID in the UNION
as an aside, you can probably also fish out the foaf:knows from the
SPARQL, which is similar to the "Portable Contacts" concept
>
> --
> Toby A Inkster
> <mailto:ma...@tobyinkster.co.uk>
> <http://tobyinkster.co.uk>
>
>
>
> _______________________________________________
> foaf-protocols mailing list
> foaf-pr...@lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
>
Just to emphasise the point, WebFinger *doesn't* work off JIDs; the
identifier being used is an email-like (and therefore JID-like)
identifier, but in no way implies that any services (e.g., SMTP, XMPP)
are associated and active with the identifier.
We often use email addresses and JIDs without their scheme included,
but WebFinger identifiers don't have a scheme.
b.
Fair point. But given that IDs/profiles are crucial info (we need them
somehow), might it not be possible to put foaf+ssl in the loop for
3rd-party hosts to make it distributed?
Aside - one thing Google Social Graph API does on this front is to look
for consistency: if my homepage claims (with microformat rel=me, or
FOAF) that http://www.youtube.com/user/danbri is mine, and that profile
claims that it's account holder has a homepage of http://danbri.org/ ...
well, they both might be lying still, but it's better than nothing.
Little bits of evidence that can add up usefully when figuring what to
trust. Not sure quite how this thinking fits with WebFinger but it's not
a million miles away either.
I'm still in catchup mode from vacation but this is very interesting.
FOAF's long had a few nods to "finger"-era Internet, I'd love to support
the WebFinger work.
One thing I was thinking was whether they'd looked at DNS for discovery,
along lines of
http://blogs.talis.com/nodalities/2009/04/discovering-sparql.php
http://www.floop.org.uk/eagle/discovering-sparql etc ...
ie. perhaps dns could hold a URI Template that explains how to map
use...@mymail.example.com to
http://profiles.mymail.example.com/users/{userid} ?
Note sure the +/- version with the well known location technique, though...
cheers,
Dan
adding foaf+ssl somewhat defuses the ease of
> implementation argument for the RDF-based solution.
Very true.
With Sindice, we can
> easily generate the results of the SPARQL query above, but we cannot easily
> determine if any of the results are trustworthy or if they are attempts to
> game the system.
But surely that is the nature of the Web... don't think we can rely on
direct provenance, but pointers from other parties should help. e.g. I
might not necessarily trust http://richard.cyganiak.de/foaf.rdf found
via Google, but if my agent came through (say) danbri's foaf, I
probably would trust it.
How we get the machine to make such decisions is another matter.
There's also a time element here, email got successful long before
spam poured a bit of poison into the well. Yet it still functions,
with appropriate workarounds. In the near term at least, tools like
Sindice *will* be reliable for person/profile data. Further on, I
don't see the ideal of everyone self-hosting as a solution, but I'm
sure a solution will emerge, the benefits of putting yourself online
are pretty clear already. The cost may be the ssl dance, or similar.
> One thing I was thinking was whether they'd looked at DNS for discovery,
> along lines of
> http://blogs.talis.com/nodalities/2009/04/discovering-sparql.php
> http://www.floop.org.uk/eagle/discovering-sparql etc ...
>
> ie. perhaps dns could hold a URI Template that explains how to map
> use...@mymail.example.com to
> http://profiles.mymail.example.com/users/{userid} ?
>
> Note sure the +/- version with the well known location technique, though...
Interesting angle, though I can't yet see how it might work for my
Auntie Nora*. Perhaps centralised agencies (a la Google) will be
necessary..?
Cheers,
Danny.
* she's been dead 10 years, so it's not really pressing
--
http://danny.ayers.name
> Interesting angle, though I can't yet see how it might work for my
> Auntie Nora*. Perhaps centralised agencies (a la Google) will be
> necessary..?
Auntie Noras, in this case, are email service providers. Doesn't mean
they'll be delighted to have yet another thing to configure and debug,
of course.
Related - has there been any discussion of use of WebFinger in spam filters?
Dan
http://buzzword.org.uk/2009/fingerpoint/spec
I think it offers the following advantages over Webfinger:
1. Minimal reinvention. Fingerpoint reuses FOAF for descriptions of
people, and reuses the W3C SPARQL Query Language for searching for their
information. It uses Mark Nottingham's Web Linking draft for discovery.
2. Integration with the world of Linked Data.
3. It's very easy to set up a small-scale Fingerpoint service - no
programming knowledge needed!
A basic command-line client for Fingerpoint can be found at:
http://buzzword.org.uk/2009/fingerpoint/FingerpointClient.pl
To run it you type:
FingerpointClient.pl acc...@example.com
To show how easy it is to set up a fingerpoint service, I've set one up
here:
http://fingerpoint.tobyinkster.co.uk/
Note that no fancy .htaccess tricks are required, no PHP, no programming
at all. It can be implemented easily on a cheap host that just serves up
static files. (Though there are scalability advantages if you can run
your own SPARQL endpoint.)
To try it out, install the FingerpointClient.pl client and try fingering
the following identifiers:
m...@fingerpoint.tobyinkster.co.uk
some...@fingerpoint.tobyinkster.co.uk
ma...@tobyinkster.co.uk