EML: Issueshttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362002-10-09T19:48:41ZEcoinformatics Redmine
Redmine Bug #625 (Resolved): Cardinality regarding eml-methods should be corrected in two places.https://projects.ecoinformatics.org/ecoinfo/issues/6252002-10-09T19:48:41ZTim Bergsmatbergsma@kbs.msu.edu
<p>eml-dataset has an optional child element methods with the cardinality zero-or-<br />ONE. It should be zero-to-MANY. A dataset may be qualifed by more than one <br />corpus of methodological effort, and it cannot be assumed that those efforts <br />form a single logically and temporally continuous sequence of methodStep. <br />Also, methods itself should be a SEQUENCE, not a CHOICE, of methodStep (itself <br />repeatable), sampling (optional), or qualityControl (optional). It is an error <br />to present a choice of optional elements.</p> Bug #601 (Resolved): element names in spatial modules do not follow guidelineshttps://projects.ecoinformatics.org/ecoinfo/issues/6012002-09-23T21:32:32ZChad Berkleyberkley@nceas.ucsb.edu
<p>A bunch of the element names in the spatial modules have underscores in them<br />instead of using camelCaps (for instance local_Georeference_Information instead<br />of localGeoreferenceInformation). This needs to be changed so that these<br />modules conform to the same coding standards as the other eml modules.</p> Bug #566 (Resolved): change how eml.xsd imports resource moduleshttps://projects.ecoinformatics.org/ecoinfo/issues/5662002-08-21T18:54:37ZPeter McCartneypeter.mccartney@asu.edu
<p>Change eml.xsd to import resource-level modules as complex types rather than <br />ref pointers.</p> Bug #489 (Resolved): eml-protocol changes neededhttps://projects.ecoinformatics.org/ecoinfo/issues/4892002-05-02T00:18:02ZMatt Jonesjones@nceas.ucsb.edu
<p>Changes as decided upon at the Sevilleta EML meeting, April 24-25, 2002:<br />Responsible: Corinna, Chris</p>
<p>1) Make eml-protocol be an extension of eml-resource as requested by RDIFS<br />2) get feedback from RDIFS (benson) on modifications<br />3) add additional protocol structure from the ASU model</p> Bug #482 (Resolved): eml-dataset changes neededhttps://projects.ecoinformatics.org/ecoinfo/issues/4822002-05-01T23:26:00ZMatt Jonesjones@nceas.ucsb.edu
<p>Changes as decided upon at the Sevilleta EML meeting, April 24-25, 2002:<br />Responsible: Matt</p>
<p>1) Add contact+ to dataset -- I also have a note that this should be added to<br />resource as contact*. Need to figure out which.<br />2) Add "publisher" <strong><br />3) Add "purpose" <br />4) Do NOT add geoform -- decided it was farsical and we could provide a<br />reasonable value (e.g., document) when converting to FGDC<br />5) add "maintenance" description -- para that describes freq of update and<br />completion status<br />6) my notes say to add distribution</strong> elelemnt, but others say it goes in<br />resource, which is it? ditto with "contact*"</p> Bug #429 (Resolved): add additional entity types to EMLhttps://projects.ecoinformatics.org/ecoinfo/issues/4292002-02-15T02:08:42ZMatt Jonesjones@nceas.ucsb.edu
<p>The current eml-entity module describes two types of entities: table-entities<br />and other-entities. Ultimately I think we need to be able to describe several<br />other specific types of entities, particularly spatial images and various GIS<br />objects.</p>
<p>General image support may also be useful (e.g., for jpg, gif, etc) so that photo<br />quadrats and other types of images used as data and metadata can easily be<br />included. We may be able to easily accomodate many of these generic entity<br />types but utilizing a MIME-type label (e.g., image/gif) in the entityType field,<br />although there may also be need for additional metadata for these entity types.</p>