[rdfweb-dev] Re: Syntactic profiling (FOAF document formats)
Julian Bond
julian_bond at voidstar.com
Thu Aug 28 07:38:04 UTC 2003
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
More information about the foaf-dev
mailing list