> 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.
True. However, I would argue (based on my perhaps bizarre understanding) that the linked data world is just as much about control--in a different sense. Library data--and really any traditionally-designed data--is controlled from the top down. With linked data, control emerges from the bottom up. Getting "creative" with linked data is just as problematic as it is with library data. If you're using data elements differently than the rest of the world, then your data won't make sense in the context of the data that links to/from it. > > <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." Let's just ignore my title/subtitle example--it's a bad one. What I intended to express isn't what I actually expressed, I don't think. Focusing on the creator example, what I wrote above are 3 completely separate triples. The first says that <http://example.org/johndoe> is the dc:creator of <http://example.org/resource-uri>. The next two further define the resource <http://example.org/johndoe> by saying that it has an awesomenamevocab:firstname property of "John" and an awesomenamevocab:lastname property of "Doe". Those aren't supposed to be DC extensions; they're properties taken from a totally external data schema that I assert describe the <http://example.org/johndoe> resource (which just happens to be a dc:creator of <http://example.org/resource-uri>). I'm not trying to build new DC elements, nor am I asserting that those properties are somehow connected to DC, so the DC extension rules don't apply. I could say: <http://example.org/resource-uri> dc:creator <http://example.org/johndoe>. <http://example.org/johndoe> foaf:firstName "John". <http://example.org/johndoe> foaf:surname "Doe". And there would be no implication that the foaf data elements were somehow qualifiers or extensions of dc:creator. At the end of the triple with the dc:creator property is where the DC "jurisdiction" (so to speak) also ends. > 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. A better way might be to express an equivalency between foaf:Agent and dc:Agent and then assert explicitly that your resource is a foaf:Agent (or a foaf:Person), although I don't think there's really a need to do that. An RDF application would be able to make the appropriate inferences about your data just based on the properties you use, no matter where those properties come from. So, in my example above--assuming that I used namespaces appropriately--an RDF application could infer that my johndoe resource belongs to the dc:Agent class no matter what additional properties (inside or outside the dc namespace) I tie to that resource. Further, where I use foaf properties to describe the johndoe resource, an RDF browser would infer that the resource also belongs to the class foaf:Person. And that's okay--resources can belong to multiple classes at once. This is an example of the "bottom up" control that linked data--in an ideal world--promises. Given enough inferences, an application might be able to draw some different equivalencies between dc:Agent and foaf:Agent, and therefore members of those classes, even though the two classes were created by two completely different communities. That's one reason that it's a good thing, in the linked data world, to use metadata languages from different communities to describe the same set of resources. It provides a basis for making all different kinds of inferences and making data between multiple communities more interoperable. Jason
