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