status of EML 2.0

[Ken Ramsey]

Peter, Chad, Matt, et all;

I have made comments on EML beta 9 and have not seen any discussion
related to them other than some points that may have come up in the
recent flurry of emails in response to Peter's email, so I am probably
going to restate many of them below.

I have very strong feelings on what EML should encompass and how it
would be most useful to the Jornada LTER and the mapping/querying
application we are currently having developed by ESRI. Our application
will be developed with EML in any case, but the application has the
promise of being much more useful and powerful to the community at large
if some of my (and others) suggestions are implemented within EML 2. I
think that EML is extremely important and that the release of EML 2
should not be rushed to the point that its usefulness is diminished.

1. URL connections: 
I agree with Peter in that some level of connection information is
needed beyond documenting simple URLs. I believe the power in describing
SQL, ODBC, or JDBC connections within EML is that it would support
application development such as our project is currently developing. The
ability to develop an application that can query EML to determine
database structures and connection information for associated research
data and to then dynamically build and execute queries would greatly
benefit the ecological research community at large. The alternative is
to develop query builders within applications locally that are tied to
specific local database schemas. This would negate much of the reuse of
code for future EML driven application development. If the purpose of
EML is to simply describe metadata and support querying of metadata,
what is the long-term usefulness of EML for higher level application
development?

2. Responsible Party:
I agree with Karen that responsible party should be at the same level
as dataset, protocols, and citations. I also agree with Matt that beta 9
allows linking responsible party to a personnel directory. However, I
would much rather update a responsible party module than try to maintain
responsible party information within all dataset modules that a person
is associated when some part of the contact information changes. The
responsible party module could be referenced from within any number of
dataset (or other) modules without having to update or maintain all
contact information within associated dataset modules. I guess this is a
maintenance issue, but I think it is important for the long-term
usefulness of EML.

While I do not think that EML should cater to every sites needs in
tracking personnel, I do think that it would be useful to have the
ability to associate coverage (temporal) to responsible party. If a
study that is described in EML has been completed, how can a user
determine if the contact information is reliable or current? I think it
is necessary to associate dates (and ranges) with a person. It would
also be useful if there where some way to determine whether the contact
information is up-to-date and the person's status (active, retired,
deceased). Perhaps a IsValid flag or a LastUpdated date field and a
CurrentStatus field could serve this purpose?

3. Coverage:
It would be valuable to add a DateType flag to the singleDateTime
element to allow classifying a date as 'ongoing', for example. I believe
Karen brought this up, too.

4. Dataset:
Add protocol element under Dataset. Datasets should allow referencing
other datasets if this is not already possible. Add flag to denote
whether a dataset is ongoing or closed. I have mentioned one way of
doing this above under Coverage.


5. Research Project:
Add protocol element under ResearchProject. As Peter brought up,
Project should allow recursive referencing to other Projects.

6. Entities:
I feel that there is a need for another entity type of ImageRaster to
describe non-georeferenced aerial photographs, photos, and videos unless
this is already possible and I just missed it.

I think that DataTable should be able to fully describe row, column,
and record level constraints fully, if not already possible. I have not
had time to go over this entity type, but in reviewing the AttributeList
I can see that not all of these constraint types are addressed.

I also think that precision needs work within AttributeList to better
describe precision instead of limiting it to significant digits.

I will stop here because I think some of these types of concerns will
drag down the discussion, but I mention them because many of these
points where brought up at the last LTER EML Workshop in a working group
break out session. I would like to restate that I would like to be
included in the conference call. I will be available as needed.

Ken


----------------------------------------
Ken Ramsey
Data Manager
Jornada Basin LTER Project
New Mexico State University
Wooton Hall, room 209
Knox Street and Frenger
Box 30003, MSC 3JER
Las Cruces, NM 88003
(505)646-7918 (office)
(505)646-5665 (fax)
keramsey at nmsu.edu