protocol and method: radical proposal

[Tim Bergsma]

Peter,

I like your idea of explicitly creating a base procedure type.  It
allows a formal representation of the similarities and differerences
between protocol and method.

May I assume that procedureType has 'step' as well as 'substep'?

I'm beginning to appreciate your comment about 'clean line'.  In a
certain sense, though, we don't want ANY formattting tags in eml -- only
structural tags.  Even if procedure/step/substep emulates DocBook, I
would still consider them eml.

Both you and Matt and I have indicated that it would be tolerable to see
procedure/step/substep be nested under textType (DocBook style) or under
a native EML procedural type (method/protocol etc), but not both.  If we
don't need to attach elements to steps, it would be much simpler to nest
procedure/step/substep under textType (Proposal A).  If we definitely
want to attach elements to steps (or preserve the option) then we should
exclude procedure/step/substep from textType and declare them under
procedureType or equivalent, as you are doing (Proposal B).

One thing that I think has evolved without my realizing it, is a
container for methodSteps.  Apparently the viable proposals have this,
but the version we saw at the last Phoenix meeting didn't (methodStep
was just repeatable).  I apologize for rehashing a discussion I probably
missed, but it is now possible to attach elements to a method as a
whole, or to individual steps, where before it was only possible to
attach elements to steps.  For instance, in the last eml-method.xsd you
sent out, instrumentation and software are attached to methodStep, but
sampling, quality control, citation, and protocol are attached to the
MethodType as a whole.  I don't understand the choices.  Why, for
instance, shouldn't some specific step (but not the whole method) simply
defer to some protocol?

ACTION ITEM:  If we go with Proposal B, we should force the user to
choose between writing a set of steps versus writing one TextType
block.  As it currently stands, the user who won't or can't break a
procedure into discrete steps is forced to create a single step and dump
all content into it's attached TextType block.  

regards,

Tim.

> Peter McCartney wrote:
> 
> Hi Tim....im afraid im not familiar enough with docbook to evaluate
> your radical proposal other than to say that it will start getting
> confusing if we dont have a clean line between where EML tags leave
> off and formatting tags begin. the step/substep is a good example - if
> we dont care to attach tags to steps and substeps then it probably
> doesnt matter if then that aspect of structure become more freeform,
> otherwise, we might need to define the steps as eml elements and use
> docbook/html/whatever for internal structure of the text portions.
> 
> Ive done some more experimenting and checked the results into the
> branch of cvs that chad created "EML_PROSPECTIVE_CHANGES". this
> version has a base procedure type that contains little more than
> substep, description and citation. Protocol imports this. Method
> defines a methodProcedure which extends this with specifics that are
> contextually meaningful like instrumentation, datasources, etc. Method
> then includes this element plus things that people didnt want to see
> under a "step" element like sampling and qualityControl. Of course, as
> ive said elsewhere, im now in favor of dropping protocol as a resource
> - i dont think it is a distinct kind of resource unless it is going to
> take on enough structure to be machine readable, otherwise its a
> document.
> 
> 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, August 30, 2002 8:30 AM
> > To: Eml-Dev (E-mail)
> > Subject: protocol and method: radical proposal
> >
> >
> > Peter et al.,
> >
> > Recent talk about importing method into protocol confuses me, both
> > because I don't know the technical implications of 'import' and more
> 
> > importantly because semantically it blurs the distinction between
> the
> > two.
> >
> > For clarity, I suggest language that sees method and protocol as two
> 
> > kinds of procedures:  method is a descriptive procedure and
> > protocol is
> > a prescriptive procedure.  Thus, protocol is an abstraction, albeit
> an
> > important one; method is concrete, representing activity that
> actually
> > occured, which may or may not be consistent with (validate against?)
> 
> > some protocol.  This is pretty much how we've all been using
> > the terms.
> >
> > For importing, then, theoretically there should be a
> > procedure base type
> > that both method and protocol import.  But there is already a
> > procedure
> > element in DocBook, which leads me to a radical proposal...
> >
> > Let's put procedure/step/substep in TextType (a DocBook
> > subset).  Then,
> > define protocol and method independently, but identically, as...
> > exactly one TextType
> > optional instrumentation
> > optional software
> > optional sampling
> > optional qualitycontrol
> > optional protocol
> >
> > leaving cardinality etc. to the experts.
> >
> > Notes:
> >
> > 1.  method would still be available at project, dataset, entity, and
> 
> > attribute levels, but that's a different discussion.  (I wouldn't
> mind
> > if it were only available at the dataset level).
> >
> > 2.  Both method and protocol can reference other protocols,
> > which makes
> > sense.
> >
> > 3.  Authors of both granular (stepped) procedures and casual (prose)
> 
> > procedures have simple, common container for their procedure:
> > TextType.  procedure/step/substep is there for those who plan to use
> 
> > it.  No contorted paths.
> >
> > 4.  Nothing is lost except the ability to formally associate
> > instrument
> > and software  with steps, rather than with method (or protocol) as a
> 
> > whole.  The association could still be authored in a human
> > readable form
> > in the step itself, but a search engine couldn't return all
> > the *steps*
> > that use a piece of software, just all the *methods* (or protocols).
> 
> > How bad is that?
> >
> > 5.  I keep using method where eml uses methods, sorry.  I like
> method
> > (singular) better, but I don't plan to debate it.
> >
> > Regards,
> >
> > 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
> >

-- 
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