[OAI-implementers] metadata formats - supporting multiple versions

[Kyle Fenton]

This line of inquiry is very intriguing to me also.   If I wanted to  
server out more domain specific data types (EAD, DDI, TEI) and/or just  
the metadata headers from those formats I haven't found any reference  
examples to know how to form a metadataPrefix that others share as  
well (oai_ead-h ?).   I've long wished there were a central online  
registry of existing metadataPrefixes, schemas, and metadataNamespaces  
for repository interoperability.   Versioning of schemas adds another  
layer of complexity to the issue.

When I was at the OAI-ORE rollout in Baltimore recently, I did ask  
Herbert van de Sompel about "minting" new metadataPrefixes.   It was a  
brief exchange as he was quite busy, but if he understood my question  
and I his answer, he places heavy emphasis on the particular schema  
being referenced and much less on the metadataPrefix.

If that's true, then the burden would be on the OAI harvester to  
correctly parse and interpret the referenced schema in order to  
determine what metadata format was being referenced.   Which no  
existing OAI harvester I know of actually does, AND which would not  
work consistently anyway, e.g. with reference to versioning.   The  
Marc21 slim xsd (http://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd 
) for instance makes use of a version attribute in its xsd:schema  
namespace, but I notice that none of the mods schemas use a similar  
convention.

--
Kyle Fenton
Technical Manager
Emory University Libraries

On Mar 31, 2008, at 9:54 AM, Gary McGath wrote:

> Riley, Jenn wrote:
>> Hello all,
>> We're growing our OAI-PMH data provider to the point where we need  
>> to simultaneously support multiple versions of a metadata schema,  
>> for different sets that have been created over time using different  
>> versions of a schema.
>> We're finding this to be an issue specifically with MODS (although  
>> the principles would apply for any metadata format that's evolving  
>> over time). According to the UIUC OAI-PMH Registry at <http://gita.grainger.uiuc.edu/registry/ListSchemas.asp 
>> >, the metadata format "mods" is used to refer to three different  
>> versions of MODS in different repositories:
>> http://www.loc.gov/standards/mods/v3/mods-3-0.xsd
>> http://www.loc.gov/standards/mods/v3/mods-3-1.xsd
>> http://www.loc.gov/standards/mods/v3/mods-3-2.xsd
>> Since the ListMetadataFormats response includes both a  
>> metadataPrefix and a pointer to a specific schema, I'm concluding  
>> that we can't use the same metadataPrefix to refer to different  
>> versions of the schema for different sets. Is that correct?
>> Within the various MODS 3.x versions, we *could* just call all the  
>> earlier versions by a newer version number when it comes out, since  
>> they're supposed to be backwards-compatible within the major  
>> release version. But saying a MODS 3.0 record is MODS 3.2 implies  
>> we've done the work to use some of the (very useful!) new features  
>> of MODS 3.2, when in fact we haven't. And given the realities of a  
>> production environment, we won't be able to spend the time to  
>> upgrade all the existing MODS records whenever a new set wants to  
>> take advantage of a feature in a newer version of MODS. Also, this  
>> fake upgrading approach wouldn't work when a new major release  
>> version comes out that's not backwards compatible. Based on all of  
>> this I'm thinking we need different metadataPrefix-es for different  
>> versions of the schema.
>> I'm not seeing in the UIUC registry any good examples of versioning  
>> a metadataPrefix that I could follow as a best practice, though.  
>> The only metadataPrefix-es listed there that seem at first glance  
>> to be versioned are junii vs. junii2, but I'm not familiar with  
>> those schemas so I can't say for sure that's what they're trying to  
>> do.
>> So what would be the best way to create "versioned" metadataPrefix- 
>> es? Something like mods_3.0, mods_3.1, and mods_3.2? Has anybody  
>> thought through these issues enough that there's a model we could  
>> follow? There's nothing on the DLF/NSDL OAI Best Practices page on  
>> namespaces and schemas <http://webservices.itcs.umich.edu/mediawiki/oaibp/index.php/NamespacesAndSchemas 
>> > that addresses this specific issue.
>> If we were to use different metadata prefixes, would this cause big  
>> problems for service providers trying to use this metadata? Or is  
>> there a way to do this with a single metadataPrefix I'm not  
>> thinking of?
>
> Interesting question, and one that could be relevant to us here  
> (though currently we've just picked one schema). If there were, say,  
> an incompatible upgrade to MODS 4, I could see wanting to support  
> both the old and new MODS for a while till everyone was up to speed  
> on the new version.
>
> I think going with different metadata prefixes would be the only  
> solution, but don't know of any standard nomenclature. In theory it  
> shouldn't matter what prefix you use, since XML considers the  
> namespace prefix just a pointer to the schema. But since the prefix  
> is what the harvester actually uses, consistency would be nice.
>
>
>
> -- 
> Gary McGath
> Digital Library Software Engineer
> Harvard University Library Office for Information Systems
> http://hul.harvard.edu/~gary/index.html
>
>
> _______________________________________________
> OAI-implementers mailing list
> List information, archives, preferences and to unsubscribe:
> http://www.openarchives.org/mailman/listinfo/oai-implementers
>
>