Quoting "Rebecca S. Guenther" <[log in to unmask]>:

> Pete and Andy had agreed (as part of Usage Board work) to put together a
> paper explaining better what this means, why MODS elements cannot be used
> as RDF properties, and what needs to be done to be able to reuse MODS
> elements. After all, those that are referenced in the DC-LAP are exactly
> the semantics that were needed for the given element. I still don't
> understand this completely.

Yes, and my apologies that I haven't done this. I said to Andy and Ann that I'd
try to get something done over the weekend and circulate it next week.

[snip]

> Some of the MODS elements have equivalent DC elements. I suppose any such
> subset would be those that are needed by an application profile?
>
> In the case of Relators, we have an RDF expression of the whole list (as I
> said above, generated on the fly) and only a subset has the statement that
> it refines dc:contributor. We would need some guidance on how to do
> this. Or perhaps there are tools to convert an XML schema to an RDF
> one?

No, this can't be done, or at least not in any generally useful way.

An XML Schema describes the structural constraints on a class of XML documents -
it describes the XML tree structure, the "content models" for XML elements and
XML attributes, which XML elements can be contained within which other XML
elements and so on.

An "RDF Schema" (there's a camp that argues we shouldn't even use that
terminology because of the confusion it causes ;-)) describes classes and
properties and relationships between them.

They aren't alternative representations of thesame information - they are
completely different things

As I was trying to say in my message last night, XML works with a hierarchical,
container-based model - so in MODS, elements have attributes and
child/sub-elements - but RDF is based on triples, simple "statements" asserting
relationships between resources.

As Andy said, both models are good and useful, but they _are_ different, and the
"components" in an XML document are completely different things from the
"components" in an RDF graph.

> > In my view we should be looking for solutions to help us meet requirements
> > of several user communities, and to move forward as regards the evolution
> > of data element sets by allowing re-use of data elements. If this can be
> > done by declaring sets of terms in RDFS then good....
>
> Right, and this was the basis I think of Rachel's famous paper about
> mixing and matching elements in different metadata schemas. Why redefine
> something that has the same semantics if there's a way of just cooperating
> instead?

Yes, "mixing and matching" is a Good Thing _if_ the things which are mixed and
matched are appropriate for "mixing and matching" ;-)

But trying to mix and match things which are in fact very different (because
they have been defined/created in the context of different models/frameworks)
simply doesn't work. (Over on dc-architecture, I used the analogy of Lego
bricks and Meccano parts - both good and useful in their own context, but if I
try to use them together, it doesn't work - my Meccano parts won't click and my
Lego bricks can't be bolted).

Unfortunately our rather loose use of terminology - particularly words like
"element" - has (IMHO) tended to encourage us to see similarities between
things which are in fact very different. (The work on the Abstract Model is one
means of trying to clarify this - we can now use that as a point of reference.)

In many cases it is better - indeed, absolutely necessary! - to define _new_
components which are appropriate for the different context of use - as indeed
has been done in the case of the RDF properties that represent the MARC relator
codes.

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/