|
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/
|
