I'm forwarding a message from the dc-libraries list here, since it touches
on an important architectural principle - namely, that you can not simply
take an 'element' from an existing XML-based language like MODS or LOM and
expect to be able to use it in a DC description. The fact that something
exists as an XML Qname is not sufficient for it to be used as a property
in DC.

Owners of such terms have to explicitly acknowledge that the terms are RDF
properties (or at least declare them in such a way that they are able to
be treated as RDF properties) before they can be used in DC application
profiles. In practice, I suggest that this means that the semantics of
these terms should be declared using RDFS.

Pete Johnston sent a follow-up to my message which explains this
further...

--- cut ---
Yes. The real underlying problem is with the DC Libraries Application
Profile.

It references DC "elements" and MODS "elements" as if they are the same
type of thing, when in fact they are fundamentally different because (as
Andy says) they are defined in the context of two different data models:
DC "elements" are properties, and are defined in terms of the
statement/triple-based DC Abstract Model and RDF data model; MODS
"elements" are components in a hierarchical data structure, and their
interpretation is defined in terms of that hierarchical data structure.

(And so it follows for example, that concepts like element containment
("sub-element", "child element"), which makes perfect sense in the
hierarchical model, have no meaning in the DCAM/RDF models; and conversely
notions like element refinement (subproperty) which is well defined in the
DC/RDF models, have no place in the hierarchical model).

Any DC Application Profile has to be based on a single underlying data
model, i.e. on the DC Abstract Model. The "mixing and matching" has to
take place within the context of that framework, and this sort of
"cross-model" hybridisation can not work.
--- cut ---

As an example of how this can work I would cite the MARC relator terms -
where the Library of Congress have taken (are taking?) the time to
explicitly re-declare an existing set of terms as RDF properties.
Because this has been done, it is now (or very soon will be) possible to
use the MARC relator terms in a DC application profile and for that usage
to be maningful in terms of the DCMI Abstract Model.

Andy
--
Distributed Systems, UKOLN, University of Bath, Bath, BA2 7AY, UK
http://www.ukoln.ac.uk/ukoln/staff/a.powell
tel: +44 1225 383933 msn: [log in to unmask]
Resource Discovery Network http://www.rdn.ac.uk/

---------- Forwarded message ----------
Date: Wed, 9 Feb 2005 23:59:49 +0000
From: Andy Powell <[log in to unmask]>
Reply-To: DC-Libraries Working Group <[log in to unmask]>
To: [log in to unmask]
Subject: Re: XML schema

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,
apologies.

Andy.

> but it you want to be able to use
> <mods:url>http://example.org/myurl</mods:url>
> 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
> http://www.loc.gov/standards/mads/mads-preliminary-draft-2-dec-17.xsd
>
> It references mods url as:
> <xsd:element name="url" type="mods:urlType" .....
>
> And look at
> http://www.loc.gov/standards/mads/mods-for-mads.xsd
>
> 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
> others.
>
> --Ray
>

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