EML versioning

Matt Jones jones at nceas.ucsb.edu
Wed Feb 18 18:15:17 PST 2004


A few minor notes...

David Blankman wrote:
> Hi David,
> 
> I've got a quick question on EML document versions. Should all versions of a 
> document be available (like cvs) or only the latest one?
> 
> -- Sven Bohm (KF8A)
> 
> 
> 
> Sven,
> 
> There is no simple answer to that question. In order for you to get a 
> broader perspective, I am copying the metacat and eml lists and the IM 
> list. My aplogies to those of you who may get multiple copies.
> 
> I am answering your question from several points of view. Hopefully one 
> of the answers is the one to the question you actually are asking.
> 
> Here is the way metacat handles versioning (this is a simplified 
> explanation as there are other tables involved):
> 
>    1. Say there is an eml document in metacat with docid kbs.1.1
>    2. You make some changes and decide to insert kbs.1.2
>    3. Metacat deletes the references to kbs.1.1 from the active table
>       XML_DOCUMENTS and then does an insert into the XML_REVISIONS table.
>    4.  kbs.1.2 is then placed into the XML_DOCUMENTS table.
> 
> There are no public tools that are designed to query the XML_REVISIONS 
> table, so for all practical purposes, the older documents are inaccessible.
Not strictly true.  Morpho includes a feature for seeing older versions 
of a document.  And metacat will return an older version of a document 
upon a read request.  The only real difference in Metacat between 
XML_DOCUMENTS and XML_REVISIONS is that the old revisions are not 
searched when someone sends a query.

>  >From an archival perspective, the question you ask is similar to the 
> question: how much rollback capability to you have/want/need in your 
> source database.
> 
> The more dynamic your metadata, the trickier the versioning issue is. 
> Since you are generating eml dynamicly, the issue of versioning is 
> important, as I see it, only in a metacat sense. If your eml is 
> harvested, then the docid of scope.identifier.version in the 
> "harvestDocument.xml" determines whether there is a new harvest or not. 
> If your docid says kbs.1.1 and kbs.1.1 is already in the metacat, then 
> there will be no new harvest even if the content of kbs.1.1 has changed.
> 
> The other question is -- when does dynamicly generated eml become a new 
> version.  If you have remote sensing data with daily or hourly updates, 
> and your temporal coverage is generated by querying a data column in a 
> data table, then from one point of view, you have a new version daily or 
> hourly. When Barbara Benson and I discussed this issue, she decided that 
> they might generate a "new version" quarterly or semi-annually or in 
> some cases annually depending on the kind of data.

I agree with David's assessment here.  There's no simple way to treat 
dynamically modified data from a relational database.  The only 
practical advice is to recommend that you increment the revision number 
any time you want the record to be re-harvested from someone outside of 
your system (like the metacat harvester).

Matt

> Let me know if the question you were trying to ask was different from 
> any of the ones that I answered.
> 
> David
> 
> 
> 
> 
> bohms at msu.edu wrote:
> 
>>Hi David,
>>
>>I've got a quick question on EML document versions. Should all versions of a 
>>document be available (like cvs) or only the latest one?
>>
>>-- Sven Bohm (KF8A)
>>
>>  
>>
> 
> -- 
> David E. Blankman
> EML Integration Developer
> Long Term Ecological Research Network Office
> University of New Mexico
> 801 University, SE #104
> Albuquerque, NM 87106
> (505) 272-7346 / (505) 272-7080 FAX
> 

-- 
-------------------------------------------------------------------
Matt Jones                                     jones at nceas.ucsb.edu
http://www.nceas.ucsb.edu/    Fax: 425-920-2439    Ph: 907-789-0496
National Center for Ecological Analysis and Synthesis (NCEAS)
University of California Santa Barbara
Interested in ecological informatics? http://www.ecoinformatics.org
-------------------------------------------------------------------



More information about the Eml-dev mailing list