 |
 |
Ross Singer wrote: > Jason clarified what I meant much better than I did, but I will take > this a step further -- the DC properties have ranges, but only 5 have > a constraint on their domain. So while dct:creator has to point at a > dct:Agent (or some equivalent), where the dct:creator property lives > can be anything. > > <dct:Location about="#RhodeIsland"> > <dct:title>Rhode Island</dct:title> > <dct:creator> > <dct:Agent about="#RogerWilliams"> > <dct:title>Roger Williams</dct:title> > <dct:creator> > <dct:Agent about="#JamesWilliams"> > <dct:title>James Williams</dct:title> > </dct:Agent> > <dct:Agent about="#AliceWilliams"> > <dct:title>Alice Williams</dct:title> > </dct:Agent> > </dct:creator> > </dct:Agent> > </dct:creator> > </dct:Location> > The above looks really odd to me -- I'm not at all sure that you can use the class Agent in that way.... I was of the impression that classes are used in metadata definitions, but not in instances. Am I wrong? > The definition of dct:title is: A name given to the resource. So > dct:title could be "re: [CODE4LIB] MARC/MODS and Automating Migration > to Linked-Data Standards", "Ross Singer" or "Chattanooga, TN" > depending on what resource we're talking about. Maybe "semantics" is > a poor word choice, but I think "Ross Singer" as a "title of an Agent > resource" or "Chattanooga, TN" as the title of a Location resource > have some conceptual distinctions to "For Whom the Bell Tolls". > > The "creation" of Rhode Island also carries a different mental image > than the "creation" of Roger Williams. > > It seems like context influences semantics, at least somewhat. > Right. It can be used for all of those things. But it can't represent "subtitle" and it can't represent "parallel title" without further metadata definitions. You seem to be saying that title as defined in DC is very broad and can be used in lots of contexts. That's true, but that's the opposite of the issue that I'm having. The issue I'm having is that it is imprecise. So if I want precision, I've got to go beyond DC -- create a new definition, maybe extending DC, or maybe creating something new. And that's why you find people all over the place creating bibliographic metadata -- because they need more precision than DC. > Again, Jason did a good job at explaining the difference. Dublin Core > in XML (at least in every example I've ever seen) consists solely of > literals. The values are text, not resources -- so in XML DC, not > only would you be unable to attach, say, birth and death date > properties to Roger Williams, you also wouldn't be able to say who his > creators are. > uh.... http://dublincore.org/documents/2008/09/01/dc-ds-xml/ I think you've been looking at the pre-DCAM DC XML. > Going back to "context defining semantics", I don't think it's > unreasonable to say that dct:title does mean "title distinct from > subtitle" if that's the expectation of how dct:title is to work within > your vocabulary/class. > > <ex:Book about="http://example.org/ex/1234"> > <dct:title>Zen and the Art of Motorcycle Maintenance</dct:title> > <ex:subTitle>An Inquiry into Values</ex:subTitle> > </ex:Book> > Well, I can say that, but lots of other people will give me: <ex:Book about="http://example.org/ex/1234"> <dct:title>Zen and the Art of Motorcycle Maintenance: An Inquiry into Values </dct:title> </ex:Book> and they'll be just as correct. Because title can be anything I want it to be, but if we're trying to communicate clearly, that broadness of definition can be a problem. > The definition of dct:title is pretty ambiguous -- alternately, you > might choose to use dct:title to contain the full title and define > some other property for main title. > Great. Redefine it another 6 or 8 ways.... that's exactly my point. > Just because title doesn't have a clear definition doesn't mean rules > can't be applied towards it when used in a particular domain (assuming > they conform to 'the name of the resource'). > > Which is what the DCAP is about. With an application profile, you *re-define* terms for your domain. Your definition, however, cannot negate the original definition, it can only extend it. So it wouldn't do for me to redefine title as the date of issuance of the resource (or redefine "issued" as the name the resource is known by). And the main thing about a DCAP is that you have to create a machine-readable definition that conforms to certain rules so that others can understand what you have decided to do with *your* data elements. >> 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. >> > > Sure you can. > > <frbr:Expression about="http://example.org/e/1234"> > <dct:title>Romeo + Juliet</dct:title> > <frbr:realizationOf resource="http://example.org/w/1234" /> > <dct:creator resource="http://example.org/i/craig-pearce" /> > <dct:creator resource="http://example.org/i/baz-luhrmann" /> > </frbr:Expression> > <frbr:Work about="http://example.org/w/1234"> > <dct:title>Romeo and Juliet</dct:title> > <dct:creator resource="http://example.org/i/william-shakespeare" /> > <frbr:realization resource="http://example.org/e/1234" /> > </frbr:Work> > Um, no "realization" is defined in FRBR. And Work and Expression are classes, not properties. I admit I'm pretty unsure how FRBR itself is going to be "realized" but I have my doubts that we'll have distinct structures like Work and Expression. This is an area I would like to see explored, but I'm not sure we have the information we need at this point -- no, more than that, I don't think we have the networks we need at this point. (BTW, this is all we have defined so far for FRBR, but this has been approved by the FRBR IFLA working group: http://metadataregistry.org/schemaprop/list/schema_id/14.html) > But nothing is going to make sense out of context. Ah, this is a key point where we disagree. Context helps, but we have to be able to move our metadata across contexts and have it still have meaning. To me, that's what RDF and the Semantic Web are all about. Freeing our metadata from the need for human interpretation, so it can be better used by machines. And for me that means precision, precision, precision. Which will fail at some points, because data is dirty and messy, but where it succeeds we will make great strides forward. 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 ------------------------------------