Ecoinformatics Redmine: Issueshttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362012-11-08T21:03:03ZEcoinformatics Redmine
Redmine EML - Bug #5731 (New): parser does not recognize attribute/@id in additionalMetadata/describeshttps://projects.ecoinformatics.org/ecoinfo/issues/57312012-11-08T21:03:03ZMargaret O'Brienmob@msi.ucsb.edu
<p>A document has an additionalMetadata section which describes a dataTable attribute. But the parser rejects it saying the referenced id does not exist in the given keys.</p>
<p>I think this is because "//attribute" was left off the list of elements in the <key name="identifierKey"> that the parser checks. I am assuming this was not deliberate.</p>
<p>example config file with <key name="identifierKey">:<br /><a class="external" href="http://svn.lternet.edu/websvn/filedetails.php?repname=EML&path=%2Ftrunk%2Feml-2.1.0%2Flib%2Fconfig.xml">http://svn.lternet.edu/websvn/filedetails.php?repname=EML&path=%2Ftrunk%2Feml-2.1.0%2Flib%2Fconfig.xml</a></p>
<p>Although the parser I used was <a class="external" href="http://knb.ecoinformatics.org/emlparser/index.html">http://knb.ecoinformatics.org/emlparser/index.html</a></p>
<p>Below is some skeleton EML. Obviously, the doc is not in Metacat because it is invalid.</p>
<p><dataset><br />...<br /> <attribute id="entity_1.NH4_uM" system="sbclter" scope="system"><br /> <attributeName>NH4_uM</attributeName><br />...<br /> </attribute><br />...<br /></dataset><br /><additionalMetadata><br /> <describes>entity_1.NH4_uM</describes><br /> <metadata><br /> <annotation> ... </annotation><br /> </metadata><br /></additionalMetadata></p> EML - Bug #5704 (New): update documentation for species binomialshttps://projects.ecoinformatics.org/ecoinfo/issues/57042012-09-04T16:06:32ZMargaret O'Brienmob@msi.ucsb.edu
<p>The EML documentation needs an update to reflect correct practice when including a taxonomic species name. Taxonomically speaking, the 'species name' is a genus and the specific epithet. But looking at it from a strictly hierarchical node structure the specific epithet looks and acts like the other nodes. However a node 'alterniflora' has no taxon rank by itself.</p>
<p>LTER already reccommends this construction in its Best Practices, but actual implementations are inconsistent, perhaps because of the normative documentation.</p>
<p>Another note: The normative docs also seem to refer to "Acer rubrum" as the 'common name' of Red Maple, which is incorrect..</p>
<p>Here is an example of 2 implementations sent to eml-dev (from Wade Sheldon):</p>
<p>with binomial:</p>
<p><taxonomicClassification><br /> <taxonRankName>Genus</taxonRankName><br /> <taxonRankValue>Spartina</taxonRankValue><br /> <taxonomicClassification><br /> <taxonRankName>Species</taxonRankName><br /> <taxonRankValue>Spartina alterniflora</taxonRankValue><br /> </taxonomicClassification><br /></taxonomicClassification></p>
<p>without binomial:</p>
<p><taxonomicClassification><br /> <taxonRankName>Genus</taxonRankName><br /> <taxonRankValue>Spartina</taxonRankValue><br /> <taxonomicClassification><br /> <taxonRankName>Species</taxonRankName><br /> <taxonRankValue>alterniflora</taxonRankValue><br /> </taxonomicClassification><br /></taxonomicClassification></p>
<p>Here is the text from the EML 2.1.1 normative docs:<br />(<a class="external" href="http://knb.ecoinformatics.org/software/eml/eml-2.1.1/eml-coverage.html">http://knb.ecoinformatics.org/software/eml/eml-2.1.1/eml-coverage.html</a>)<br />seem to suggest the opposite approach:</p>
<p>"The name representing the taxonomic rank of the taxon being described.<br />The values included may be referenced from an authoritative source such<br />as the Integrated Taxonomic Information System (ITIS)in the U.S.<br />(<a class="external" href="http://www/itis.usda.gov">http://www/itis.usda.gov</a>) and in Canada<br />(<a class="external" href="http://sis.agr.gc.ca/pls/itisca/taxaget">http://sis.agr.gc.ca/pls/itisca/taxaget</a>). Also, Species2000 is another<br />source of taxonomic information, found at (<a class="external" href="http://www.sp2000.org">http://www.sp2000.org</a>)<br />Example(s):<br />Acer would be an example of a genus rank value, and rubrum would be an<br />example of a species rank value, together indicating the common name of<br />red maple. It is recommended to start with Kingdom and include ranks<br />down to the most detailed level possible."</p> EML - Bug #5617 (New): date time format strings need a systemhttps://projects.ecoinformatics.org/ecoinfo/issues/56172012-06-05T20:45:23ZMargaret O'Brienmob@msi.ucsb.edu
<p>EML has a formatString element that takes text strings, and the spec give several examples. Translating dates would be much easier if the system which specified the format was included.</p>
<p>This data: 01May2007</p>
<p>The spec example suggests DDWWWYYYY<br />which is specified by the system [unknown]</p>
<p>Another representation of this date is</p>
<p><formatString>DDMonYYYY</formatString></p>
<p>which can be read directly by postgresql. So using something like this:<br /><formatString system="sql">DDMonYYYY</formatString></p>
<p>would be more informative and make interpretation easier for code like the DML.</p>
<p>example doc using this date format: knb-lter-sbc.61.1</p> Metacat - Bug #5616 (Resolved): See bug #5615 for EMLhttps://projects.ecoinformatics.org/ecoinfo/issues/56162012-06-05T18:48:34ZMargaret O'Brienmob@msi.ucsb.edu
<p>For good Metacat public relations, it is essential that EML documents be well- and completely presented.</p>
<p>The EML default HTML-skins need to be examined and then enhanced to make sure that they reflect good EML practice, and that labels and layout are intuitive to non-developers.</p>
<p>I made this a blocking issue, because to not do so before release would tarnish the reputation of Metacat. Others might disagree.</p> EML - Bug #5615 (New): Examine HTML skins for EMLhttps://projects.ecoinformatics.org/ecoinfo/issues/56152012-06-05T18:43:45ZMargaret O'Brienmob@msi.ucsb.edu
<p>examine EML default HTML-skins to make sure that they reflect good EML practice, and that labels and layout are intuitive to non-developers. This is especially important so that EML will reflect positively on applications which present it, like Metacat.</p> Morpho - Bug #5141 (Resolved): offer a choice to "cancel" from any savehttps://projects.ecoinformatics.org/ecoinfo/issues/51412010-08-11T21:20:24ZMargaret O'Brienmob@msi.ucsb.edu
<p>when a user choose to save a data package, there is usually not an option to cancel out of the operation. <br />1. For example, when there is a docid collision in Metacat, the user has to choose to increment the revision or let morpho choose a new docid. The user should also be able to cancel out altogether if s/he does not know which to choose.<br />2. if the log-in fails, the local doc is still saved. this should be optional.</p> Morpho - Bug #5139 (Resolved): morpho "preferences" and query speedhttps://projects.ecoinformatics.org/ecoinfo/issues/51392010-08-11T19:54:34ZMargaret O'Brienmob@msi.ucsb.edu
<p>Under "Set Preferences", a user can edit the Metacat installation that his/her client points to. It seems that Morpho queries are set up to match the indexing of the KNB metacat. So if you set this URL to anything other than the KNB, you run the risk of your queries running very, very slow (>5 minutes). At a minimum, this should be stated on the Preferences page.</p> Morpho - Bug #5138 (New): descriptions of queries need to be better describedhttps://projects.ecoinformatics.org/ecoinfo/issues/51382010-08-11T19:46:19ZMargaret O'Brienmob@msi.ucsb.edu
<p>Morpho currently has two options that run queries:<br />"open an existing data package" <br />"search for an existing data package"</p>
<p>This bug report has two parts: clarify what these do, and add a third option.</p>
<p>1. The difference between these is not clear. The first only returns datasets that the user owns. The second searches all readable packages (which is not particularly useful for package management). Since this difference is easy to forget, it should be clearer in the links.</p>
<p>2. The concept of ownership is problematic anyway, since there is no easy way to know who owns a document in Metacat, and the original owner may not be the manager. However, the permissions are easy to see and define, so a third query choice would be very helpful for management:<br />"List existing data packages that I have permission to manage"</p> Morpho - Bug #5128 (Resolved): access list does not show all dns in the LTER LDAP treehttps://projects.ecoinformatics.org/ecoinfo/issues/51282010-08-04T20:32:06ZMargaret O'Brienmob@msi.ucsb.edu
<p>When adding access rules for individuals, not all the people in the LTER tree are available. It appears that missing folks are the relatively recent additions, eg, since about 2008, but I cannot be sure of that.<br />this might be related to bug 3596.</p> Morpho - Bug #5118 (New): export function error reportinghttps://projects.ecoinformatics.org/ecoinfo/issues/51182010-08-04T16:29:17ZMargaret O'Brienmob@msi.ucsb.edu
<p>A user tried to export a data package to a directory that she did not have permission to write in (a drive mapped with smb). <br />Morpho's response was a message window: "Some problem with saving data files has occurred" (click OK), followed by a second message window: "Package export complete"</p>
<p>Two things:<br />1. Morpho should report a usable message for the problem, and <br />2. should not follow up with the same message it uses for successful exports.</p> EML - Bug #4683 (New): The knb xslt stylesheet display is squished over to the lefthttps://projects.ecoinformatics.org/ecoinfo/issues/46832010-01-21T01:15:15ZMargaret O'Brienmob@msi.ucsb.edu
<p>For a long time we have noticed that for some EML datasets, the HTML rendered by the knb or lter XSLT stylesheets (from metacat) is squashed over to the left side. It appears to be something about the column-width. Just now we found 2 consecutive revisions of a dataset where the earlier one does not squish, but the second one does. Those ids are:<br />knb-lter-mcr.9.4 (not squished)<br />knb-lter-mcr.9.5 (squished)<br />the difference between the 2 EML docs might help identify the XSLT problem. Both are EML2.1. The main difference between the 2 files is that the second one includes a methods tree. There might be a bug for this already -- if so sorry, I had no luck finding one.</p> Metacat - Bug #4676 (New): registry did not let me see my data table, although permissions are sethttps://projects.ecoinformatics.org/ecoinfo/issues/46762010-01-15T19:07:59ZMargaret O'Brienmob@msi.ucsb.edu
<p>I was demonstrating the knb dataset registry, and put in a test dataset (knb.230).<br />We logged in (as uid=mobrien,o=LTER...) While viewing the dataset, we clicked on the "View data table" link, and got the "public is not allowed to view this data table". I was still logged in, and the metadata for the data entity displayed an "authentication" value.</p> Morpho - Bug #4661 (Resolved): table 'worksheet' display not updated after table deletedhttps://projects.ecoinformatics.org/ecoinfo/issues/46612010-01-12T21:43:14ZMargaret O'Brienmob@msi.ucsb.edu
<p>a user wanted to replace a dataTable in a package. She chose 'Data->delete data table'. The data table disappeared, and she added uploaded a new table and a created a new set of attribute descriptions. So far, this is as expected.</p>
<p>However, when she finished the attribute descriptions, and Morpho displayed the table, it displayed the old attribute descriptions in the 'worksheet' pane. When she clicked on an attribute, the new attribute description was displayed on the right (alongside the old table). When she closed the data package and reopened, the new data table was there, so it seems to be just a worksheet display issue.</p>
<p>The EML docids are cdonahue.26.2 (old table, to be deleted) and cdonahue.26.3 (new table)</p> Metacat - Bug #4658 (Resolved): metacat runs out of memoryhttps://projects.ecoinformatics.org/ecoinfo/issues/46582010-01-09T00:13:12ZMargaret O'Brienmob@msi.ucsb.edu
<p>I parsed an EML 201 doc from:<br /><a class="external" href="http://knb.ecoinformatics.org/emlparser/parse">http://knb.ecoinformatics.org/emlparser/parse</a></p>
<p>I got a java error to the effect that it ran out of memory trying to read a zip(?) I dont have the error trace any more.</p> Morpho - Bug #4657 (Resolved): morpho creates <keyword> elements out of keywordType attribute con...https://projects.ecoinformatics.org/ecoinfo/issues/46572010-01-08T22:13:18ZMargaret O'Brienmob@msi.ucsb.edu
<p>the <keyword> element has an optional attribute keywordType, as in this snippet from knb-lter-sbc.17.12</p>
<p><keywordSet><br /> <keyword keywordType="theme">Santa Barbara Coastal</keyword><br /> <keyword keywordType="theme">LTER</keyword><br /></keywordSet></p>
<p>EML created by Morpho does not include this attribute, but when Morpho encounters one, it takes the attribute content and moves it to a keyword element, yielding a node like this (knb-lter-sbc.17.13):<br /><keywordSet><br /> <keyword>theme</keyword><br /> <keyword>Santa Barbara Coastal</keyword><br /> <keyword>theme</keyword><br /> <keyword>LTER</keyword><br /></keywordSet></p>
<p>So now we have extra erroneous keywords, and no keywordType attributes. <br />Morpho seems to do this as soon as it reads the EML in, since the extra keywords show up immediately.</p>
<p>Note: this data set is still EML201, and so was was edited with Morpho 1.6.1. I confirmed the behavior with Morpho 1.7 and a local test dataset.</p>