[rdfweb-dev] Which Person wrote this FOAF?
danbri at w3.org
Tue Jul 29 10:53:33 UTC 2003
Julian -- thanks for raising this. It is certainly something that needs
addressing, and has been discussed inconclusively around here before. I
think we've found it difficult to discuss / think about because several
different and related issues collide.
- 'I made this'
- 'this is about me'
- 'this is my foaf file'
- 'this is the foaf file for ...'
- 'this is a FOAF file (and not just some random RDF that uses FOAF
- 'this is PGP-signed by ...'
...are all related but different concepts. We need to decide which are
the crucial assertions to communicate.
In general I agree with Edd's analysis below:
* Edd Dumbill <edd at usefulinc.com> [2003-07-29 11:07+0100]
> On Tue, 2003-07-29 at 10:45, Emmanuil Batsis (Manos) wrote:
> > This probably supports the addition of a foaf:file or something in the
> > place of seeAlso.
> To have such a construct would probably be a bad idea. There will never
> be guaranteed one source of information about anyone -- this is how the
> web works and a fundamental assumption of FOAF -- so to codify such an
> expectation in the vocabulary is either: (a) incorrect, if foaf:file
> implies a 1:1 authoritativeness, or (b) redundant, if you don't imply a
> 1:1 relationship, you don't get any more than seeAlso gives you.
There is a lot to be said for keeping rdfs:seeAlso in there explicitly,
since it provides a basic hook for RDF harvesters to use to traverse
inter-file links without knowledge of any particular schema or RDF
Also yes, it is important to allow that an agent may publish several
different RDF files, each of which could use FOAF to make
self-descriptive claims about the author.
> It's also eminently fakeable. I could start littering the interweb with
> foaf:file statements for somebody else, pointing to files of my own
Yup, in general all of FOAF is vulnerable to lies etc., except when
people bother to use PGP etc to sign their claims so you at least have
an idea who is making them.
> In short: foaf:file would tend to give false assurances that consuming
> software really can't support.
> > It could be used in statements about statements (i.e.
> > to say this info came from Foo's foaf file).
> Well, we can already record the URL we found the information at. If
> there's a foaf:maker or foaf:made property connected to that URL, we can
> record (unverified) author information. And if a verifiable digital
> signature is in place, we can then make a trust decision on that
> information, based on how much we trust the key we have for that person.
I'm wondering how this will turn out for tool-assisted FOAF publication.
For example, Ecademy and TypePad generate FOAF on behalf of the person
described. Firstly, are we happy with the use of foaf:maker as a way
for such FOAF to assert that it is 'from' the person it describes. (I
am); secondly, it is reasonable to expect such services will ever
find a way to allow their users to PGP-sign this content (I'm
> > Other ways of documenting
> > where information came from when merging foaf files could be better as a
> > solution, but in general I agree in the importance of knowing where a
> > particular statement occured. Could be used in constructing weighted
> > graphs based on trust metrics etc.
> I agree on this importance, but it does not necessitate creating
> something like a "foaf:file" term. maker, made and dig sigs can get us
> pretty far on in that.
My take is that the basic facts we want to assert are:
"I made this and it is about me" (backed up by other assurances that
establish that the RDF really was published by its authors; PGP +
>From IRC chat w/ Edd, something like this does the job:
<foaf:Document rdf:about=""> <!-- at the top level of your FOAF file -->
<foaf:topic rdf:nodeID="me"/> <!-- also we'd need this nodeID on the
XML element that describes you -->
</foaf:Document> <!-- "i made this document and it is about me" -->
This is enough to allow an application to look at the claims some RDF
file makes, and find out if there is a Person that both created the
document and is its topic. I think that solves at least 80% of
requirements here; it may be that eventually we need some types for RDF
documents (my booklist RDF file; my stuff-for-sale RDF file; my
bibliogrpahy in RDF file, ...) but we should deal with that when the
need proves itself...
More information about the foaf-dev