[rdfweb-dev] Re: Syntactic profiling (FOAF document formats)

[Julian Bond]

Jim Ley <jim at jibbering.com> wrote:
>"Julian Bond" <julian_bond at voidstar.com>
>> Dan Brickley <danbri at w3.org> wrote:
>> >  * "classic" FOAF files
>>
>> As is probably clear, this is the one I'm interested in.
>
>I think Classic should be the genuine RDF any extensions approach, that's
>the classical, the limited syntax one, is certainly new.

I had to guess which was the closest of Danbri's suggestions. Purely on 
a statistical basis of most widespread current usage, "Classic" seemed 
to be the One file - One person model. If you want to call it something 
else and use Classic for the generalized RDF model, feel free. Just as 
long as we all talk roughly about the same thing.

>> - Only one main Person with Person as a top level node
>> - This Person must have:-
>>    - at least one of mbox or mbox_sha1sum.
>
>This may be acceptable, but I don't like it much, it means unless I have an
>email address I can't exist, even publishing a genuine sha1sum allows people
>to confirm my identity given an email address, people may not want that, but
>they may be happy to give their homepage say (which has contact methods on
>it.)

>>  This should only be used in
>>      the form of Digital ID currently used in foaf
>
>I'm not sure I understand this, could you clarify?

It seems essential to me that there is some form of Digital ID that is 
consistent across FOAF files produced by different people/systems. This 
is so aggregators have some hope of relating information from multiple 
places. I think we all understand that mbox_sha1sum (and mbox) is flawed 
for the reasons you give but I'll maintain that it is good enough. I 
haven't seen any other approach that is as widely available, as easy to 
understand or as simple for a soft Digital ID.

I do feel though that if mbox is restricted to the meaning in the spec, 
then there is a need for a more general foaf:email to handle the edge 
cases where the email address is not a static inverse functional 
property of the Person.

>>    - This Person is assumed to be the author/owner of the data unless
>>      otherwise stated.
>
>I don't think we can have any assumptions at all, certainly not ones like
>this,  the author of the data is a key plank of authenticating who says
>what, and removing lies etc.  Assuming anything about that simply is not
>appropriate.   We need more simple methods than GPG perhaps and everything
>that goes with it, but I can't see assumptions getting us anywhere assuming
>things will fall down even against the forgetful, let alone the liars (which
>nothing like this will defeat)

Again, you're right from a purist point of view. But again, I'll 
maintain that if files only have a single top level Person and we 
actively discourage the publication of hearsay about the other Persons 
in the file then this assumption is good enough. If every file in this 
model included a <foaf:made rdf:resource="" /> against the primary 
person, then we're stating this assumption more explicitly. This is no 
defence against liars but is a bit more RDF friendly than making XML 
assumptions. To be honest I'm much more concerned about aggregators 
being able to show the source of the data than preventing abuse with 
technology.

>You also must allow for the markup to indicate that the foaf is signed and
>the location of the key etc.

We have to accept that if this model gets widespread adoption then the 
vast majority of people being described will not have a clue how to sign 
the file.

>> I don't feel the need to move away from striped RDF-XML. What I do feel
>> the need for (within this use case) is consistency.
>
>As I think everyone knows, I see no point in a restricted syntax, I see it's
>useful to require certain properties where possible, and limiting certain
>things for social reasons (not publishing mbox without consent, include
>foaf:name etc.)  but  to me a simple syntax will just let people create
>tools which will quickly not interop with other systems so the authors will
>be progressing onto real RDF parsers quickly.   I don't see the point of the
>broken middle step, I'd rather spend my time helping the person work with an
>RDF Parser from the word go.

I've made the same point as a downside. I *do not* want to come up with 
a format or model that breaks RDF, so anything of this form should still 
be easily parsable by an RDF parser. Logically there are likely to be 
fewer people writing read apps of this data than write apps and much 
fewer write apps than instances of data. So that's relatively few people 
who need to be educated.

As a counterpoint though take RSS 1.0. This is RDF. It quite often 
contains properties from other vocabularies. You really ought to use an 
RDF parser to read it. But I can extract the information I want out of 
it and ignore the additional information using 4 or 5 Regex statements 
or any one of 20 or so libraries written in a mish mash of regex, sgml, 
xml parsers. And I can use the exact same code to read similar data from 
4 other related pure XML standards. I want to get similar ease of 
parsing and hence similarly wide adoption of a superset of FOAF. I think 
it's possible to do this partly because the output of Ecademy, Typepad 
and Foaf-a-matic is so close to already having this profile.

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