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