Many thanks to those who have drafted these DC documents. There are various
deadlines here, therefore, forgive me if the questions raised below are not of
imminent importance.
A. I seem to remember that a decision was made to call the Element "Contributor"
in its singular form. However, in Paul Miller's RFC #3 (Subelements, 2-3-98), it
is stated:
4.3.6 CONTRIBUTORS
Contributors.PersonalName
The name of an individual making a contribution to the creation of the
resource.
Contributors.CorporateName
The name of an institution or corporation making a contribution to the
creation of the resource.
Contributors.PersonalAddress
An electronic or physical address for the individual in question. This
could be an electronic mail address, web page, URL, postal address, etc.,
and is most useful if further defined by use of a SCHEME.
Contributors.CorporateAddress
An electronic or physical address for the institution or corporation in
question. This could be an electronic mail address, web page URL, postal
address, etc., and is most useful if further defined by use of a SCHEME.
B. Should subelements for the Source Element be included in the RFC #3 at this
stage?
In Paul Millers RFC #3 (Subelements, 2-3-98), it is stated:
4.3.11 SOURCE
No SUBELEMENTs at present.
In John Kunze's RFC #1 (Unqualified DC, 1-30-98), it is stated:
3.11. Source Label: "Source"
Information about a second resource from which the present resource is
derived. While it is generally recommended that elements contain
information about the present resource only, this element may contain a
date, creator, format, identifier, or other metadata for the second
resource when it is considered important for discovery of the present
resource; recommended best practice is to use the Relation element instead.
For example, it is possible to use a Source date of 1603 in a description
of a 1996 film adaptation of a Shakespearean play, but it is preferred
instead to use Relation "IsBasedOn" with a reference to a separate resource
whose description contains a Date of 1603. Source is not applicable if the
present resource is in its original form.
and from Simon Cox's excellent elucidation in his 12-24-97 message regarding
DC-Source vs DC-Relation:
Thus, any resource can have
(1) its own metadata, relating primarily to the current instantiation,
DC.Creator, DC.Date, DC.Format, DC.Identifier, etc
(2) some additional metadata which is related to ancestor(s),
DC.Source.Creator, DC.Source.Date, DC.Source.Format,
DC.Source.Identifier, etc
- the embedding mechanism.
(3) a pointer(s) to ancestors
DC.Relation.IsBasedOn, DC.Relation.IsFormatOf, etc.
- the ideal 1-to-1 mechanism.
I understand that it is preferred to use the Relation Element to record
metadata for source item. However, I cannot figure out how to enter a date of a
source item (e.g., a photograph taken in 1900) into a Relation Element. It seems
to me quite logical to put the date under the Source Element as DC.Source.Date.
If this is the case, perhaps it should be clearly stated in the RFC #3 that the
Source Element could have (in theory) any of the other 14 DC elements as its
subelements. Or, am I going overboard?
Karen
***********************************
Karen M. Hsu
Assistant Director for Cataloging
The Research Libraries
New York Public Library
42nd St. & 5th Ave.
New York, N.Y. 10018-2788
(212) 930-0702
(212) 930-0785 (Fax)
Internet: [log in to unmask]
***********************************
______________________________ Reply Separator _________________________________
Subject: DC-Source vs DC-Relation
Author: Simon Cox <[log in to unmask]> at Internet
Date: 12/24/97 8:26 AM
Simon Pockley wrote:
>
> It seems to me that `version', `format' and `based on' - are
> dealt with under `Source' even if the relation is one way.
We really need to clear this one up. It is becoming a FAQ.
I could quote several messages to this list which followed
Helsinki which clarified the proposed usage of "Source" with
respect to "Relation", and my message of Sunday also spoke
to this, but perhaps I'll try again.
Yes - "Source" as an element independent of "Relation" is
semantically ambiguous. In the full RDF type framework,
information about all Source's for a resource would be
retrievable through following a chain of Relation's of
the types indicated above, thus as Simon Pockley correctly
observes, Source seems to be a subset of Relation.
However, it is likely that it will be a long time, maybe never,
before a complete RDF framework has been put in place with
DC metadata for everything which would allow this to be a
complete solution. And even then, short of elaborate caching
arrangements, it may not be very efficient. Thus, we need
an alternative way to allow _information_about_an_ancestor_,
which is nevertheless relevant to _*discovery*_of_the_present_resource_,
to be attached to the _metadata_of_the_present_resource_.
It has been proposed that the "Source" element be used
explicitly to provide this facility.
Thus, metadata in DC-Source is in fact metadata for a
resource(s) other than the present one, but which is
privileged because it is considered to be important
for resource discovery, and is thus _embedded_ in the
metadata set for the present resource. The fact that
the metadata actually refers to a different resource is
flagged by inserting the key-word "Source" in the
attribute identifier for the metadata element.
Thus, any resource can have
(1) its own metadata, relating primarily to the current instantiation,
DC.Creator, DC.Date, DC.Format, DC.Identifier, etc
(2) some additional metadata which is related to ancestor(s),
DC.Source.Creator, DC.Source.Date, DC.Source.Format,
DC.Source.Identifier, etc
- the embedding mechanism.
(3) a pointer(s) to ancestors
DC.Relation.IsBasedOn, DC.Relation.IsFormatOf, etc.
- the ideal 1-to-1 mechanism.
In principle the information stored in (2) could be
discovered by finding the metadata sets referred to in (3),
but in some cases, although it is less elegant (it is a
deviation from the 1-to-1 rule) it may be more practical.
Note that the syntax used in (2) here implies that Source
_must_ be qualified. In the litest version of DC
- no qualifiers - DC.Source and DC.Relation would sometimes
have the same value - an identifier for an ancestor,
though for DC.Source it may be a more distant ancestor -
but in all other cases the usage would be different.
Is this clear, and does it accord with other people's
understanding?
---------
(This is substantially a repeat of a message already
seen by subscribers to dc.relation. Further discussion
will be on meta2.)
--
__________________________________________________
Dr Simon Cox - Australian Geodynamics Cooperative Research Centre
CSIRO Exploration & Mining, PO Box 437, Nedlands, WA 6009 Australia
T: +61 8 9389 8421 F: +61 8 9389 1906 [log in to unmask]
http://www.ned.dem.csiro.au/SimonCox/
|