[eml-dev] obsolete EML tags ?

inigo isangil at lternet.edu
Fri Sep 19 09:49:27 PDT 2008



Thanks for placing me in such position, but no... on the contrary, I am 
just suggesting what I see as possible changes on EML based on community 
feedback.  Start a dialogue. Contemplate change for the better. I say no 
to "more of the same" -what a crazy thing.

inigo

Corinna Gries wrote:
> Inigo,
>
> You are really in EML bashing mode, aren't you?
>
> I would like to rescue a few of these tags here. I am using the <view>
> tag and actually really need it to break down large databases into
> reasonable datasets. And when we get into these ODMs and variants
> thereof, the view will be the way to define a dataset in EML.
> I have all our protocols in <protocol> and if we ever get to some sort
> of LTER protocol catalog/registry that should be the way to go. I think
> this as well as <software> is not used much because everybody is busy
> (struggling) keeping up with the datasets - we'll get there.
> I agree that <citation> needs some work and probably should become some
> citation collection, i.e. allow many <citation> to be used in one file
> to be useful. I think that has been discussed.
>
> My two cents
> Corinna
>
> -----Original Message-----
> From: eml-dev-bounces at ecoinformatics.org
> [mailto:eml-dev-bounces at ecoinformatics.org] On Behalf Of inigo
> Sent: Friday, September 19, 2008 9:20 AM
> To: eml-dev
> Subject: [eml-dev] obsolete EML tags ?
>
>
>
> more for the record.
>
> The use and adoption of the EML probably has not peaked yet, but one can
>
> argue that is never to soon to revisit obsolete parts of the standard.
>
> I am sure that long discussions and thorough design plans that were 
> approved unanimously ensued when placing atop of the EML hierarchy items
>
> like "software", "citation" and "protocol".  After some time,  people 
> has used the EML in telling ways. 
>
> In my view, the following are clear candidates to be deemed obsolete. 
> <software> :  /eml/software  - No one at LTER+Pisco is using the 
> "software" tag - top of the EML hierarchy-. 
> <view>   :   /eml/dataset/view - One LTER site used in one instance the 
> <view> tag - what's up guys,  no one willing to describe database views?
> <storedProcedure> : /eml/dataset/storedProcedure.   No one is using this
>
> at LTER+ObFS+Pisco.  If you need it, take it home, it's screaming for 
> shelter.
> <series> : /eml/*/series - This element may have been adopted via the 
> FGDC - There is one LTER site that used it 14 times.
> numerous elements within "physical". (size, maxRecordLenght, 
> encodingMethod, numPhysicalLinesPerRecord,caseSensitive,aunthentication,
>
> characterEncoding). - Some of these, NEVER used, and some sparingly
> used.
> some elements under <distribution>. there is talk to add <access> under 
> here (or was it upstream?). However, how about deprecating those 
> dinasour-age elements? compression... offline.. why tease people saying 
> that you have data, but not willing to share it ? if you do not want to 
> share it, why mention it. too large? no dataset is too large.  even 
> Comcast still allows internet traffic of the order of 250Gb/month/user. 
> /distribution//connection is not popular either. 2 sites use it 
> sparingly, i actually helped promote the use of this particular element 
> for one of these sites. but im open to change that..
>
> Other elements may not deserve being deprecated, but certainly will not 
> win any EML popularity contest: Here are some.
>
> <protocol> : /eml/protocol/   Three (two of those coordinated from the 
> same team) LTER sites use the "protocol" tag.   I know there was some 
> discussion here to revamp this tag.  a chaneg now will not affect many, 
> it seems.
>
> <citation>  : /eml/citation/   Four sites use this, two of these 
> sparingly.  This tag has been discussed, and there was some sound 
> silence in eml-dev (surprise) but it would seem that a change (like the 
> one pursued by Servilla and OBrien would do some good to some. 
>
> Im sure there are more tags alike. we can discuss also the 
> spatialVector/Raster complex groups. or not.
>
> cheers, inigo
>
>
> _______________________________________________
> Eml-dev mailing list
> Eml-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev
>   



More information about the Eml-dev mailing list