linking protocol to dataset

[Tim Bergsma]

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