A simpler format for OLAC vocabularies and schemes

[Gary Simons]

Martin,

This is a good question.  Let me take a stab at answering:

>If I understand correctly, the proposal is to move from:
>
>     <title>Orginal title</title>
>     <title refine="alternative">Translated title</title>
>
>to:
>
>     <title>Original title</title>
>     <dcterms:alternative>Translated title</dcterms:alternative>
>
>I've checked with the relevant DCMI website and this does indeed seem to
be
>in conformance with their recommendations. Now perhaps in that case I
should
>take this up with the DCMI and not with OLAC... What I can't see is why
the
><dcterms> element is neither embedded in the <title> element, nor
identified
>as a type of title element (as in OLAC 0.4).

First, let me make sure everyone understands what dcterms is.  It is the
namespace for all of the refinements defined in the DC Qualifiers
recommendation. Thus, there is also:

<dcterms:hasPart>A qualified Relation</dcterms:hasPart>
<dcterms:temporal>A qualified Coverage</dcterms:temporal>
and so on

> To put it bluntly, a human
>can't see what it is an alternative type of, since it is not tagged in any
>obvious way as a title. Does this require that "alternative" be defined
>(somwhere?) as a type of title? And in this case, shouldn't it be called
>"alternativeTitle" or something more transparent?

It is quite true that the XML file gives no clue as to the corresponding
non-qualified element.  However, there is no ambiguity since each DC
refinement is defined to occur with only one DC element. That is,
<alternative> is defined to be a refinement of Title and nothing else,
<temporal> of Coverage, and so on.  The mapping problem is solved in
implementation by adding a table of refinement to non-qualified element
pairs to the harvested metadata database.  This allows a service provider
to "dumb down" the tags in the dcterms namespace to their dc equivalents.
The standard OLAC harvester will have this built in.

>Up to this point I am heartily in accordance with the suggestions for
>simplifying the formats. I agree that syntactic conformance with DC is a
>good thing, but they now seem to be going down a road which aims to
flatten
>out any hierarchical organisation of the data classification, and makes
>human readability of the XML impossible.

Note that the hierarchical organisation is in the classification scheme,
and not in the data itself.  That is why it is appropriate for data
encoding to be "flattened".  There only needs to be one instance of the
classification hierarchy (e.g. the database table I mention above, or the
DCMI's RDF schema for dcterms), and a flattened tag can be looked up in
that hierarchy rather than repeating the refinement-to-element mapping in
every instance of the refinement.

>Further apologies if I've got the wrong end of the stick here by coming in
>belatedly to the discussion.

I hope that makes sense.

-Gary