Hi Ray, Robina,
The issue is not whether the MODS elements are "top-level" or not, but that the components used in a MODS instance are different in their nature from the terms referenced in a DC metadata description. A MODS element is a different sort of thing from a DC property. That's just a consequence of the fact that MODS and Dublin Core are based on different conceptual models. A MODS element is a "container": it has content (which may be other MODS elements or literal content); it might have attributes; it is interpreted in the context of the MODS data structure - even if it is a "top-level" element. A DC property is a type of relationship. In DC metadata descriptions, properties are referenced (using URIs) in statements. DC properties do not have content or attributes.
What the DC Lib AP needs (it seems to me) is a set of properties (and maybe other terms of the types used in DC metadata descriptions - classes, vocabulary encoding schemes and syntax encoding schemes) to represent the information it needs to meet its functional requirements.
Now it may be that the information represented by those properties (classes, etc) corresponds to the information represented by some part of the MODS hierarchical data structure, and it may be possible to describe a mapping between that part of the MODS hierarchical data structure and a set of statements using some specified set of properties, classes etc.
Those properties, classes etc could be assigned URIs owned by the Library of Congress, if that was desirable, and LoC wanted to own/manage those properties. They could equally well be assigned URIs owned by another party. Even if the properties, classes etc were identified using LoC-owned URIs, it would remain the case that the MODS elements on the one hand and the properties and classes etc on the other hand are _different_ things. (Incidentally, that was the approach taken with the set of properties defined to represent the MARC relator terms. Again there are two sets of terms: a set of terms that are used in MARC and a corresponding set of properties that can be referenced (using LoC-owned URIs) in DC metadata descriptions.)
For an example of this sort of mapping between a set of components used in a hierarchical data structure and a set of terms which can be used in a DC metadata description, see the work of the DCMI IEEE Task Force - N.B. still work in progress - on a mapping between the data elements of the IEEE LOM standard and a set of properties, classes, etc for use in DC metadata descriptions described here:
http://dublincore.org/educationwiki/DCMIIEEELTSCTaskforce/LomDCAMAnalysis
In the column headed "Probable DCAM representation" the QName-like names are all abbreviations for URIs which identify properties, classes, etc that can be referenced in DC metadata descriptions. They should not be confused with, say, the names used for XML elements in the LOM XML binding or the names of the LOM data elements themselves. Also the mapping is not always a simple one-to-one mapping.
Some of those terms mentioned in the column headed "Probable DCAM representation" already exist in the vocabularies of properties, classes etc provided by DCMI, others will be defined as part of this process. The URIs of those new terms may be owned by the IEEE LTSC or they may be owned by another party - AFAIK, that hasn't yet been decided - but in either case they are a different set of things from the "LOM data elements" defined by the IEEE LOM standard.
Cheers
Pete
-----Original Message-----
From: DC-Libraries Working Group on behalf of Ray Denenberg, Library of Congress
Sent: Wed 9/27/2006 10:29 PM
To: [log in to unmask]
Subject: Re: DC-Lib - proposal regarding MODS elements
I'm not yet completely conviced that this problem is "intractable", as the
paper suggests.
Quoting:
'An example is the "extent" element which appears twice in the MODS schema,
once within the "physicalDescription" container element and once as a
sub-element of the "part" container element - it follows that it makes no
sense to talk about the meaning of the mods:extent element in isolation as
its meaning can only be distinguished in the context of the structure of the
MODS schema.'
Ok, so instead of talking about the <extent> element, why not talk about the
<physicalDescriptionExtent> element and the <partExtent> element. (I'm not
suggesting that these two elements be renamed in-context but rather that
they would each reference the appropriate globally defined element instead
of being defined inline.)
True, these two elements don't (yet) exist, but they can easily be defined,
if it helps solve the problem, though I admit I'm not sure whether it does
or not.
And I realize that <extent> is not one of the elements at issue here but
only singled out for illustration. So let's consider one that is:
<dateCaptured>.
Now this one doesn't suffer from the dual-definition problem, but apparently
the problem is simply that it is not a top-level element. Are you aware
that in MODS 3.2 dateCaptured is now a globally defined datatype? Did that
not help? Would it help if <dateCaptured> (or <originDateCaptured>) were to
be defined as an instance element? That can be done, if it would help.
--Ray Denenberg
----- Original Message -----
From: "Clayphan, Robina" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Thursday, September 14, 2006 9:57 AM
Subject: DC-Lib - proposal regarding MODS elements
Colleagues,
The use of MODS terms in DC-Lib has been problematic for some time and a
proposal to remove them is on the agenda of the forthcoming WG meeting.
I have prepared a paper called "MODS terms in DC-Lib proposal" for this
item and placed it in the file area of this list.
http://www.jiscmail.ac.uk/cgi-bin/filearea.cgi?LMGT1=DC-LIBRARIES
The paper contains the proposal itself, background information and a
summary of the discussion that took place on the list earlier this year.
Those who will not be attending the conference are invited to submit
their thoughts to the list in advance of the meeting. A ballot will be
held at the meeting and extended to this list afterwards.
Regards,
Robina
Chair, DC Libraries Working Group
---------------------------------------------------
Robina Clayphan
Bibliographic and Metadata Standards
The British Library
Boston Spa, Wetherby
West Yorkshire LS23 7BQ UK
Tel: +44 (0)1937 546969
Fax: +44(0)1937 546586
--------------------------------------
**************************************************************************
Experience the British Library online at www.bl.uk
Help the British Library conserve the world's knowledge. Adopt a Book.
www.bl.uk/adoptabook
The Library's St Pancras site is WiFi - enabled
*************************************************************************
The information contained in this e-mail is confidential and may be legally
privileged. It is intended for the addressee(s) only. If you are not the
intended recipient, please delete this e-mail and notify the
[log in to unmask] : The contents of this e-mail must not be disclosed or
copied without the sender's consent.
The statements and opinions expressed in this message are those of the
author and do not necessarily reflect those of the British Library. The
British Library does not take any responsibility for the views of the
author.
*************************************************************************=
|