EML

Ok im having problems with using this thing. i may have to just email it if i
hit the wrong button again.

ive attached (twice) a draft of protocol that makes the changes from Sevilleta,
although there is still some chaff in the file to weed out before checking it
in.

Im concerned about how this module works for individual datasets if we bump
protocol up to resource level. if our intent is to have generic libraries of
protocols that are abstracted from the individual datasets, then how do we
avoid having 200 different protocol descriptions for basically the same
operation, but differ only in the source dataset used or in the particular
instrument model? in other words, where do we cross the line between "best
practices" and "metadata", and can this single module serve both purposes?

It is essential that we be able to describe the specific source
datasets,instruments, etc. used in a particular dataset, so whatever we do
should not eliminate that possibility.

Changes look good, Peter. To keep up my record on long lists of comments, here
goes nothing...

1) we agree to nix the "eml-" in the root element, and identifier is part of
resource, so I think you could start the whole tree with the "protocol" element,
eliminating the extra "eml-protocol" and "identifier" elements.
2) You renamed the namespace prefixes so that they are no longer consistent with
the rest of EML. Technically that is fine, but it would be less surprising and
more understandable if you were consistent with the rest of EML. In particular,
change rsb to res and change "lit" to "cit". Plus, you don't actually use the
"soft" and "ds" namespaces, so they should be eliminated from the namespace
declarations and the xs:imports).
3) the CHOICE under methodStep/description has a content model "+", so the
children of the choice don't need to be repeatable. The
methodStep/qualityCOntrol should be handled the same way (so change the CHOICE
content model to + there).
4) Indentation & whitespace, as usual.
5) We'll need to make changes based on changes to packaging, which I think will
address your issue about being able to reference protocols for individual data
sets. I'll write a long tome on this tomorrow.

Otherwise, looks good. We should get Barbara Benson to review this for us
before we finalize.

Ok thanks for the comments. Ill clean up the technical things as suggested. But
im still troubled by the fundamental question of whether we can do both
metadata and a general protocol library using the same module. Any comments on
that one? one solution ive thought of is to simply put a recursive link to
protocol, to allow one to write a locally specific protocol statement that
references a more generic one. that doesnt solve the problem of our
protocol "library" being bloated with lots of protocol discussions that are
meaningful only for one particular dataset.

Ok here is a copy with most of the changes Matt listed plus the addition of a
recursive call to protocol as third choice option under methodStep/description.
This would let us make pointers to a more generic protocol in a similar way to
how eml-project can point to a related project description.

I still have to clean up the module documentation stuff - not sure i fully
understand the new structure yet.

Peter,

While reviewing eml-protocol, it all seemed to make sense, although I was
confused about the content/methodStep/description/protocol element. There's no
inline documentation for it. I see your bugzilla comments, and understand the
rationale, but how it's implemented still is confusing. Are you saying that
you'd want to "extend" a protocol...i.e. steps 1 through 5 are identical, but
this local protocol modifies steps 6 and 7? If that's the case, I could see
that work with a content/methodStep/description/protocol/paragraph that desribes
the relationship to the "other" protocol or protocol reference.

Peter,

Lastly, it seems we should not use element refs pointing into imported schema
docs...instead follow the convention of creating a new element and Typing it
acording to the ComplexType in the remote schema:

<xs:element name="sourceDatasetUsed" type="ds:DatasetType">
....
</xs:element>

Chris-

the recursion of protocol back into itself was a possible solution i'd had to
the problem i mentioned of trying to deal with the fact that we want to reuse
protocol descriptons, yet also adapt them to our specific dataset. the analogy
was with the way we linked project descriptions to other project descriptions.
We should probably get some feedback on this before accepting it - maybe its
just not so much of an issue as I'm making it.

The ref call to dataset was done simply to get the file to validate -at the
time, dataset did not have a complex type due to the problem that surfaced
early last week. I just fixed it.

Protocol is now a resource. Completed. In CVS.

I'm passing the following comments from Tim Bergsma the data manager at Kellog
Biological Station in Michagen. He made them in a eml-dev email. I posting to
bugzilla just to make sure they don't fall through the cracks.

2. There is a great need in the research community to maintain a
distinction between 'protocol' and 'method'. In my thinking, 'protocol'
is a prescriptive procedure, and 'method' is a descriptive procedure.
When interpreting data, it is critical to know whether a stated
procedure represents a record of what was done, or is only an
expectation of what should have been done under normal circumstances.
For small research efforts where procedures are not repetitive, it is
sufficient merely to document that which was done. For large efforts
with repetitive procedures, it is convenient to create a prescriptive
protocol, but then essential to maintain a record asserting that the
protocol was followed, and noting the (inevitable) deviations from the
protocol. Beta9 does nothing to sharpen the distinction between
protocol and method, using the words interchangeably, as many of us do.
Perhaps we should adopt 'procedure' in place of 'protocol', with a
required switch indicating whether the procedure is prescriptive or
descriptive.

3. In Beta9, <protocol> is modeled as a sequence of <methodSteps>
(which can be described by means of paragraphs, citations, or protocol
references). This is insufficient. It is quite natural for a protocol
to have introductory material (for instance) which is not a method
step. It is also possible to write a protocol which is a network of
contingencies rather than a list of steps. For example, 'fertilizer
recommendations based on soil nitrate tests' properly constitute a
protocol, but are better represented as prose rather than as a series of
steps. Perhaps protocol (or its successor) should be a series of choice
of paragraph or methodStep. At present, I can't use the eml model to
represent fully the protocols that exist for our site.

eml-method was created with a procedureType complex type. this is imported into
em-protocol and is extended within eml-method to include refs to datasources
used

methodological info was extracted from project and put in eml-method. eml-
method is imported into dataset, entiy and attribute.

this addresses issues rasied in the June LTER metadata workshop concerning
protocol and project descriptions.

Original Bugzilla ID was 489