protocol and method: radical proposal
Tim Bergsma
tbergsma at kbs.msu.edu
Fri Aug 30 08:30:02 PDT 2002
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
More information about the Eml-dev
mailing list