[OAI-implementers] metadata formats - supporting multiple versions

Gary McGath gary at hulmail.harvard.edu
Mon Mar 31 09:54:05 EDT 2008


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




More information about the OAI-implementers mailing list