[rdfweb-dev] advocating use of rdf:ID / rdf:about attributes onfoaf:Person tags

Julian Bond julian_bond at voidstar.com
Sun Aug 17 16:17:35 UTC 2003


I think we've got some interlocking issues here. I don't think any one 
of them will get resolved until we formally recognise this.

note: any new properties or names are just placeholders for this 
discussion and not necessarily suggestions for spec names.

Jim Ley <jim at jibbering.com> wrote:
>FOAF is a vocabulary, foaf files are something that don't meet everyones use
>cases,

Jim, you've said this several times and I think I understand now. This 
cuts to a fundamental dichotomy about FOAF. One the one hand, FOAF is an 
RDF vocabulary that can be used wherever you use RDF to describe 
something that includes people. There will be many, many use cases for 
this. On the other hand, there is a subset of these where an individual 
file is; mostly foaf, describes a single person, contains links via 
foaf:knows to other people which have links via seeAlso to similar style 
single person files that describe them. However, this second definition 
keeps morphing into the first as you look closer. However again, the 
second definition is important. There are significant numbers of 
instances. It's the one many people think is the *only* approach when 
they first come to FOAF. This use of FOAF is not going away just because 
it's not the only one.

This leads me to think that there is a place for a spec at a layer above 
FOAF RDF specifically to define the second description above. Let's call 
it mFOAF (for metafoaf!). I suspect this is going to be little more than 
a "best practice" document and will probably not contain many additional 
tags. One significant one is some property for pointing at other mFoaf 
files. Let's call it foaf:mFoafSeeAlso. I think the whole idea of a new 
standard's instances containing links to other instances of the new 
standard is extremely powerful for getting early adoption and enabling 
scutters. But I think it's becoming clear that overloading the use of 
rdfs:seeAlso doesn't quite get the job done. Right now people are using 
rdfs:seeAlso in mFoaf mainly as a foaf:mFoafSeeAlso *but not 
exclusively*. The scutter writers are having to code round the 
exceptions. And this issue won't go away as shown by the continuing 
discussion about foaf:foaf.

I think that underlying the seeAlso debate is actually the mFOAF debate. 
As long as mFOAF doesn't formally exist, the use of seeAlso in "rdf 
containing foaf" will be seen to be ambiguous by some of the users of 
foaf. And that's ambiguous in a usage sense not a spec sense.

---------

Then we get to the digital ID issue. For mFOAF to work it is important 
that we have a mechanism to identify that particular foaf fragments 
produced by different people in different files at different times all 
refer to the same real world person. Then we need to have a way for one 
or more of those to be flagged as authoritative because they were 
actually produced by that person as opposed to hearsay produced by some 
other person. This has lead to mbox, mbox_sha1sum, maker, made, pgp 
signing, falsely using XML characteristics and the current debate about 
IDs.

But at the core of this is the Digital ID problem. Despite some of the 
best minds working on it, and despite the huge need, there is still no 
widely accepted digital ID. The closest we have right now for our 
purposes is mbox as defined by the current foaf spec and optionally 
obfuscated by SHA1. A relatively long lived email address, owned by the 
single person that is being described in this foaf fragment. There are 
lots of reasons why this is imperfect and these keep being brought back 
up. This broadly works but where it's going wrong is that we're not 
necessarily defining mbox as a substitute for digital ID. And we're 
still allowing mbox to be used as a general encoding for any old email 
address. And while made and maker go some way to dealing with 
Authoritative, that's not actually what they're saying.

So I think we need two new properties to reflect the actual need for a 
digital id rather than overloading existing properties

- foaf:myID      //some arbitrary but long lived and unchanging Digital 
ID. Typically, a SHA1 encoded email address belonging to the person 
being described only.

- foaf:authority //A flag that says that this data is authoritative. It 
should be used on the main foaf:Person in a mFOAF file. Maybe that is 
actually implied by a file actually being an mFOAF file.

Now the effect of foaf:myID could be done with mbox by introducing 
foaf:email for the general case and tightening recommended practice on 
mbox. What doesn't work for me is that mbox/mbox_sha1sum is used for 
FOAF's digital ID *and* for any and all email addresses I might be 
responsible for.

I recognise there are huge problems with trust surrounding 
foaf:authority. And maybe foaf:made is "good enough". I'm uncomfortable 
with using foaf:maker and foaf:topic because in lots of existing files, 
the whole file is made by one person, but not all the data in it is 
authoritative.

-- 
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