 |
 |
> 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. I think what Ross is getting at isn't exactly what he said: you're right of course that the semantics of a DC property don't change when you use it in various circumstances. What happens is that you use the same DC property to describe the same type of attribute for different entities within your data set. So, you use a dc:creator property to describe the creator of a digital image file, a dc:creator property to describe the creator of the thing in your image, and a dc:creator property to describe the creator of the metadata record. The properties point to different things, but it's still the same property--you don't need to define three separate and distinct properties in your schema. This is one of the things that makes MARC (and so many other metadata standards) unwieldy, because you've got the same essential type of property (like a "creator" property) that is defined separately depending on what it is supposed to be describing (when it doesn't necessarily have to be that way). > > 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. I think the reason it matters--and the reason that Ross mentioned it--is because the commonly-used XML serialization is just a flat DC record describing a single resource (isn't it?). Using a data model like RDF (or the DCAM), DC becomes a lot more powerful because of the ability to reuse the DC metadata properties to describe different entities/resources easily. Your later point that some DC properties aren't specific enough (e.g., title) still stands, although I wonder if it would be kosher (as far as DC is concerned) to do something like this: <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". Similarly with names: <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. Jason Thomale Metadata Librarian Texas Tech University Libraries