EML discussion and conference call

[Peter McCartney]

For what its worth, here's my two bits since the last thing we want is
anyone to feel disenfranchised from this process. i think many of these
frustrations (and Ken's is by no means the only example) happen when someone
joins a process that has gone on for some time and is close to the end. For
a very long time, I have served as the conduit for both exposure to and feed
back from the LTER data management group. There was a clear sentiment
expressed early on that rather than have everyone getting involved
personally, this was the arrangement most preferred. Now, for better or for
worse (no, lets say its for the better!) we have a number of people jumping
into the game at the root level (jeez, look how much this stuff is affecting
my speech patterns.) The result is that some new players have not been
exposed to prior design drafts, histories of specific concepts, or the sheer
number of angles these issues get examined from. To be specific, i think the
confusion over reponsible party comes from a lack of exposure to the concept
of "resource" as we adopted it from Dublin core two years ago, combined with
a missunderstanding that an item of information must be a "resource" in
order to be searched independently. On the other hand, we have yet to come
to an agreement on how to efficiently describe parameters for service
connections, an issue that i can assure you will be resolved. The final
solution may not (wait, make that definately won't) be one that everyone
likes, but as with all features, it will have to do the job. With respect to
mapping applications, Ive tried pretty hard to ensure that there is spatial
support in the schema. Ive also paid very close attention to ESRI's
variations on the FGDC schema. Even though I chose to use open standards
definitions (GML, fgdc and ISO) rather than follow a single vendor's
definitions, the final content model is compatible with esri's development
tools - it just requires a little work to put it in their terms. 

The process of participating at the "root" does mean learning some rather
cumbersome and unfriendly media (eg bugzilla, cvs). While i personnally
think these tools get in the way of the conceptual design process, they
certainly do provide some benefits to the development process. For
individuals that dont want to get into it up to their elbows, the alternate
solution (and its a valid one) is to pick a voice that seems sympathetic
and communicate your ideas through them. Ive tried to serve that role for
the LTER data community - if ive failed anyone in that role, i apologize,
but im also not your only voice - there is James, David and Owen as well.

I dont think anyone is trying to make EML part of a proprietary scheme.
While we've all been evaluating eml against our own development projects, i
think its safe to say that there has been good resistance to including
features in EML that are there simply because they provide
application-specific information (although there are some in our ranks that
would secretly cheer if it didn't work with Windows). The downside is that
someone looks at EML in light of their own inhouse system or software and
invariably decides that it has an achilles heel with respect to some crucial
function. Ive learned that the solutions have generally come not from saying
"i need feature x" but rather "i want to be able to do function x - is that
something that EML should support and how".  There is a great deal that I
dont think should be directly driving EML, even though many things would be
made easier at my site if they were. Its a healthy process to look at lots
of applications in designing EML, but we have to accept that we can't make
it revolve around any one of them. 

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

> -----Original Message-----
> From: Chad Berkley [mailto:berkley at nceas.ucsb.edu]
> Sent: Tuesday, September 03, 2002 2:13 PM
> To: Ken Ramsey
> Cc: Eml-Dev (E-mail)
> Subject: Re: EML discussion and conference call
> 
> 
> Hello Ken,
> 
> I must admit that I was a bit taken aback by your email.  I have taken
> the morning to calm down and give you what I think is a resonable
> response.  Please do not take offense, as I have not meant to offend
> anyone with this email. I would simply like to set the record 
> straight.
> 
> I'm sorry that you have felt that our group is not open to 
> changing EML
> to meet your (or others' needs).  I assure you that this is not the
> case.  In fact, we have made substantial changes to EML just 
> since April
> to meet the needs of LTER sites as well as independent scientists that
> have given us feedback through the KNB REOT group.  I think your view
> that we are closed to change may be a misunderstanding on your part. 
> Several people, including myself, Matt Jones, Peter McCartney 
> and others
> have been working on EML for several years.  Matt, in particular, has
> been working on EML since 1997.  I have been working on it for 2 years
> now.  Peter has been working on it at least as long as I 
> have, probably
> longer.  Since we all have in-depth knowledge of the 
> progression of EML,
> we have all seen many of the same technical issues several 
> times in the
> development cycle of EML.  You are, in a way, seeing the very tail of
> the development and hence, it may seem to you that we are all 
> set in our
> ways and simply want to argue over the points that we want to argue
> about.  We are not being close minded, we just may have a better
> understanding of EML as a whole and what has already been tried in the
> past and thus,(I hope) what will work in the future.  I 
> assure you that
> any recommendation made is welcomed and it will be fully reviewed.  
> 
> I'm sorry if it seemed that your email was ignored.  It looks 
> like Tim's
> email made it into Bugzilla but yours did not.  Perhaps you could
> reiterate any of the points within that email that you think are still
> valid.  Really, the best way for us to track issues with EML 
> is through
> bugzilla.  It takes a bit more time to enter the bugs, but the product
> is much easier to deal with than an email that can be easily forgotten
> about.  Also, with bugzilla, you are guaranteed to get someone to look
> at your problem because it will send us annoying emails everyday if we
> don't.  
> 
> The manner in which we hold our meetings and phone conferences is
> exactly how all technical meetings that I have ever been a part of are
> held.  If you feel strongly about a point, you argue the 
> technical merit
> of your philosophy and the rest of the peer group responds with their
> opinions until some decision is made.  If you do not want to back up
> your recommendations with logical argument, then they are not going to
> make it into EML.  
> 
> I would also like to address the fact that we all have other 
> projects to
> work on.  In the past, I have been involved with up to 3 different
> programming projects besides EML.  Others have even more of a 
> load than
> I do, with grant writing, administrative tasks, etc.  I'm 
> sorry that you
> have had a bad time with your servers, but frankly, we all 
> have our own
> side problems that do not involve EML and we still find time 
> to work on
> it.  Once EML 2.0 is released and is usable, we should all have more
> time to work on other projects.
> 
> In response to your comments about the connection metadata:  We will
> have connection metadata in EML.  It's just a matter of what form it
> will be stored in.  The members of this group have been 
> having this same
> philosophical discussion about URLs versus pre-defined connection
> parameter schema for 6 months now.  It will eventually be worked out
> like all the other issues.  I don't know how to interpret your last
> sentence.  EML is free software, it may be used how you see fit.  But
> what we are really trying to do is build ecological community ties for
> site interoperability.  Creating proprietary systems will not 
> meet that
> goal.
> 
> That having been said, we really do appreciate your (and 
> anyone else's)
> input into EML.  We have been wanting "real world" feedback about EML
> for some time now.  This is the first time that we have had that
> luxury.  It can only make EML better.
> 
> I'm looking forward to the chat tomorrow.
> 
> chad
> 
> -- 
> -----------------------
> Chad Berkley
> National Center for 
> Ecological Analysis 
> and Synthesis (NCEAS)
> berkley at nceas.ucsb.edu
> -----------------------
> 
> On Fri, 2002-08-30 at 16:06, Ken Ramsey wrote:
> > Matt,
> > 
> > I am sorry I have not replied to the email discussions or 
> submitted the
> > example of why I believe that people (researchers, technicians,
> > information managers, and other staff) are a valuable resource and
> > should (in my opinion) be considered a resource at the same level as
> > protocol, dataset, and citations.
> > 
> > There are 2 reasons for my inaction, the first is that I have other
> > responsibilities that have been taking up the majority of 
> my time, such
> > as server crashes and responding to researchers needs. The 
> second reason
> > is that, quite frankly, I do not enjoy the manner in which your team
> > seems to operate. By his I mean that your team seems to be tied so
> > closely with the project that you do not seem to be open to 
> change and I
> > do not like to operate in that mode; where I feel I must argue every
> > point or issue I would like EML to address. I also do not like that
> > after being told by Mark Schildauer to email eml_dev with the issues
> > from the last LTER EML Workshop only to have them 
> apparently ignored. I
> > am sorry, but I do not have time to populate the bug list 
> at this time.
> > 
> > I appreciate the opportunity to participate in the workshops and
> > conference call. I look forward to the release of EML 2 and will use
> > what I can from the final product. However, like I stated in my last
> > email to eml_dev I will have the mapping and querying application
> > developed as much as possible to EML. If you cannot support storing
> > connection information in EML, I will have no other choice 
> than to have
> > the application developed directly to our RDBMS schema.
> > 
> > I will join the conference call next week (using Groove) 
> with the hope
> > of being able to contribute.
> > 
> > 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
> > 
> > _______________________________________________
> > eml-dev mailing list
> > eml-dev at ecoinformatics.org
> > http://www.ecoinformatics.org/mailman/listinfo/eml-dev
> 
> 
> _______________________________________________
> eml-dev mailing list
> eml-dev at ecoinformatics.org
> http://www.ecoinformatics.org/mailman/listinfo/eml-dev
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20020903/128fd8b7/attachment.htm