Please note that the draft by Paul and Tony reflects some confusion
among us that has not received sufficient attention to date, but that
will be the focus of the DC-models group in the very near future.  I
think we cannot go very far with this RFC until these issues are worked
out, so please do not look at this document as a deployment guide at
this time.

stu

	-----Original Message-----
	From:	[log in to unmask] [SMTP:[log in to unmask]]
	Sent:	Thursday, February 05, 1998 12:50 PM
	To:	DC-list
	Subject:	DC Source/Subelements

	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/