linking protocol to dataset
Peter McCartney
peter.mccartney at asu.edu
Fri Oct 11 13:23:57 PDT 2002
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20021011/ba196330/attachment.htm
More information about the Eml-dev
mailing list