linking protocol to dataset
Tim Bergsma
tbergsma at kbs.msu.edu
Thu Oct 10 11:26:02 PDT 2002
Peter,
No, it was David who suggested renaming methodStep. See below. I'm
more interested in whether we share a common vision for the usage of
methodStep and subStep. If methodStep(s) do not imply sequential
dependency relationships, then we solve three or four problems by going
with method/step rather than methodStep/subStep. No new problems are
created. Any set of steps to which one wished to ascribe sequential
dependency can be cast as a list of steps, wrapped in a method.
Remember, steps have ALL the same attributes as method, since they are
both ProcedureStepType. If you have no objections, we would merely be
tuning our element names to signal sanctioned usage.
regards,
Tim.
> 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