On Wed, 9 Feb 2005, Ray Denenberg, Library of Congress wrote:
> From: "Ann Apps" <[log in to unmask]>
> > The way of encoding these MODS terms is different from, and not
> > really consistent with, DC practice to date. They have to include
> > nested elements, eg:
> > <mods:location>
> > <mods:url>http://example.org/myurl</mods:url>
> > <mods:location>
> Hi Ann,
> I'm not really up-to-date with dc so I don't know what dc practice you're
> referring to,
The fundamental problem here is that the XML encoding of DC is a
representation of the underlying DC 'model' (the DCMI Abstract Model)
which essentially is the same 'resource, property, value' triple model
found in RDF. MODS (in common with many other XML-based languages, e.g.
LOM, METS, etc.) does not share that same underlying model.
This is not a critisism of any of these other XML-based languages BTW -
just a statement of fact.
It is therefore not possible to simply squish together DC 'elements' and
MODS 'elements' in any kind of meangingful way.
Even if, as you suggest below, there is a way to make mods:url look
superficially like a DC 'element' (i.e. to use it without the nesting),
unless it really is a DC-compatible property, then what is being attempted
here simply does *not* work.
By "DC-compatible property" I mean that the URI
http://www.loc.gov/mods/v3url (*) identifies a 'property' (as defined in
section 7 of the DCMI Abstract Model) that is intended to be used in the
context of the DC Abstract Model and/or RDF. And, as a rule of thumb, I'd
suggest this means that the semantics of this property should be declared
using RDFS (as per all the current DC terms).
(*) Note the rather odd URI here caused by the mods namespace URI not
ending in either a slash or a hash - I hope I've got this right. If not,
> but it you want to be able to use
> without wrapping it in <mods:location>, there's an easy way.
> The mads schema has the same problem, so we've created a "mods-for-mads"
> schema. It's totally compatible with the current mods (they produce
> identical instance sets) but a number of new data types have been created
> (url one of them) so that they can be directly referenced.
> Take a look at
> It references mods url as:
> <xsd:element name="url" type="mods:urlType" .....
> And look at
> It declares element <url> within <location> as
> <xsd:element name="url" type="urlType" minOccurs="0" maxOccurs="unbounded"
> and creates a new definition urlType.
> So you could reference it as mods:url, You'd just need to change the
> schema location:
> <xsd:import namespace="http://www.loc.gov/mods/v3"
> schemaLocation="http://www.loc.gov/standards/mads/mods-for-mads.xsd" />
> Mads is still a draft. Our intention is to issue a new mods version (3.1)
> that includes these definitions, sometime after (or when) we release the
> first version of mads.
> We would be happy to include any other similar definitions in mods 3.1, if
> it makes sense to. (It was once suggested that we should treat every mods
> subelement in this fashion. I'm fairly sure we don't want to do that,
> because (1) it doesn't make sense in every case, and (2) it would create a
> much-less-readable schema.) For example, edition and dateCaptured of
> originInfo. If you'd like I'll change mods-for-mads so that these can be
> referenced (even though mads doesn't reference them currently) or any
Distributed Systems, UKOLN, University of Bath, Bath, BA2 7AY, UK
http://www.ukoln.ac.uk/ukoln/staff/a.powell/ +44 1225 383933
Resource Discovery Network http://www.rdn.ac.uk/