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