eml-methods modification proposal (see bug 624 for more detail)

[Tim Bergsma]

David, Peter,

Considering that we were working independently, it's interesting that we
both noticed an opportunity for parallelism in the naming of methodStep
and qualityControl.  I didn't notice this in David's suggestion until I
re-read it more carefully this morning.  Consistent with what I said
last Friday, I think methodStep/qualityControlStep is preferred (David's
option A).  

I think David was defending B mostly to accomodate the concerns that I
raised earlier.  Meanwhile, I was realizing that renaming methodStep to
step entails a cascade of consequences.  It has value in that all
"stepping" is achieved in a single place:  ProcedureStep type.  But for
consistency, we'd want to dip into ProtocolType and change
proceduralStep to procedure, with a cardinality of zero or one. 
procedure and method, when written with explicit steps, would both have
a root 'description', which is nice for method since it gives you a
place to mention things common to all steps, like a method title.  But
awkward for protocol, which already has exhustive global metadata by
virtue of resourceGroup.  Also, I think Peter clearly wanted to have
dataSource associated with something 'step'-like, which seems to
disappear if you rename methodStep.  If you make dataSource a child of
ProcedureStepType, then it becomes available to qualityControl and
protocol as well, and we'd have to figure out again why we didn't want
to do that.  In short, it's more tinkering than a release candidate can
afford.

To summarize:  the two schema issues remain critical, and renaming
qualityControl to qualityControlStep is an improvement but non-critical.

Tim.


David Blankman wrote:

> I also recommend that methodStep be renamed to method and subStep be
> renamed to step. Both methodStep and qualityControl are of type
> ProcedureStepType. For consistency we should have either:
> 
>    A. methodStep and qualityControlStep
>        or
>    B. method and qualityControl.
> 
> I recommend option B.
> 
> David Blankman
> 
> --
> 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
> 
> _______________________________________________
> 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