Quite right.
Misha
> 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/
>
------------------------------------------------------------------------
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.
|