linking protocol to dataset

David Blankman dblankman1 at comcast.net
Thu Oct 10 11:14:00 PDT 2002 

Peter & Tim,

Actually I was the one who mentioned the name changes, not so much as a 
suggestion that we actually change the element names, but  to help think 
about the meaning of the schema. Given Tim's enthusiastic response to 
changing the name, it might not be a bad idea to change the element 
names, especially since the schema should probably be fixed anyway.


David

Peter McCartney wrote:

> whoa...i never suggested renaming elements. I think what what i 
> suggested was that the structure that we have can accomodate the 
> example, even if it doesnt follow the implied semantics of the element 
> name. Trust me, theres a LOT more in EML that worries me more than 
> methodstep's name! 
>
> Peter McCartney (peter.mccartney at asu.edu)
> Center for Environmental Studies
> Arizona State University
> 480-965-6791
>
> > -----Original Message-----
> > From: Tim Bergsma [mailto:tbergsma at kbs.msu.edu]
> > Sent: Thursday, October 10, 2002 7:11 AM
> > To: David Blankman
> > Cc: Eml-Dev (E-mail); Peter McCartney
> > Subject: Re: linking protocol to dataset
> >
> >
> > David, Peter,
> >
> > I am euphoric about the suggestion of renaming methodStep to method!
> > If, as you say, there is no implied dependency relationship among a
> > series of methodStep, then method is a much clearer term.  If
> > we rename
> > methodStep to method, then we can rename subStep to step.  It's (near)
> > perfect!  (I've been bothered by subStep too, probably because the
> > concept of nesting was represented by schema recursion and
> > again in the
> > element name: unnecessary).  We we gain is a sanctioned wrapper for a
> > set of steps that DO have implied dependency.
> >
> > If we change methodStep to method, and subStep to step, we will not be
> > changing the schema structure (Bug 624 notwithstanding).  We
> > could drop
> > bug 625.  What we would be doing is signaling a clearer, less
> > ambiguous,
> > more flexible way of using methods.  Methods that can be serialized
> > (represented as a sequence of formal steps) would be written
> > as (David's
> > example)
> >
> > <methods>
> >  <method></method>
> >  <method>
> >   <step></step>
> >   <step></step>
> >   <step></step>
> >  </method>
> > <method></method>
> >  </methods>
> >
> > while unserializable methods would be written as
> >
> > <methods>
> >  <method></method>
> >  <method>
> >   <description>
> >  </method>
> >  <method></method>
> > </methods>
> >
> > Having said that, I just realized that at least one global
> > <description>
> > element would be required even for serializable methods, as the schema
> > stands.  Peter, is that a problem for you?  Any elegant fix? 
> > I have one
> > other problem with ProcedureStepType that I'll describe in a second
> > email.
> >
> > Tim.
> >
> >
> >
> > David Blankman wrote:
> > >
> > > Tim,
> > >
> > > As I look at the model, it seems to me that the model
> > accomdates what
> > > you want to do. The element names are perhaps a little
> > > confusing/misleading. My reading is similar to Peter's. As
> > I read it, a
> > > series of "methodStep(s)" does not imply that there is a dependency
> > > relationship among the series of methodSteps. Perhaps it would be
> > > clearer to rename methodStep to method, then methods would
> > a repetable
> > > choice (or sequence depending on the resolution of  bug 624) of  a
> > > method, sampling or qualityControl. Since a method
> > (methodStep) can have
> > > 0 or more subStep(s), the intrepretation of:
> > >  <methods>
> > >     <method></method>
> > >     <method>
> > >         <subStep></subStep>
> > >         <subStep></subStep>
> > >         <subStep></subStep>
> > >     </method>
> > >     <method></method>
> > > </methods>
> > >
> > > would be clear: three independent methods, one of which has
> > a series of
> > > three substeps.
> > >
> > > I am not entirely clear whether subStep is still useful/needed given
> > > that <description>/textType allows for nesting, but I can
> > see that it
> > > allows for additional descriptive richness.
> > >
> > >
> > > Tim Bergsma wrote:
> > >
> > > >Peter, others,
> > > >
> > > >I'm wrestling with the relationship between a protocol and
> > a dataset.
> > > >
> > > >In my local data management system, a dataset can 'have'
> > an associated
> > > >protocol.  But in eml, a dataset cannot have a protocol: 
> > it can only
> > > >have a methods that has a methodStep that has a protocol.
> > > >
> > > >In fact, in my local system, a dataset can have any number of named
> > > >methods, and any number of named protocols.  But eml
> > clearly expects
> > > >that a dataset has only one methods.  The only way I can see to
> > > >stipulate multiple, independent methods is to create multiple
> > > >methodSteps, and poke the descriptions into TextType.  Same for
> > > >protocols.  Clearly this was not how methodStep was intended.
> > > >
> > > >MethodStep repeats, but also the choice of
> > > >methodStep/sampling/qualityControl repeats.  Correct me if
> > I'm wrong:
> > > >choosing methodStep twice will look exactly like choosing
> > it once but
> > > >having two methodSteps.  Consequentially, there's no
> > mechanism to signal
> > > >that one sequence of methodSteps is independent of a
> > second sequence of
> > > >methodSteps.
> > > >
> > > >Unless review of RC2 flags this as a certifiable flaw,
> > it's not going to
> > > >change now.  I have a very real problem that some of my
> > datasets don't
> > > >have records of actual activity (methods), they only have
> > protocols.  I
> > > >could spoof the methods/methodStep tags and poke each
> > protocol into a
> > > >textType.  For datasets with multiple, independent
> > methods, I guess I'll
> > > >have to poke each into a sequential methodSteps, even if
> > they are not
> > > >sequentially related.  Please comment.
> > > >
> > > >Tim.
> > > >
> > > >
> > > >
> > > >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
> > > >_______________________________________________
> > > >eml-dev mailing list
> > > >eml-dev at ecoinformatics.org
> > > >http://www.ecoinformatics.org/mailman/listinfo/eml-dev
> > > >
> > > >
> > >
> > > --
> > > David E. Blankman
> > > Database Integration Developer
> > > Long Term Ecological Research Network Office
> > > University of New Mexico
> > > 801 University, SE #104
> > > Albuquerque, NM 87106
> > > (505) 272-7346 / (505) 272-7080 FAX
> > >
> > > _______________________________________________
> > > eml-dev mailing list
> > > eml-dev at ecoinformatics.org
> > > http://www.ecoinformatics.org/mailman/listinfo/eml-dev
> >
> > --
> > 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
> >
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20021010/301e5f92/attachment.htm

More information about the Eml-dev mailing list