[foaf-dev] Time to make the foaf classes relate to Dublin Core classes?

[Dan Brickley]

Richard Cyganiak wrote:
> Dan,
> 
> On 23 Jan 2008, at 00:13, Dan Brickley wrote:
>> Thanks for raising this. I agree that the two classes have the same 
>> members. Had a chat with Tom Baker earlier too, and we couldn't think 
>> of any example "agents" that these two definitions would disagree 
>> about. The owl:sameAs relation, however, would be too strong, since 
>> the classes are different beasts. They have different history, 
>> provenance and other facts about them.
> 
> That's an interesting point of view. You've stated before that classes 
> and properties are “creative works”. Here you state that classes and 
> properties have history and provenance.
> 
> I don't like this point of view. It violates Occam's razor and muddles a 
> bunch of things.

Simplicity can be subjective :)

> I offer an alternative view here:
> 
> RDFS classes and properties cannot exist without documents describing 
> and defining them. This could be RDFS documents or prose specifications, 
> like the FOAF spec. Thus, the history and provenance of classes and 
> properties can be tracked by looking at the documents. The documents 
> also clearly are creative works.
> 
> Hence, I think it is much simpler, clearer and more natural to ascribe 
> history, provenance and expression of creativity to the documents that 
> define classes and properties; not to the classes and properties itself.

So dc:creator the property existed equally before 1994 as yesterday? 
That's a bit too platonic for my tastes.

> After all, it is clear and undeniable that the FOAF specification is a 
> creative work of yours. It is also undeniable that this specification 
> describes a class, foaf:Person, which contains all people. But do you 
> really want to claim that you are the creator of the class of all people?

Heheh... that's a slippery question!

http://www.w3.org/TR/rdf-mt/#rdfs_interp allows "that (as noted earlier) 
two different class entities could have the same class extension". The 
"earlier"  note (section 1.1) being,

"However, the semantic model given here distinguishes properties and 
classes considered as objects from their extensions - the sets of 
object-value pairs which satisfy the property, or things that are 'in' 
the class".

So you and and I might define classes whose memberships happened to 
entirely coincide, yet they can be different RDF classes. (Some OWL 
systems do things differently, I think.)

So, sure, I'm a creator of a class whose membership is "all people". But 
so is anyone who writes an OWL restriction that picks out those same 
individuals. But it's "a class", not "the class".

> As I see it, this class has always existed “out there”, and the 
> contribution of you and the DC folks is that you've described this 
> existing class with a certain level of formality, and given it a URI. 
> You did this by creating a document.

While I like the documentary perspective, having class identity dictated 
by class membership can be quite chaotic and confusing in a changing 
world and partially known world.

> My argument boils down to this: It is futile to talk about who created a 
> particular abstract concept, or try to track versions of an abstract 
> concept. Let's stick to observable reality -- to the documents that 
> describe the abstract concepts. We know who created them, we can version 
> them. I think that this view of the world avoids a whole bunch of thorny 
> philosophical issues and is healthier for getting stuff done.

Are Java classes observable? I guess the difference is that you're 
seeing RDF classes as more like sets of things, and I see them as 
already being something like "descriptions of sets of things". And as 
things we can change our minds about and re-document (by making 
different rdfs:label and rdfs:comment statements) as time goes by. So in 
that last sense I think we've a similar view of them as abstractions; 
this by contrast with the old Dublin Core tradition of changing the term 
and namespace URIs when the community decide to make slightly different 
claims about their properties.

cheers,

Dan


>>> [0] http://dublincore.org/news/2008/#dcmi-news-20080114-01
>>> [1] http://dublincore.org/documents/dcmi-terms/
>>> [2] http://dublincore.org/schemas/rdfs/
>>> [3] http://dublincore.org/documents/domain-range/