fixing methods
Tim Bergsma
tbergsma at kbs.msu.edu
Fri Oct 11 13:36:23 PDT 2002
Peter,
I noticed that methodStep has a dataSource child, but methodStep/subStep
does not. This is because methodStep extends ProcedureStepType with a
dataSource element at the root level. If it were possible (?), one
might have wanted to extend ProcedureStepType at the subStep level, not
that I have any instances of subSteps with dataSources.
As things stand, I'm convinced that methodStep is designed to hold a
sequentially dependent series of steps: to think of methodStep as a
method is the workaround, and not vice versa. I'm dropping my request
to rename methodStep to method. Also, the "sub" part of subStep has
permanent value for signalling the relationship of this element to the
parent Step of which it is a part, so I'm dropping my request to rename
subStep to step.
The four uses of ProcedureStepType in eml are proceduralStep,
methodStep, subStep, and qualityControl. For consistency,
qualityControl could be renamed qualityControlStep.
I'm done whining about methods! Time to validate...
Tim.
Tim Bergsma wrote:
>
> 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
> _______________________________________________
> 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
More information about the Eml-dev
mailing list