[rdfweb-dev] PPD

Morten Frederiksen mof-rdf at mfd-consult.dk
Thu Feb 5 20:53:59 UTC 2004

On Thursday 05 February 2004 10:06, Julian Bond wrote:
> 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.
This seems to me to be two different objectives:
a) Finding "the" FOAF file for a person.
b) Finding out who/what a file is about.

The first seems to me to be a bogus claim, it'd be like asking Google to 
always return only a single result.

The second is arguably more interesting, but I think foaf:topic covers that 

And yes, this issue is at the center of the battlefield between data and 
document views...

It's not like I wouldn't "gain" personally from fixed structures - the FOAF 
Explorer would be much better off!

> 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".
Well, for a few use cases, when viewing FOAF files as standalone documents, 
yes, but not when the purpose is to e.g. display all depictions of a person, 
related projects or interests in common with other people.

I think FOAF is about much more than documents, it's about what those 
documents say.

> 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.
I'm not sure what information is being thrown away?

> 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.
Hmm, I'd hope the library owner would maintain a robots.txt file if visitors 
weren't allowed. As for scutter adjustments, sure, if a specialized scutter 
doesn't find any interesting statements it should stay away (or revisit only 
on occasion), but so far we've only seen general scutters.

> 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.
True, as long as tools (like Typepad) don't make invalid assumptions and 
decisions on behalf of the author.

In any case, as I said, I think the train has left the station, at least in 
the sense that I'm clearly in the minority here. However, it seems the 
discussion has been fruitful in the sense that we've touched upon some 
interesting issues, and if some of my concerns could be addressed by the 
prose accompanying the term definition, I'm pretty sure I can survive the 
addition of the PPD class.

As for the primaryTopic predicate, I am - as you seem to be - still thinking 
foaf:topic is fine, at least for now. Show me examples of documents that 
usefully employs multiple foaf:topics, while needing a way to express a 
primary topic, and we can talk. :)
(On that note, the mere mention of a "thing" in a document could be said to 
imply at least a secondaryTopic predicate...).


More information about the foaf-dev mailing list