Peter,
I suggest you read [1] and [2].
[1] http://www.roads.lut.ac.uk/lists/meta2/1997/10/0099.html
[2] http://www.roads.lut.ac.uk/lists/meta2/1997/10/0171.html
----------------------------------------------------------------------------
Misha Wolf Email: [log in to unmask] 85 Fleet Street
Standards Manager Voice: +44 171 542 6722 London EC4P 4AJ
Reuters Limited Fax : +44 171 542 8314 UK
----------------------------------------------------------------------------
12th International Unicode Conference, 8-10 Apr 1998, Tokyo, www.unicode.org
7th World Wide Web Conference, 14-18 Apr 1998, Brisbane, www7.conf.au
>
> 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.
|