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

Richard Cyganiak richard at cyganiak.de
Wed Jan 23 17:33:07 GMT 2008


Dan, Mikael,

I'll probably not convince anyone, so I'll just acknowledge the  
difference in viewpoints, and clarify my viewpoint a little bit.

On 23 Jan 2008, at 13:32, Dan Brickley wrote:
>> 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.

Don't confuse names and the things they stand for. The URI dc:creator  
was certainly not used before 1994. The concept it stands for has  
certainly existed before that date. Documents have had authors before  
1994.

In my view, what happened in 1994 is that someone described this  
particular author-work relationship, which obviously existed before,  
in a specification, and the spec also assigned the URI “dc:creator” to  
that relationship.

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

Yes, this is true, but I don't think it's relevant to this point.

The sections you quote are about something else. There is the class of  
“all people named Richard Cyganiak who have contributed to this  
thread” and the class of “all people wearing black sweaters in DERI  
Galway's room 102 today”. Both are clearly different classes, even  
though they have the same members. This is orthogonal to the question  
wether these classes existed before I thought of them, or wether they  
are creative works.

I'd rather not try to answer these questions -- do classes as such  
exist before they are formally defined, can they change, are they  
creative works. I'd rather stick to talking about the documents that  
define the classes, and for which we can easily answer those questions.

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

Still, can you give any evidence for your creator claim for that  
particular class, without pointing to a document you authored? I doubt  
it. Could you refute my claim that I created the resource identified  
by foaf:Person?

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

As said above, this is not my point of view. I don't want classes  
defined by class membership, this violates RDF semantics. I want  
classes defined by documents and specifications.

I oppose this way of formalizing metadata related to classes and  
properties:

    foaf:Person dc:creator :danbri .

Because laying claim to the creation of an intangible abstract idea is  
a bit too fluffy for me. I advocate doing it this way:

     foaf:Person rdfs:isDefinedBy <http://xmlns.com/foaf/0.1/> .
     <http://xmlns.com/foaf/0.1/> dc:creator :danbri .

Because that's tangible and verifiable and reflects more closely how  
things work in practice.

[snip]
> 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.

Yes, certainly. Changing our minds, in practice, requires revision of  
the documents defining the class, and hence it is a revision of the  
class *definition*. Anything beyond that is just conjecture, in my view.

Finally, let me point out that you often have to fall back on document- 
oriented language -- “write an OWL restriction”, “re-document a class”  
-- while trying to argue that creating and modifying classes is  
independent from documents. Not sure if this observation means anything.

I don't want to draw this discussion out much longer -- I think I've  
made my case as good as I can, please feel free to return to the  
discussion of FOAF-DC alignment.

Cheers,
Richard


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



More information about the foaf-dev mailing list