julian_bond at voidstar.com
Thu Feb 5 09:06:23 UTC 2004
Morten Frederiksen <mof-rdf at mfd-consult.dk> wrote:
>Call me naïve, but if FOAF as RDF is going to survive, we have to keep
>insisting on the model, not the syntax. By restricting the syntax, we may
>help out a lazy app-developer here and there - on the short term, but it will
>stop the progress towards more RDF - on the long term. We'd essentially be
>doing them (and us) a disfavour.
This is the crux. There's undeniably a need to be able to mark a
specific file as being a reasonably authoritative document about a
single person. That's how 90% of the "FOAF" files out there are
structured at the moment. We circle around this with wot, signing, made,
maker, topic, and now PersonalProfileDocument. And given the lack of an
accepted formal way of saying this, when we write aggregators we jump
through hoops to try and work out which Person is primary. Simply
ignoring the problem (which is what plink does now) plainly doesn't
work. A long list of foaf files for a person that says "This person was
mentioned in these" is interesting but much less use than the very short
list that says "These are this person's profiles".
While I understand the view that this is all a big collection of
metadata that can be queried however you like, that view is throwing
away some useful information.
For me this also points up a problem with seeAlso that it says nothing
about the nature of the target document. I think we should be able to
give a hint to the scutter about whether it's worth spidering into the
link. There's an example real world problem here where a scutter can be
walking round a web of foaf:Person type files and fall into a large
library of photographs with lots of interconnecting links. There's
nothing particularly wrong with this apart from the impact on the
bandwidth of the library owner and the need for the scutter writer to
add more code to make sure it doesn't go back.
I'm not yet convinced that a more restricted form of topic is actually
necessary. But just having it there forces the foaf author to think
about the nature of the foaf file, which may be a good thing.
Julian Bond Email&MSM: julian.bond at voidstar.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