Jason, it seems that what you are suggesting is the DC terms can be
re-used in lots of different contexts, and that is true and that is a
Good Thing. You have to create the context to use them in, but the
"coreness" of DC is quite deliberate in that way. Library data is much
more about control than sharing, and for that reason it emphasizes
precise definitions and doesn't let users get "creative" with the
metadata. It depends on what you are trying to do, and it all boils down
to: the right tool for the job.
<http://example.org/resource-uri> dc:title
<http://example.org/resource-uri/title>.
<http://example.org/resource-uri/title> mods:title "The Title of a Book".
<http://example.org/resource-uri/title> mods:subtitle "The Subtitle".
<http://example.org/resource-uri> dc:creator <http://example.org/johndoe>.
<http://example.org/johndoe> awesomenamevocab:firstname "John".
<http://example.org/johndoe> awesomenamevocab:lastname "Doe".
So that way you're making use DC elements that are already defined and adding
specificity where necessary instead of reinventing new metadata elements where
you really don't need to.
The idea of a core that is extended is appealing. In a sense, that's
what you do with classes in RDF. DC has "Agent" as a class, and all of
the various agents are members of that class. What you have above,
however, is not "is a type of" but "is a part of" and that violates the
DC rule for extensions, which is that they must be able to be
represented by the Core value (the "dumb-down" rule). So "subtitle" is
not a type of title, it's a part of a title, and can't be represented by
"title". You can't refer to "lastname" as "creator."
As a counter example, RDA has "title" and it has "title Proper",
"parallel title", "translated title" -- each of those is wholly a title,
so if you wanted to lose the detail you could refer to them as "title".
Now, I think you could, for the purposes of your metadata, re-define
dc:creator to be of type foaf. So then in your metadata dc:creator can
only accept values as defined by foaf. But you lose the ability to use
dc:creator with a simple string. At this point, I see only a small
advantage to the use of dc:creator. But it would be interesting to
experiment with a DC application profile that leans on the DC core but
extends the core in the way you indicate above. I think there would be
problems extending some of the elements (e.g. "date" which is defined as
an RDF literal). At this point it gets over my head because of the
subtleties of the DCAM and how properties are defined within its bounds.
kc
--
-----------------------------------
Karen Coyle / Digital Library Consultant
kco...@kcoyle.net http://www.kcoyle.net
ph.: 510-540-7596 skype: kcoylenet
fx.: 510-848-3913
mo.: 510-435-8234
------------------------------------
