Sorry for the delay in replying (nothing like a shorted-out keyboard to
take you out of the loop!) I'm not sure how to clarify ... let me try ...
by asking a question:
Since all the elements are optional, there will likely be resources for
which there is no formal DC.Identifier. That said ...
Using DC.Relation.Identifier and DC.Relation.Type, how would you create a
relationship between two resources when one or both did not have a value
for DC.Identifier? (Maybe you wouldn't/couldn't do this anyway, in which
case my observation is moot?)
The second point was simply that this requires adding another semantic for
qualifying DC. If we do that for Relation, for the sake of simplicity and
consistency wouldn't we need to revisit other elements? For example, you
offered:
<meta name="DC.Relation.Identifier"
content="http://purl.org/metadata/dublin_core_elements">
<meta name="DC.Relation.Type" content="IsBasedOn">
The date equivalent would be:
<meta name="DC.Date" content="1993-03-14"
<meta name="DC.Date.Type" content="Created">
I'm relatively new to the list, so if I'm out in left field here, "somebody
stop me".
From: misha.wolf on 03/25/98 12:06 PM
To: [log in to unmask]
cc:
Subject: Re: Ever since Canberra
I've read this mail three times and still don't understand it.
Misha
> Just to muddy up the water with a couple more issues that impact how we
> express Relation ...
>
> 1) By adding the concept of "Identifier" to Relation we will limit the
> scope of Relation. The current definition and proposed syntax limits
> Relations to being based on the Identifier element. Admittedly, _most_
of
> the time there will be an identifier, but conceptually, there will be
> situations where it will be desirable to create relationships between
> resources based on some other element. I hate to see us narrow the
design
> unnecessarily.
>
> Current Definition & Syntax - the only thing to which a relationship can
be
> indicated is another resource that has an Identifier:
>
> Definition:
> An _identifier_ of a second resource and its relationship to the present
> resource. This element permits links between related resources and
> resource descriptions to be indicated. ...
>
> Syntax:
> <meta name="DC.Relation.Identifier"
> content="http://purl.org/metadata/dublin_core_elements">
> <meta name="DC.Relation.Type" content="IsBasedOn">
>
>
>
> The previous definition and syntax left much more flexibility:
>
> Definition
> Relationship to other resources. The intent of specifying this element is
> to provide a means to express relationships among resources that have
> formal relationships to others, but exist as discrete resources
themselves.
> For example, images in a document, chapters in a book, or items in a
> collection.
>
> Syntax
> <meta name="DC.Relation.IsBasedOn"
> SCHEME="URL"
> content="http://purl.org/metadata/dublin_core_elements">
>
> 2) By adding a new and different semantic style (different from any of
the
> other elements), we are making DC more complex and making the tool
> creators' job more difficult.
>
> We already have two mechanisms for refining the elements: qualifiers and
> SCHEMEs. This introduces a third mechanism for refinement. Do we really
> need another?
------------------------------------------------------------------------
Any views expressed in this message are those of the individual sender,
except where the sender specifically states them to be the views of
Reuters Ltd.
|