[foaf-dev] Time to make the foaf classes relate to Dublin Core
richard at cyganiak.de
Wed Jan 23 17:33:07 GMT 2008
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
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
>> 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
>> 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
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.
> 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.
> 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.
>>>>  http://dublincore.org/news/2008/#dcmi-news-20080114-01
>>>>  http://dublincore.org/documents/dcmi-terms/
>>>>  http://dublincore.org/schemas/rdfs/
>>>>  http://dublincore.org/documents/domain-range/
More information about the foaf-dev