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