Ann, Pete, Ray, Andy,
Thanks to all of you for this discussion which has certainly shed some
light on the issues surrounding the desire to re-use MODS terms in
DC-Lib. My current understanding is that, despite the best efforts of
Ray and colleagues at LC, there appear to be insuperable obstacles in
re-using MODS elements in a DC application profile due to the two
formats being based on fundamentally different models.
Is it premature to draw the conclusion that we probably have to abandon
the idea of re-using MODS elements in DC application profiles? This
issue has been around since the UB decisions of 2002 [1,2,3] and if we
must now find a different solution then I would like to start making
some progress on it.
If we are to look for an alternative there are three terms to make some
decisions about: dateCaptured, edition and location. The most obvious
alternative solution is to try and identify the terms we require from
other namespaces that share the same model. As a starting point Ann has
suggested using the term "isLocatedAt", proposed by the Collection
Description WG [4], instead of "location". This term refines
dc:relation and the definition given in the CDAP is "A location of the
resource". This does not seem to conflict with the requirement of
DC-Lib, which is to identify the organization holding the resource [5].
Robina
1) http://dublincore.org/usage/decisions/2002/2002-02.captured.shtml
2)
http://dublincore.org/usage/decisions/2002/2002-02.holdingLocation.shtml
3) http://dublincore.org/usage/decisions/2002/2002-02.version.shtml
4)
http://dublincore.org/groups/collections/collection-application-profile/
2006-02-24/#genislocatedat
5)
http://dublincore.org/documents/2004/09/10/library-application-profile/#
Location
-----Original Message-----
From: DC-Libraries Working Group [mailto:[log in to unmask]] On
Behalf Of Ann Apps
Sent: 26 April 2006 10:12
To: [log in to unmask]
Subject: Re: Progressing DC-Lib and MODS
Thanks Ray and Pete for helpful contributions. Why am I starting to
regret volunteering to explain this in language everyone can
understand...? Seriously I think this explains it very well - or will
when consolidated into a document.
But is there an additional issue? XML schema (or DTD) defines the
existence and structure of elements according to a known syntax. But it
doesn't define semantics for the elements.
The only semantics I can find for the MODS terms are in the User Guide
(I did only look very quickly). This is clearly for human reading. The
DC-Lib AP itself does define the semantics of the properties as they are
used within the AP (currently also for human reading).
The semantics of DC properties are defined in RDF at
http://dublincore.org/2003/03/24/dces
Should properties used in a DC Application Profile have defined
machine-readable semantics available somewhere as well as URIs (or at
least an intention of providing them)?
Ann
-------------------------------------------------
Ann Apps. IT Specialist (Research & Development), MIMAS,
The University of Manchester, Oxford Road, Manchester, M13 9PL, UK
Tel: +44 (0) 161 275 6039 Fax: +44 (0) 161 275 6040
Email: [log in to unmask] WWW: http://epub.mimas.ac.uk/ann.html
--------------------------------------------------
> -----Original Message-----
> From: DC-Libraries Working Group [mailto:[log in to unmask]]
> On Behalf Of Pete Johnston
> Sent: Wednesday, April 26, 2006 7:41 AM
> To: [log in to unmask]
> Subject: Re: [DC-LIBRARIES] Progressing DC-Lib and MODS
>
> Quoting "Ray Denenberg, Library of Congress" <[log in to unmask]>:
>
> > We have attempted to address one of the problems that Ann cited by
> > making the 3 elements in the DC-Lib profile global in MODS version
> > 3.2 so that they can be referenced by other XML schemas. However,
> > Pete notes, making these elements global doesn't make them usable
in a DC metadata description.
> >
> > We have not assigned URIs to MODS elements yet. We cannot assign
> > URIs in
> the
> > same manner as URIs are assigned for DC because MODS is structured.
> >
> > To elaborate on the confusion that Pete alludes to: An identifier
> > created for an xml element is not necessarily a universal identifier
> > for that element - it identifies the element to the extent that it
> > distinguishes it from another element with the same name but in a
> > different namespace. For DC, an identifier for an element may also
> > be a universal identifier, because dc is flat. Not so for MODS,
> > because it is structured. Namespaces do not know about structure;
schemas do.
>
> Yes, thanks. This is a good point that I had glossed over.
>
> > The confusion -- the misconception that an element identifier is a
> > URI -- comes when one says that a "qname" identifies an xml
> > element. A qname is for example, "mods:name" - "mods:" in this
> > context is (functionally) a uri (a prefix associated with a uri,
> > the uri of the mods namespace). So, since a qname is therefore
> > (functionally) an element name qualified by a uri, people tend to
> > conclude that a derived URI can be constructed (e.g. the namespace
> > URI concatenated in some fashion with the simple element name) to
> > universally identify the element, and clearly this is a
misunderstanding. It works for DC but not for mods.
>
> Yes. I think generally we (DCMI, DCAP developers, DC implementers)
> need to be rather more careful about explaining when we are using
> "qualified names" as abbreviations/shorthands for URIs - which we all
> do all the time, as it's a heck of a lot easier to say/write "dc:date"
> than "http://purl.org/dc/elements/1.1" - and when we are using XML
> QNames, which as Ray and I have said are shorthands for these two-part
> names ("local" element name qualified by URI (XML Namespace Name)).
>
> Because of course DC makes use of XML too and in some contexts that
> "dc:date" string really is an XML QName!
>
> _Some_ _XML_ _formats_ make a mapping _between _XML QNames and URIs -
> and then usually only in some clearly specified contexts - but it
> remains the case that they are different things.
>
> I realise we risk giving the impression to the casual user that we are
> suffering from excessive pedantry, but once we get into this area of
> working with different metadata standards and different "abstract
> models" or conceptual frameworks, these things become crucial if we
> are able to commuicate effectively across those boundaries and if we
> are to develop effective interoperability between our different
standards.
>
> > Consider for example mods elements:
> >
> > <extent> within <physicalDescription> and
> > <extent> within <part>
> >
> > Two completely different elements, same simple name, same namespace.
> > These cannot be distinguished using qnames.(Obviously not, as a
> > qname is a combination namespace name and simple name, and these
> > have the same
> simple
> > name and same namespace. They are distinguished in the MODS schema
> > by structural definition.)
>
> Right, yes.
>
> > So if we want to assign URIs to MODS elements, it cannot be based on
> > namespace. We are considering doing it based on schema, for example:
> > info:element/mods/physicalDescription/extent
> > info:element/mods/part/extent
>
> OK, but I'd expand a little just on that final point.
>
> I agree that URIs could be assigned to the MODS elements in this way
> and two different URIs could be assigned to distinguish the two
> different uses/interpretations of the MODS extent element. I might
> quibble about the choice of the info URI scheme, but I Won't Go There
> ;-)
>
> Using those URIs, we can refer unambiguously to each of those
> elements-as-containers defined by the MODS hierarchical data
structure.
>
> If we really wanted, we could even use those URIs as resource URIs and
> value URIs in DC metadata descriptions and make statements about those
> MODS elements-as-containers
> However, it would still be the case that the things identified by
> these URIs are those elements-as-containers. They are deployed in the
> context of the MODS tree data structure; a MODS element-as-container
> (or maybe an instance of one of tose elements as containers - I'd need
> to think harder about the model there!) has attributes and child
> elements and so on. They don't have refinement/subproperty
> relationships with other MODS elements-as-containers; because that
> notion has no meaning in the MODS conceptual framework. They are not
> properties and should not be referred to as properties in DC metadata
> descriptions.
>
> Properties are different things from elements-as-containers. They are
> two different types of thing constructed within two different
> conceptual frameworks,; they have different relationships with other
> things within those frameworks.
>
> It would be a mistake for the DC Libraries WG to take a URI that Ray
> and the MODS team had assigned to identify a MODS element-as-container
> and to use it as a property URI, because we would then be implying
> that the same URI identified two quite different types of component.
>
> As I said at the meeting in Madrid, the DC Libraries AP requires a
> small set of properties to represent the information it currently
> tries to represent "using MODS elements".
>
> To be referenced in a DC metadata description, those properties must
> be identified by URIs. Personally, I'd advocate using the http URI
> scheme because you get lots of simple, practical, immediate benefits
> from using that scheme in the context of the Web - but, hey, all we
> need are URIs and another URI scheme would still do the job.
>
> Whether those URIs (of whatever URI scheme) are owned/assigned by
> DCMI, Library of Congress or some other party is a
> social/political/organisational issue. I'm really much less bothered
> about that choice than about the fact that we are clear about what
> those URIs identify/refer to, and that we take care to avoid confusing
> XML elements and DC properties.
>
> Cheers
>
> Pete -------
> Pete Johnston
> Research Officer (Interoperability)
> UKOLN, University of Bath, Bath BA2 7AY, UK
> tel: +44 (0)1225 383619 fax: +44 (0)1225 386838
> mailto:[log in to unmask]
> http://www.ukoln.ac.uk/ukoln/staff/p.johnston/
**************************************************************************
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.
**************************************************************************
|
