linking protocol to dataset

Tim Bergsma tbergsma at kbs.msu.edu
Thu Oct 10 11:35:38 PDT 2002 

If we go this route, I'd be happy to take one more look at the
documentation for methods.  For instance, the methods element itself
still has the annotation <xs:documentation>Comment describing your root
element</xs:documentation>
which should either be dropped or made more descriptive.

Tim.


> David Blankman wrote:
> 
> 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
> > >
> >

-- 
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

More information about the Eml-dev mailing list