linking protocol to dataset
Tim Bergsma
tbergsma at kbs.msu.edu
Mon Oct 14 06:51:34 PDT 2002
Absolutely.
Tim.
> David Blankman wrote:
>
> Yes, those certainly need to be fixed.
>
> Peter McCartney wrote:
>
> > Ok cool, but we are still agreed that the bugs noted to change
> > choice to sequence elements in methodsType and ProcedureStepType
> > should be fixed, correct?
> >
> > 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: Friday, October 11, 2002 2:05 PM
> > > To: Peter McCartney
> > > Cc: dblankman at lternet.edu; Eml-Dev (E-mail)
> > > Subject: Re: linking protocol to dataset
> > >
> > >
> > > Peter,
> > >
> > > Just saw this. As per my previous email, I think you are right.
> > I
> > > spent all night and half of today wrestling with this, and I'm
> > > concluding that, although there may be an issue here, the
> > > changes would
> > > be more widespread than would be appropriate for a release
> > candidate.
> > > Things are actually quite good as they stand. I want to
> > > thank David for
> > > entertaining my point of view and identifying a workaround.
> > > I did post
> > > another bug about ProcedureStepType, but that was just to make
> > sure it
> > > wouldn't be forgotten (looks like it won't be).
> > >
> > > Issues aside, Peter, I'm really impressed overall with how
> > > ProcedureStepType works in the schema: the modularity is elegant.
> > >
> > > regards,
> > >
> > > Tim.
> > >
> > > > Peter McCartney wrote:
> > > >
> > > > david and i are on irc discussing this now, so let me share what
> > im
> > > > saying there.
> > > >
> > > > 1. there are two place in the schema where i invoked choices
> > instead
> > > > of squence by mistake. one is in methodsType, the other is in
> > > > ProcedureStepType. fixing those as summarized in bugzilla
> > > address some
> > > > of the issues david has raised there.
> > > >
> > > > 2. the objections to the name "methodStep" seem to be related to
> > the
> > > > case of having two method actions to be described that do
> > > NOT have any
> > > > squential relationship. if this is because each refers to
> > different
> > > > portions of the dataset, then i remind you that we provide
> > > methods as
> > > > an element in entityBase and AttributeType for just this reason.
> > if
> > > > you really have methods relevant to the whole dataset for which
> > > > squence doesnt matter, then it seems like it doesnt matter if
> > you
> > > > enter them sequentially.
> > > >
> > > > so i think there are two minor errors regarding choice/sequence
> > > > elements to fix. the rest of this might be just cutting the cord
> > and
> > > > letting it go.
> > > >
> > > > 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 11:36 AM
> > > > > To: dblankman at lternet.edu
> > > > > Cc: Peter McCartney; Eml-Dev (E-mail)
> > > > > Subject: Re: linking protocol to dataset
> > > > >
> > > > >
> > > > > 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
> > > > >
> > >
> > > --
> > > 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