On Wed, 27 Sep 2006, Pete Johnston wrote:
> 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.
I would support Ray's opinion in recent (and previous!) mails as to
whether the issues over re-use of MODS elements are 'intractable' also see
Rebecca's comments in previous debates on this topic
http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0604&L=dc-libraries&T=0&P=1&P=1168
I would like to add my own take on this long-running debate.
I think it would be useful to take a step back and consider the benefits
of the alternative approaches suggested in these latest exchanges. As
Robina's paper explains, the Usage Board itself supported re-use of MODS
elements (as properties) for some considerable time. I think we should
have some sense of history, what were the UB trying to achieve then, what
is to be achieved by the approach proposed now?
In my view Dublin Core semantics are simple by choice, on purpose, in
order to enable a base level of shared understanding. The DCAM allows for
extensibility and thereby suggests there will be change and evolution.
This leads me to believe that the data model and associated syntax(es) in
which the DC semantics are expressed should not be over-complex, should be
accommodating and 'fit for purpose'.
I fully accept Pete's view that the DCAM and MODS data models are
different. But I would argue that despite there not being equivalence in
the data models, in practice where there is 'semantic equivalence' it is
beneficial to appropriate MODS elements for use in DC. Where human
judgement agrees semantic equivalence, where appropriate URIs have been
declared, then I see no detriment to real-world systems in re-use of an
'element' as a 'property'. I am not a purist!
To me the bottom line is whether systems that use DC will be disadvantaged
by what is (in my view) a 'good enough' approach to re-use and
equivalencing. If a property defined by an RDFS assertion has the same
semantics as a MODS XML element, although they are not technically the
'same object' what will it break if the an URI is declared and used as an
equivalent?
Moreover, if a service agregates metadata structured according to a
particular DCAP this will oftem be done in the context of a 'designated
community' where some prior knowledge can be assumed. If metadata is being
aggregated from far and wide, then, as I see it, re-use of semantically
equivalent MODS elements as properties will not be an issue in huge triple
stores??
Just warming up to discussions in Mexico,
Rachel
>
> 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.
>
> *************************************************************************=
>
---------------------------------------------------------------------------
Rachel Heery
UKOLN, University of Bath tel: +44 (0)1225 386724
http://www.ukoln.ac.uk
|
