[eml-dev] EML 2.1 release coming soon- draft

[Christopher Jones]

Inigo,

On Apr 2, 2008, at Apr2---5:01:50 PM, inigo wrote:
> So <describes> (eml:eml/additionalMetadata/describes) is
> fundamentally important, you argue. Why is <describes>
> optional ?

Early in the development of EML, the core developers placed a lot of  
emphasis on the extensibility of metadata languages, and the EML  
2.00beta* releases were all based on RDF-like triple constructs in  
order to cross-reference EML modules and documents, and to provide an  
extensible framework.  RDF was in it's infancy at the time, and is a  
tough to grasp hold of as well, and so the various EML developers in  
the community decided to forego some of the flexibility of the RDF- 
style modules and opted for a simpler, hierarchical EML schema.  In  
order to maintain an extensible framework in EML, the  
<additionalMetadata> tag was added, and the <describes> tag used to  
bind content to various locations in the EML tree.  So, from an  
extensibility standpoint, <describes> and <additionalMetadata> are  
fundamental to EML.

> It is an element barely used in LTER,  and I
> don't recall a strong push in LTER best practices for its use.
> (Then again, by the time we get to the last page of the
> best practices, we are pretty overwhelmed with advice)

I think it's good to remember that EML is a specification developed by  
the *ecological community*, with the LTER Network being one component  
of that larger community. The LTER 'Best Practices' have been  
developed within the LTER to help guide the network in producing EML,  
but it is by no means part of the specification.  Other groups will  
benefit from the experiences of the LTER in using EML, and vice versa.

> The describes element is the metadata placeholder for metadata
> that did not fit anywhere else in the metadata document. The
> content there could be so generic that It would be difficult to
> make good use of it other than human reading. There are exceptions,
> of course (STMML)

Actually, it's not.  <additionalMetadata> is the container used to  
provide a moderate level of extensibility in EML, as noted above, and  
the <describes> tag is the mechanism used to bind the additional  
content to other locations within the EML tree.  The <describes> tag  
is optional because an EML author may *not* want to bind content to  
another location in the tree, but rather just provide additional  
metadata in a structured format that a parser that can handle (likely  
a parser that understands a superset of EML, for instance a markup  
language developed for soils metadata that is highly domain specific  
and added to the addtional metadata section.)

> I would say that
> the "unexpected" content in <additionalMetadata> will be primarily
> to save us from information loss, and sometimes, we use to plug
> in other schemas (such the STMML/custom unit consensus workaround).
> Perhaps other specify <access> rules there, (not sure why).

Please read the EML 2.0.1 specification. Access control rules in  
Section 2.4.1 state:

"Exceptions for particular data components of the package can be  
controlled at a finer grain by using an access description in the  
<additionalMetadata> element that points at a particular  
<distribution> element by referencing its unique id. An access control  
document may be defined, or referenced, from this location, and the  
<describes> element is used to point to the distribution that is to be  
controlled via its "id" attribute."

You seem to be lobbying for the removal of the <describes> tag, which  
is integral to maintaining separate access control rules for both  
metadata and data components of an EML package.  In my opinion, this  
would be a step backwards.  There are recognized and documented  
problems with the access control constructs in EML, and possible  
backwards-incompatible fixes are described in Bugzilla, but a  
wholesale removal of <describes> would be detrimental to the current  
access control functionality.

> However, it is still "optional". So, automated parser
> and semantic apps relying on <describes> content will be ill-fated
> with the schema as is. Enforcing the use of <describes> at the
> recommendation level ( that is, best / common practices) is all we
> have now.

Actually, the rules governing the use of the <describes> tag is  
strictly enforced by the applications that employ the EML parser (for  
both EML and XML validity).  You may want to ask Chad and Matt about  
how the parser enforces the rules - they wrote the EML parser.

> So, as it is, it is not much different from taking <describes>
> out of there. <xs:any> does not preclude the use of <describes>.
> May be it ought to be mandatory, we did it so in one EML-2.0.2
> candidate. Later, we proposed this other solution because of the
> backward compatibility problem, and also, because we did not need it.
> Perhaps, part of the reason is not used is because in practice, we
> have been forced to remove it from the EML schema due to its
> problematic nature.

If you plan to lobby for the removal of the <describes> tag, you must  
replace all of the functionality that it provides (described above and  
more) with other constructs without sacrificing the fundamental  
feature of EML: extensibility.  EML is not perfect by any means.  The  
community will likely move on to more semantically-oriented languages  
in the future, but the features that were designed into EML have  
catapulted groups within the ecological community out of free-form  
text descriptions, proprietary binary file descriptions, and/or no  
descriptions at all.

Thank you to all of those that toiled over the current version of EML,  
and those who are toiling over future versions now.

Chris
_________________________________________________________________
christopher jones       cjones at msi.ucsb.edu      (805) 680-5946
marine science institute  university of california, santa barbara
_________________________________________________________________

> cheers, inigo
>
> ps: im sending this to the eml-dev list per Matt request.
>
>
> Matthew Jones wrote:
>> <describes> is a fundamentally important field.  It cannot be removed
>> without significantly reducing the functionality of the
>> additionalMetadata section.  We use it for annotations of many points
>> in the schema.  It is also the primary mechanism being considered for
>> attaching semantic annotations to eml attributes.  So I would  
>> strongly
>> resist such a change.
>>
>> BTW, this discussion should be occurring on eml-dev.  Please forward
>> it there so all EML contributors are aware of it.
>>
>> Matt
>>