status of EML 2.0

[Tim Bergsma]

Greetings all.

Brief reaction to Peter's comments...

Regarding item 4.  While my thinking is no doubt somewhat muddled, it
has been haunting me recently that at my site, the best URL for any
given data set depends on whether you are a machine or a person.  So
which URL do I specify in the EML documentation?  I'm hoping this
question is related to Peter's item 4.

Regarding the list of suggested changes, I really like the idea (not
surprisingly) of formally distinguishing between methods and protocols. 
(But can steps have sub-steps?) The idea of distinguishing between
'project' and 'researchContext' sounds promising for preventing
inconsistent use of the current specification.  I don't have a strong
opinion on when the changes should happen, but I'm biased slightly in
favor of completeness rather than timeliness.

Regards,

Tim.

> Peter McCartney wrote:

>...
> 4) The decision to record online distribution only using URLs and only
> as stateless pointers to a single opaque object will, I fear, force us
> to seriously limit the role of EML in the future development of a web
> service based network. The fact that URLs are at best awkward and at
> worse not useable for expressing some types of connections is one
> thing, but it is the lack of support for describing a stateful
> connection that bothers me most. Many LTER sites, not just CAP, are
> attempting to build internet applications that are metadata driven and
> provide an interface (either direct or web service based) to data
> stored in many different systems including SDE, SQL, ascii files and
> various GIS and hyperspectral formats. While few of us intend to give
> out the stateful connection information to end users directly, many of
> us would like to see the development of server-side tools follow some
> standards so that we might all better share software components.
> Without a standard in EML for describing connection information in a
> usable format, the result is adminstrators are force to still develop
> local solutions and then figure out how to relate them to EML. I'd
> hate to see EML perceived as useful for enabling outside institutions
> to build applications around site data but not very useful for sites
> in building their own applications.

> ...
> If I were to suggest changes to Beta9 to best address these responses,
> they might go something like this. I would change eml-project to be
> predominantly a research project description including stafffing,
> funding, publications, and links to higher level projects.. I would
> also leave eml-protocol as a resource module, but make it
> predominately text based and prescriptive, used only when a prodedure
> has been formally worked out and used by many datasets. I would make a
> new module called methods, which i would use in every place that we
> now use protocol. methods would contain a repeatable methodStep
> element, which in turn would include references to source datasets
> (type eml-dataset), software (type eml-software), instrumentation, and
> any QAQC procedures that can be logically related to those steps.
> Methods would also include optional links to eml-literature and
> eml-protocol as references to formally published or cataloged
> prodedures.  I would create a new module researchContext in which i
> would include the methodological descriptors that directly qualify
> this dataset like site description, sampling, and the above methods
> module. Finally, for QAQC information that arent described under
> methodology but are directly related to specific attributes in the
> data, I would suggest using the data-quality module (in its current
> incarnations as attributeAccuracy, horizonalAccuracy and
> verticalAccuracy) should be used as the mechanism for describing both
> data quality and the various control/assurance procedures used to
> arrive at that quality.

> 
> Peter McCartney (peter.mccartney at asu.edu)
> Center for Environmental Studies
> Arizona State University
> 480-965-6791

-- 
Tim Bergsma
LTER Information Manager
W.K. Kellogg Biological Station
Michigan State University
Hickory Corners, MI   49060
616/671-2337
tbergsma at kbs.msu.edu
http://lter.kbs.msu.edu