eml-dataset changes needed
Changes as decided upon at the Sevilleta EML meeting, April 24-25, 2002:
1) Add contact+ to dataset -- I also have a note that this should be added to
resource as contact*. Need to figure out which.
2) Add "publisher"
3) Add "purpose"
4) Do NOT add geoform -- decided it was farsical and we could provide a
reasonable value (e.g., document) when converting to FGDC
5) add "maintenance" description -- para that describes freq of update and
6) my notes say to add distribution elelemnt, but others say it goes in
resource, which is it? ditto with "contact*"
#3 Updated by Chris Jones about 18 years ago
In looking at eml-dataset as a whole, the contact+ seems redundant to me given
that creator, metadataProvider, and associatedParty? are part of the
ResourceGroup in the higher sequence. In fact, I think it will be confusing
because it is not clear where to place contact information. I would suggest to
remove contact+, and use the creator element plus and the other ResourceGroup
RPs to document contact info. It sounds like we were trying to emulate what
Endnote was doing, so let me know if I'm off base here.
#4 Updated by Matt Jones about 18 years ago
I think you're off-base here :)
The contact role was removed from resource and specifically placed in the
individual modules so that it could be required for some modules (dataset) and
optional for others (literature). I think we need the role "contact", and I
think it is distinct from creator and metadataProvider.
#6 Updated by Owen Eddins about 18 years ago
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.
<dataset> should have an optional <protocol> child. Currently it
does not. <project>, <dataTable>, and <attribute> have the <protocol>
option, but not <dataset>. Peter McCartney defined 'dataset' as "the
product of a discrete research activity" (6-20-2002). It is very
natural to suppose that a discrete research activity has a protocol. As
things are now, dataset protocols must be associated with their
entities, which makes it awkward to represent a protocol which
effectively corresponds to several entities. For instance, a bird
survey protocol could generate a table of weather conditions and a table
of sightings, maybe even a set of audio recordings. Such a protocol is
represented more naturally at the dataset level than at the entity
#8 Updated by Peter McCartney almost 18 years ago
This comment is just a change to stop the automatic "needs attention" email.
The only aspect of this that directly affects dataset is that an element
called "method" or methods" is added to dataset and contains some elements that
were previously attributed to project. What's actually in "method" and what its
relationship with "protocol" is is dealt with in a set of draft changes
published in the CVS branch "prospective_changes" or something like that.
Acceptance of them really requires simultaneous resolution of the "textType"
bug as all of the methodological modules eventually break down into formatted
text and we need a clean break between them.
#9 Updated by Peter McCartney almost 18 years ago
Ok, im going to close this bug as fixed since there is a clear point after
Matt's entry (#5) where the only remaining issue was related to the
method/protocol discussion. dataset now contains method which resolves's Tim
Bergsma's points. Any lingering issues related to methods should appear in a
bug related directly with that module.