EML questions at HFR

[Peter McCartney]

well there are those that would argue that once published, EML content
shouldnt be allowed to change automatically according to changes in a
current management database. But there are two sides to the coin. When area
codes change (as they do in Arizona every 5 years or so), you dont want all
your data contacts broken. However, as project participants work their way
up the hierarcy, you dont want their roles on past projects to be changed to
reflect thier roles on current ones. So its really an issue for everyone
deciding when and when not to update information in EML. 
 
 
Peter McCartney (peter.mccartney at asu.edu <mailto:peter.mccartney at asu.edu> )
Center for Environmental-Studies
Arizona State University
 

-----Original Message-----
From: Emery R. Boose [mailto:boose at fas.harvard.edu] 
Sent: Sunday, April 06, 2003 4:32 PM
To: Peter McCartney; 'David Blankman'
Cc: Iml; Eml-Dev (E-mail); Jeanine
Subject: RE: EML questions at HFR


Hi Peter & David,

Thanks for such rapid and helpful responses!

Sounds like synchronization may be a critical issue for those intending to
use EML for content storage (and not just exchange) ...

Best, Emery


At 03:04 PM 4/4/2003 -0700, Peter McCartney wrote:


what we were striving for in eml was to ensure that there was a place to
describe the research activities that were directly responsible for the
production of a dataset. in my opionoin a core area program or an LTER site
project is probably a related project to the specific project. But from the
data management workshop, it became obvious that many sites dont have this
concept of specific research projects, so we removed the methods discussion
from the project descpription to ensure that the specific activites related
to this dataset could be expressed even though they were not part of the
project description.So the bottom line is describe the smallest resolution
research activity as the project, and then link related project descriptions
for any "parent" projects.
 
 
EML requires that the original content for any block of information that is
referenced with <references> must appear once in the document. That means
that if you want to have a unique list of content items that you only have
to enter once, you must manage that list separately and then draw from it
when you creat your eml files. one obvious way is to have a database of
these things (for example - you already have the LTER persBIB database from
which you could draw personnel descriptions) and then write some tool that
pastes that content into your eml files as you build them up. another way
would be manage an xml file with party fragments in it as you describe, and
copy and paste from that into your eml files as you go. there is really no
effective way to maintain the syncronization between your eml files and the
external source. the system and scope attributes can be used to indicate
that this content is identified in an external source, but you'd have to
write your own custom software to manage the relationship. We're discovering
that this can lead to key violations since the xml parsers dont consider the
scope attribute when enforcing the unique constraint on ID's, so we're now
looking at writing our own metadata into additionalMetadata to manage the
relationship between content blocks and our relational database.
 
you can enter discontinuous polygons in geographic  coverage if you want to
represent the study ares of two lter sites as the study area of a project.
Bear in mind that geographic coverage at the resource level is primarily
discovery information. there is a separate section under methods where you
can define the extent of your study area with respect to its spatial
sampling universe. In principle these are the same, but entries in
/dataset/coverage tend to be imprecise bounding boxes  
 
 
Peter McCartney (peter.mccartney at asu.edu <mailto:peter.mccartney at asu.edu> )
Center for Environmental-Studies
Arizona State University

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20030407/6ed10be4/attachment.htm