[rdfweb-dev] URI, ID, seeAlso

Julian Bond julian_bond at voidstar.com
Mon Aug 18 07:34:56 UTC 2003

David Madore <david.madore at ens.fr> wrote:
>  * And anyway, the FOAF field experiment clearly points in this
>  direction: if Jim Ley is at once <URL:
>  http://xml.mfd-consult.dk/foaf/morten.rdf#jim > and <URL:
>  http://jibbering.com/foaf.rdf#xpointer(whatever) >, no matter how hard
>  we try to avoid the fact, then isn't it better to recognize the
>  possibility and use/introduce means to deal with it

>  - When writing a FOAF file, always introduce an rdf:ID attribute on
>  every person which this file describes "authoritatively".

I don't like this because I see it as overloading the use of the rdf:ID
for a purpose that it wasn't intended for. I think this is just as wrong
as saying that the first top level node of type Person describes the
file authoritatively.

>Just bringing the subject up to mention that it seems a lot of a mess.
>Certainly we shouldn't trust all of Joe's statements about Jane: Joe's
>foaf.rdf file might say that Jane is an idiot, but we shouldn't
>conclude that Jane is an idiot, only that Joe thinks that Jane is an

All we can conclude is that the rdf file at foo.foo/john/foaf.rdf says
that Jane is an idiot. But if we have a convention for authority, we'd
be able to say that the person described in foo.foo/john/foaf.rdf with
mbox_sha1sum john999, thinks that jane with mbox_sha1sum jane111 and
described by bar.bar/jane/foaf.rdf is an idiot. We're getting close now
to something that is "good enough".

The point here is that foaf *should not be* a solution to trust. But it
should be a good enough representation that we can use it in the real
world to draw some conclusions.

>*** Concerning the use of rdfs:seeAlso

>Surely any kind of doubt should profit the prudent interpretation.
>And the prudent interpretation would be to introduce a foaf:foafFile
>property (with foaf:foafFile rdfs:subPropertyOf rdfs:seeAlso) on a
>foaf:Person, supposedly pointing to an RDF file that describes the
>person in question, and recommend using that property instead of

I said it yesterday but I'll restate it. We don't have agreement on what
a "FOAF file" is. And this despite a large amount of instances in the
wild. Without this agreement it makes no sense to introduce a
foaf:foafFile property that points at "FOAF File"s. If we further
restrict foaf:foafFile that it must describe the Person it's attached to
we're introducing an inference that may not be justified by the file
we're pointing to. We should rather examine the file and see what it

Now again, I'm not actually arguing against you. I think there is a case
for a formal convention for a subset of RDF that contains foaf. Let's
say something like this.

- Only one main Person with Person as a top level node
- This Person must have:-
  - at least one of mbox or mbox_sha1sum. This should only be used in
    the form of Digital ID currently used in foaf
  - Some form of name
  - zero or more knows entries
    - Each knows should have one Person
    - Each of these should have:-
    - At least one mbox_sha1sum
    - They should not have mbox without the specific agreement of this
  - This Person is assumed to be the author/owner of the data unless
    otherwise stated.

Now let's call this mFOAF. I think there should be a reference at the
top of the file that specifically states this. Either similarly to RSS
eg <mfoaf version="0.9" /> or as part of the document section.

If this was created, then there should be an enhanced seeAlso
(mFoafFile) that is equivalent to seeAlso but is only ever used to point
at other mFoafFiles. ie files that conform to mFoaf.


One of the drivers in my thinking here is Scutter approaches. There is
one approach which is to build a huge triple store of every triple you
can find. This store should have the usual subject, predicate, object
but also timestamp when found and source URI. This is doable now but I
would say it's not scalable unless you are doing a Google scale project.

The other approach is to only store the relationships/properties you're
interested in searching, parsing them out at collection time. And then
pointing back to the original source at run time. If this is all based
on the mFOAF use case, then mFoafFile is going to be extremely useful.
And being able to say "Apparently definitive" or "hearsay from X" is
also going to be useful.

Julian Bond Email&MSM: julian.bond at voidstar.com
Webmaster:              http://www.ecademy.com/
Personal WebLog:       http://www.voidstar.com/
M: +44 (0)77 5907 2173   T: +44 (0)192 0412 433

More information about the foaf-dev mailing list