On Wed, 9 Feb 2005, Andy Powell wrote:
> 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.
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.
Pete
|