[Fwd: protocol, methods, and project]

[Tim Bergsma]

David,

Good points.  I agree with the way you've reclassified my example.

Tim.

> David Blankman wrote:
> 
> Tim et al,
> 
> I understand your issues about where do I put what (in dataset? , in
> project? in dataTable?)
> 
> The following is not meant to imply a need to change the EML model,
> but to comment on some of the issues that Matt and Tim raise. The
> Project module has been a source of confusion from its inception (if I
> remember correctly Project started out at a level equal to that of
> dataset). The confusion stems in part from the fuzziness of the
> concept "Project" and to a certain extent "Dataset".:
>  1. The scope of "project" is variable and indeterminate.
> 
>  2. The fact that project is contained within dataset adds to the
> confusion, since normally we would view a dataset as part of a
> project. ["Contained within" may not be technically correct in XML
> Schema terms but it is the way that most of us would describe it].
> 
>  3. The change in the packaging concept from triples to containment
> makes some things clearer but makes the question of "what goes where"
> more important. .
> 
>  4. For some, perhaps many, of the LTER information managers, the term
> "dataset" is is used to describe what is represented in EML as
> "dataTable", while the term  "project"  is used to describe what is
> represented in EML as "dataset".
> 
> I would suggest that  in Tim's example, "
> 
>  "For instance, at KBS, our
> mainsite layout is a randomized complete block agricultural
> experiment,
> installed in 1986.  That's a project, with a method, and created no
> data
> per se.  All of our main datasets, however, each with their own
> sampling
> techniques (methods/protocols) implicitly rely on the project method."
> 
> This information would logically go in
> Project/designDescription/paragraph (or whatever paragraph becomes).
> Perhaps the designDescription module should also be able to reference
> a resource-level protocol, although that may be possible already
> through the use of references. If I understand the distinction Peter
> makes between protocol and method, then anything at the project level
> would be a protocol.
> 
> Specific methods then belong at the dataTable level. Since "project"
> is optional, dataTable then needs to be able to include protocols as
> well as methods.
> 
> While I agree with Matt on trying to minimize the places where
> elements reside, the needs of site-based programs may be different
> from those of individual ecologists. An LTER site may need/want to
> have a richer set of items at the project level than an individual
> ecologist might need. Over time, I can foresee variations in Morpho
> configurations (or other EML tools) that might give users different
> recommended eml subsets in the same way that Quickbooks does for
> helping businesses choose account configurations that are relevant to
> their business, e.g. service vs retail vs manufacturer.
> 
> David
> 
> Tim Bergsma wrote:
> 
> > Matt, Peter,
> >
> > I'm scrambling to keep up here, but two comments:
> >
> > I think project needs its own method.  In fact, the best reason for
> > declaring a project is to document methods that form the context for
> > multiple datasets.  Advice to the user:  if a method is dataset
> > specific, associate it with dataset.  If datasets share an
> > experimental
> > context, declare a project and document the activities that created
> > the
> > experimental context as project/method.  For instance, at KBS, our
> > mainsite layout is a randomized complete block agricultural
> > experiment,
> > installed in 1986.  That's a project, with a method, and created no
> > data
> > per se.  All of our main datasets, however, each with their own
> > sampling
> > techniques (methods/protocols) implicitly rely on the project
> > method.
> >
> > I have no objection to simplifying method by dropping software,
> > instrumentation, etc and just making it a textType.  It solves some
> > of
> > the problems I mentioned in my last email.  I have hesitated to
> > suggest
> > this, because I don't know the history of why they are there.
> >
> > regards,
> >
> > Tim.
> >
> > -------- Original Message --------
> > Subject: protocol, methods, and project
> > Date: Wed, 28 Aug 2002 09:35:59 -0800
> > From: Matt Jones <jones at nceas.ucsb.edu>
> > To: Peter McCartney <peter.mccartney at asu.edu>
> > CC: "Eml-Dev (E-mail)" <eml-dev at ecoinformatics.org>
> > References: <11232E890694F74893375BC7AD88A62DAAB20E at MAINEX4.ASU.EDU>
> >
> > Hi Peter,
> >
> > So I looked over your protocol and methods changes as well.
> > Excellent
> > start. Some comments...
> >
> > I like the idea of distinguishing between a method that is ad-hoc
> > from a
> > protocol that is a resource-level version of a method.  And I agree
> > that
> > protocol should be modified to import eml-method so that they are
> > identical underneath in structure (except that protocol would have
> > the
> > resource fields).  Will you do that as well?
> >
> > I noticed that you removed the recursion from methodStep, although
> > methodSteps are repeatable.  This has some interaction with the
> > "procedure/step/substep" debate that's been happening in the
> > eml-text
> > thread.  Personally, I think it would be better if EML defined the
> > methodStep as repeatable and recursive, and left
> > "procedure/step/substep" docbook tags out of the eml-text module.
> > Or I
> > could be persuaded to leave it out of eml-method and put it in
> > eml-text.
> >   What I think would be bad is putting it in both places.  That
> > would
> > just make it confusing to end users who are trying to document their
> > procedures.
> >
> > I also was a bit confused about the inclusion of "protocol" in
> > method.
> > If a user has a protocol to describe, should they use the methodStep
> > block under method, or under method/protocol?  How do they decide?
> >
> > The single most frequent question from our EML/Morpho users in our
> > seminars, and the one that frustrates users to no end, is: "I have
> > piece
> > of information, in which of these X places should i put it in eml?".
> > Basically, they have a very difficult time distinguishing the intent
> > in
> > eml of reused element trees.  For example, they might say "data was
> > collected in 1999", and want to know if they should put that piece
> > of
> > information in dataset/coverage or dataset/dataTable/coverage.
> > Legitimate question, subtle distinction.  There are hundreds of
> > these
> > subtleties in EML, which add up to massive confusion to users.
> >
> > So how does this relate to protocol?  By sprinkling
> > "protocol/method"
> > elements throughout eml, users will have lots of choices of where to
> > put
> > things, and almost no understanding of why things should go in one
> > place
> > over another.  In general, if we can, I would like to see us come up
> > with a solid rationale and use case for each use of "method" in eml.
> > If
> > we can avoid it, I'd prefer to not have two or more locations for
> > information that can be interpreted identically (e.g., method in
> > dataset
> > and project).  Soo....can we consolidate the method references
> > somewhat?
> >   I'm happy to move it to dataset if that's where people want to see
> > it,
> > but I propose that we should not have it in both dataset and
> > project.
> >
> > I'm also a little confused about the whole method structure itself
> > -- it
> > seems overly complex for what it does.  This is not information that
> > we
> > intend to machine process at this point.  So why are instrumentation
> > and
> > software broken out from the description?  Can't methodStep just be
> > a
> > structured text block, maybe called "method"?  Is protocol needed,
> > or
> > can it be referecend under citation if it is a published protocol?
> > Is
> > qualityCOntrol so different from methodStep in its machine
> > processing
> > that it needs to be a separate structure?  Can't we just include
> > quality
> > control methods as a methodStep (aka method in my earlier terms)?
> >
> > Finally, in project, some of the cardinality rules don't make sense.
> > designDescription is 0 to many, and contains a child choice that is
> > 1 to
> > many, which contains an optional citation.  I think it should be:
> > designDescription is 0 to 1, anc contains a choice that is 1 to
> > many,
> > where both elements in the choice are 1 to 1.  An analogous argument
> > could be applied to studyAreaDescription.  This approach allows
> > these
> > elements to be optional, but if they are present, requires that they
> > have at least one child for content.  In general having a child of a
> > choice be optional is unneeded.
> >
> > Well, that's probably enough of a tome for now.  Thanks for your
> > excellent effort on this...
> >
> > Matt
> >
> > Peter McCartney wrote:
> >
> >
> >> 2) my proposed changes to address the LTER IM complaints about
> >> protocol/project: these involved defining a new module called
> >> eml-methods which includes elements for quality control, sampling
> >> description and methodStep(s). MethodSteps includes pointers to
> >> related
> >> sofware, datsets, and instruments and a description which any
> >> combination of text, eml-protocol, or eml-citation.
> >>
> >> methods is imported optionally into dataset, entityBase and
> >> attribute
> >> and any previous links to protocol is removed.
> >>
> >> This solution leaves eml-protocol to be used only for generic
> >> protocols
> >> that we wish to publish as resources. There is still a flaw here
> >> in that
> >> protocol also defines a methodStep elment that differs from the
> >> one in
> >> method. so the name should be changed or perhaps protocol should
> >> just
> >> import eml-method so that all it does is add the resourceBase
> >> elements.
> >>
> >>
> >>
> >
> >
> 
> --
> 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

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