linking protocol to dataset

Peter McCartney peter.mccartney at asu.edu
Thu Oct 10 10:23:12 PDT 2002 

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/81a1853a/attachment.htm

More information about the Eml-dev mailing list