protocol and method: radical proposal

[Peter McCartney]

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
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20020830/c8db80fe/attachment.htm