Ross Singer wrote:
>
> One of the problems here is that it doesn't begin to address the DCAM
> -- these are 59 properties that can be reused among 22 classes, giving
> them different semantic meaning.
>   

Uh, no. That's the opposite of what the DC terms are about. Each term 
has a defined range -- so the defined range of creator is Agent. It can 
only be used as an Agent. You don't mix and match, and you don't assign 
different semantics to the same property under different circumstances. 
You can further *restrict* properties (which is what the application 
profile is all about) but you can't change the semantics of properties. 
The DCAM allows a property to be a member of more than one class, but I 
don't see any examples of that (will ask on the DC list) in DC terms. 
Remember that the A in DCAM is "abstract." Some of the things it makes 
possible may be unusable in real life.

> Dublin Core is toothless and practically worthless in XML form.  It is
> considerably more powerful when used in RDF, however, because they
> play to their mutual strengths, namely that in RDF, you generally
> don't use a schema in isolation.
>   

The elements in Dublin Core are the elements in Dublin Core. The 
serialization shouldn't really matter. But if you need to distinguish 
between title and subtitle, Dublin Core's http://purl.org/dc/terms/title 
doesn't work. What matters is the actual *meaning* of the term, and the 
degree of precision you need. You can't use 
http://purl.org/dc/terms/title for "Mr." or "Dr." in a name -- it has a 
particular meaning. And you can't use it for "title Proper" as defined 
in library cataloging, because it doesn't have that meaning. It all 
depends on what you are trying to say.

>   
> This is true.  But this is also why I'm asking what is missing in
> DCTerms that would be available in MODS -- The "win" of RDF is that
> you aren't contrained by the limits of a particular schema.  If a
> particular vocabulary gets you a fair ways towards representing your
> resource, but something is missing, it's perfectly reasonable (and
> expected) to plug in other vocabularies to fill in the gaps.
>   

Exactly. But the range of available vocabularies today is quite limited. 
There are a lot of semantics that are used in libraries that I can't 
find in the available vocabularies. Eventually I think we will have what 
we need, but ... well, yesterday I was hunting all over for a data 
element for price. And the person who needed it didn't want to get into 
the complexity of ONIX. BIBO doesn't have it. DC doesn't have it. RDA 
doesn't have it. Something that simple.

Now I admit that lots of people are inventing bibliographic element 
sets. But if you look carefully at the properties they are defining, the 
overlap isn't all that great. At least, if you don't want to lose 
meaning. It's absolutely key to look at the semantics and the 
relationships. RDA is defining certain properties as having a fixed 
relationship to an FRBR entity. (I'd rather do that in an application 
profile rather than the properties, but that's not my call.) A similar 
property in DC, without making that connection, doesn't have the same 
meaning because you can't distinguish between a title for the work or a 
title for the expression. Perhaps you could create a record format that 
gives DC terms "title" that context, but used alone it does not contain 
those semantics.

What I WOULD like to see is a good vocabulary of basics -- date, time, 
place, currency, etc etc etc. One place where you know you can go and 
find all of those key building blocks, so you don't have to hunt all 
over god's little acre for something as simple as "price". That would be 
really useful.

kc


-- 
-----------------------------------
Karen Coyle / Digital Library Consultant
[log in to unmask] http://www.kcoyle.net
ph.: 510-540-7596   skype: kcoylenet
fx.: 510-848-3913
mo.: 510-435-8234
------------------------------------