Metacat: Issueshttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362006-07-31T19:55:05ZEcoinformatics Redmine
Redmine Bug #2503 (Resolved): Metacat Servlet action=spatial_query returns incorrect resultshttps://projects.ecoinformatics.org/ecoinfo/issues/25032006-07-31T19:55:05ZMatthew Perryperry@nceas.ucsb.edu
<p>It appears that the metacat spatial query (metacat?action=spatial_query) does not return correct results. Based on a few test cases, it appears that only spatial queries which intersect the north-west corner of the geographic coverage return a correct result. This indicates a rather serious error in the spatial intersection logic.</p> Bug #2467 (Resolved): IE auto-stretch does not display correctly with eml-2.0.0 data packageshttps://projects.ecoinformatics.org/ecoinfo/issues/24672006-06-21T18:01:03ZCallie Bowdishbowdish@nceas.ucsb.edu
<p>Data Packages created with eml.2.0.0 do not display correcly when using the ESA, KNB, NRS, OBFS and NCEAS skins on Internet Explorer.</p>
<p>knb: <a class="external" href="http://knb.ecoinformatics.org/knb/metacat?action=read&qformat=knb&docid=nceas.146">http://knb.ecoinformatics.org/knb/metacat?action=read&qformat=knb&docid=nceas.146</a></p>
<p>nceas: <a class="external" href="http://knb.ecoinformatics.org/knb/metacat?action=read&qformat=nceas&docid=nceas.146">http://knb.ecoinformatics.org/knb/metacat?action=read&qformat=nceas&docid=nceas.146</a></p>
<p>Data packages that contain this in the eml file have problems transforming correctly. <eml:eml xmlns:eml="eml://ecoinformatics.org/eml-2.0.0" xmlns:stmml="http://www.xml-cml.org/schema/stmml" xmlns:ds="eml://ecoinformatics.org/dataset-2.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" packageId="nceas.146.5" scope="system" system="knb" xsi:schemaLocation="eml://ecoinformatics.org/eml-2.0.0 eml.xsd"></p>
<p>Data Package nceas.146 is the first one in the NCEAS list of data packages when Browse existing NCEAS data sets is chosen.</p> Bug #2466 (Resolved): knb skin does not auto-stretch correctly on IEhttps://projects.ecoinformatics.org/ecoinfo/issues/24662006-06-21T17:33:46ZCallie Bowdishbowdish@nceas.ucsb.edu
<p>Internet Explorer does not auto-stretch correctly using the knb skin.</p>
<p><a class="external" href="http://knb.ecoinformatics.org/knb/metacat?action=read&qformat=knb&docid=nceas.289.1">http://knb.ecoinformatics.org/knb/metacat?action=read&qformat=knb&docid=nceas.289.1</a> or nceas.289.2 do not display correctly when using the knb skin. The NCEAS skin auto-stretch works with nceas skin. <a class="external" href="http://knb.ecoinformatics.org/knb/metacat?action=read&qformat=nceas&docid=nceas.289.2">http://knb.ecoinformatics.org/knb/metacat?action=read&qformat=nceas&docid=nceas.289.2</a></p>
<p>Note that this document has large paragraphs.</p> Bug #2371 (Resolved): Replication problem with links with '&'https://projects.ecoinformatics.org/ecoinfo/issues/23712006-02-28T20:02:49ZDan Higginshiggins@nceas.ucsb.edu
<p>There seems to be problem in replicating datapackages with links that contain<br />the '&' character.<br />In particular, consider the knb-lter-gce.232.5 package. Using morpho and KNB, the<br />Online Distribution element is:</p>
<p><a class="external" href="http://gce-lter.marsci.uga.edu/lter/asp/db/send_file.asp?name=metacat-user&ail=none&filiation=LNO&tify=0&cession=INV-GCEM-0412b1&lename=INV-GCEM-0412b1_1_0.TXT">http://gce-lter.marsci.uga.edu/lter/asp/db/send_file.asp?name=metacat-user&ail=none&filiation=LNO&tify=0&cession=INV-GCEM-0412b1&lename=INV-GCEM-0412b1_1_0.TXT</a></p>
<p>while in ecogrid it is:</p>
<p><a class="external" href="http://gce-lter.marsci.uga.edu/lter/asp/db/send_file.asp?name=metacat-user&il=none&iliation=LNO&ify=0&ession=INV-GCEM-0412b1&ename=INV-GCEM-0412b1_1_0.TXT">http://gce-lter.marsci.uga.edu/lter/asp/db/send_file.asp?name=metacat-user&il=none&iliation=LNO&ify=0&ession=INV-GCEM-0412b1&ename=INV-GCEM-0412b1_1_0.TXT</a></p>
<p>Note the loss of characters after the '&'s !!!</p>
<p>This is making it impossible to retreive data in Kepler (and in Morpho)</p> Bug #2317 (Resolved): modify ldapweb.cgi to restrict account creationhttps://projects.ecoinformatics.org/ecoinfo/issues/23172005-12-13T23:09:34ZMatt Jonesjones@nceas.ucsb.edu
<p>ldapweb.cgi currently allows account creation in multiple LDAP subtrees based on<br />the organizationthe user selects. In future systems we will want much more<br />control of accounts that are created in particular subtrees (such as NCEAS), so<br />we need to change ldapweb.cgi to only allow account creation in the<br />"unafiliated" subtree. The script should check input and make sure that<br />unaffiliated is chosen and send back an error if not.</p> Bug #2312 (Resolved): finalize header graphic for ESA registryhttps://projects.ecoinformatics.org/ecoinfo/issues/23122005-12-08T18:43:06ZMatt Jonesjones@nceas.ucsb.edu
<p>The header is almost complete except for final wording changes on buttons and<br />final detail on the moderation list button. This button needs to be part of the<br />main toolbar if possible. Othersise, it probably needs to be set off more.</p>
<p>Deadline: Dec 14</p> Bug #2311 (Resolved): modify stylesheets to display citation formathttps://projects.ecoinformatics.org/ecoinfo/issues/23112005-12-08T18:40:24ZMatt Jonesjones@nceas.ucsb.edu
<p>Wehn displaying EML documents in the ESA registry (and maybe others in the<br />future), we will want to display the 'citation format' that was agreed upon for<br />ESA at the top of the EML display page. This means modifying the EML stylesheets.</p>
<p>The citation display should be configurable to choose whether to display<br />identifiers as metacat identifiers (the default) or as LSID identifiers (used<br />for ESA skin for now). I can give pointers on how to do this.</p>
<p>The citation format to be displayed should be:</p>
<p>Robert SW, Hopkins R, and Marker PM. 2005. Distribution and abundance of<br />mussels in the intertidal zone of Santa Barbara Channel from 2000 to 2004. ESA<br />Data Registry urn:lsid:esa.org:esadata:104:1 (<a class="external" href="http://data.esa.org">http://data.esa.org</a>).</p>
<p>Lets boldface the title in the display and see how that works.</p>
<p>These fields should probably replace the existing top of the form where the<br />identifier and title are displayed, and delete the "Data Set Description" <br />heading as it doesn't add anything.</p> Bug #2222 (Resolved): Bug in squery when using not-containshttps://projects.ecoinformatics.org/ecoinfo/issues/22222005-10-05T20:40:37ZSaurabh Gargsgarg@nceas.ucsb.edu
<p>For the following squery:<br /><pathquery version="1.2"><br /><querytitle>Moderator-Search</querytitle><br /><returndoctype>eml://ecoinformatics.org/eml-2.0.1</returndoctype><br /><returndoctype>eml://ecoinformatics.org/eml-2.0.0</returndoctype><br /><returndoctype>-//ecoinformatics.org//eml-dataset-2.0.0beta6//EN</returndoctype><br /><returndoctype>-//ecoinformatics.org//eml-dataset-2.0.0beta4//EN</returndoctype><br /><returndoctype>-//NCEAS//resource//EN</returndoctype><br /><returndoctype>-//NCEAS//eml-dataset//EN</returndoctype><br /><returnfield>originator/individualName/surName</returnfield><br /><returnfield>originator/individualName/givenName</returnfield><br /><returnfield>creator/individualName/surName</returnfield><br /><returnfield>creator/individualName/givenName</returnfield><br /><returnfield>originator/organizationName</returnfield><br /><returnfield>creator/organizationName</returnfield><br /><returnfield>dataset/title</returnfield><br /><returnfield>keyword</returnfield><br /><querygroup operator="INTERSECT"><br /><queryterm searchmode="not-contains" <br />casesensitive="false"><value>public</value><pathexpr>dataset/access/allow/princi<br />pal</pathexpr></queryterm><br /></querygroup></pathquery></p>
<p>The key part here is:<br /><queryterm searchmode="not-contains" <br />casesensitive="false"><value>public</value><pathexpr>dataset/access/allow/princi<br />pal</pathexpr></queryterm></p>
<p>i.e. dataset/access/allow/principal should not have 'public' value.</p>
<p>This request is resulting in the following query:<br />SELECT docid,docname,doctype,date_created, date_updated, rev FROM <br />xml_documents WHERE docid IN ((SELECT DISTINCT docid FROM xml_path_index <br />WHERE <abbr title="nodedata">UPPER</abbr> NOT LIKE '%PUBLIC%' AND path LIKE <br />'dataset/access/allow/principal' )) AND (docid IN(SELECT docid FROM <br />xml_documents WHERE lower(user_owner) ='public') OR (docid IN (SELECT <br />docid from xml_access <abbr title=" (lower(principal_name">WHERE</abbr> = 'public' AND <br />perm_type = 'allow' AND (permission='4' OR permission='7'))OR <br />(lower(principal_name) = 'public' AND perm_type = 'allow' AND <br />(permission='4' OR permission='7'))) AND subtreeid IS NULL) AND docid <br />NOT IN (SELECT docid from xml_access <abbr title=" (lower(principal_name">WHERE</abbr> = <br />'public' AND perm_type = 'deny' AND perm_order ='allowFirst' AND <br />(permission='4' OR permission='7'))OR (lower(principal_name) = 'public' <br />AND perm_type = 'deny' AND perm_order ='allowFirst' AND (permission='4' <br />OR permission='7'))) AND subtreeid IS NULL )))</p>
<p>This is not right as it still gives me back documents which have <br />'public' value in dataset/access/allow/principal. The part which is <br />wrong is:<br />SELECT DISTINCT docid FROM xml_path_index WHERE <abbr title="nodedata">UPPER</abbr> NOT LIKE <br />'%PUBLIC%' AND path LIKE 'dataset/access/allow/principal'</p>
<p>The query should be something like this: (maybe a simpler version of this)<br />SELECT DISTINCT docid from xml_path_index where docid NOT IN (Select <br />docid FROM xml_path_index WHERE <abbr title="nodedata">UPPER</abbr> LIKE '%PUBLIC%' AND path <br />LIKE 'dataset/access/allow/principal') ;</p> Bug #2220 (Resolved): Temporal coverage on Data Registry formhttps://projects.ecoinformatics.org/ecoinfo/issues/22202005-10-04T17:07:37ZVeronique Connollyconnolly@nceas.ucsb.edu
<p>In the Temporal Coverage of Data section of the NCEAS Data Repository form<br />(<a class="external" href="http://knb.ecoinformatics.org/cgi-bin/register-dataset.cgi?cfg=nceas">http://knb.ecoinformatics.org/cgi-bin/register-dataset.cgi?cfg=nceas</a>), the<br />year, month, and day are indicated as being required. However, if you enter a<br />year, but don't select a month and/or day (leave them as "0"), you don't get an<br />error message for the missing month and day, and the values that you left as "0" <br />become "1" (01 01 yyyy).</p>
<p>We should allow the user to provide the year only (month and day would not be<br />required fields), and the month and day should not be displayed if they were not<br />selected.</p> Bug #2218 (Resolved): Data medium info not saved in editing modehttps://projects.ecoinformatics.org/ecoinfo/issues/22182005-09-30T20:26:27ZVeronique Connollyconnolly@nceas.ucsb.edu
<p>When you go back to the data registry form (this was for the NCEAS skin) after<br />getting a failure message (by using the link in "Click here to return to the<br />form, fill in the required fields, and submit the data set description again"),<br />the option that was previously selected under "Data medium" doesn't appear,<br />i.e., the info previously submitted wasn't saved.</p> Bug #2217 (Resolved): Change output text for Usage rightshttps://projects.ecoinformatics.org/ecoinfo/issues/22172005-09-30T20:08:09ZVeronique Connollyconnolly@nceas.ucsb.edu
<p>Under the "Usage Rights" field, when you select "Obtain permission from data set<br />owner(s)" the output (what appears in the data package) is simply "permissions".<br />The output should be "Obtain permission from data set owner(s)".</p> Bug #2215 (Resolved): NCEAS skin: NCEAS Project(s) should be a required fieldhttps://projects.ecoinformatics.org/ecoinfo/issues/22152005-09-30T19:45:04ZVeronique Connollyconnolly@nceas.ucsb.edu
<p>On the NCEAS data repository form<br />(<a class="external" href="http://knb.ecoinformatics.org/cgi-bin/register-dataset.cgi?cfg=nceas">http://knb.ecoinformatics.org/cgi-bin/register-dataset.cgi?cfg=nceas</a>), the<br />field "NCEAS Project(s)" should be a required field. If you don't select<br />anything from the drop-down menu and click on the submit button, you don't get<br />an error message saying you should have selected a project.</p> Bug #2214 (Resolved): Submitting lat/long coordinates in spatial coverage sectionhttps://projects.ecoinformatics.org/ecoinfo/issues/22142005-09-30T19:40:01ZVeronique Connollyconnolly@nceas.ucsb.edu
<p>A data package was created using the NCEAS Data Repository form. When<br />coordinates 53 deg, 34 min, 0 sec N, and 0 deg , 2 min, 0 sec W were entered in<br />the SPATIAL COVERAGE OF DATA section, this error message came up:</p>
<p>Failure<br />An error occurred. Please check the list of errors below:</p>
<ul>
<li>cvc-complex-type.2.4.b: The content of element 'geographicCoverage' is not<br />complete. One of '{"":boundingCoordinates}' is expected.</li>
</ul>
<p>Click here to return to the form, fill in the required fields, and submit the<br />data set description again.</p>
<p>It didn't seem to like the 0 degrees for the longitude because when it was<br />changed to "1", it worked.</p> Bug #2211 (Resolved): automatically insert pubDate on registry submissionhttps://projects.ecoinformatics.org/ecoinfo/issues/22112005-09-28T23:08:40ZCallie Bowdishbowdish@nceas.ucsb.edu
<p>We need to automatically insert pubDate on registry submission. The 'pubDate'<br />field represents the date that the resource was published. The format should be<br />represented as: CCYY, which represents a 4 digit year, or as CCYY-MM-DD, which<br />denotes the full year, month, and day. Note that month and day are optional<br />components. Formats must conform to ISO 8601</p>
<p>Updated and new version of data packages that have been submitted to the<br />registry will have a new pubDate.</p>
<p>IRQ conversation, " yeah, an updated document is really a new version with a new<br />date the (modified) resource was published <matt> so it should proabbly be<br />updated <matt> the original revision will still have the original pubDate<br /><matt> so nothing is lost"</p>
<p>Note: This will be used for citations and will be used with citation information<br />in stylesheets along with the lsid on the ESA stylesheet.</p> Bug #2207 (Resolved): Advanced Search integrationhttps://projects.ecoinformatics.org/ecoinfo/issues/22072005-09-26T22:20:40ZDuane Costadcosta@lternet.edu
<p>Over the past year, the LTER Network Office has developed an Advanced Search web<br />application that uses the Metacat client to run an advanced search on criteria<br />such as subject, author, spatial, and taxon. In its current form, the Advanced<br />Search interface exists as a separate web application, outside of the Metacat<br />code base. The goal of this task is the integrate the Advanced Search web<br />application with the Metacat code base, as described in more detail below.</p>
<hr />
<p>Proposal to Integrate Advanced Search Capability <br />with Metacat Distribution</p>
<p>The goal is to refactor the Query application so that major parts<br />of it would be integrated with Metacat, while other parts of it<br />could be customized for LTER-specific needs and maintained<br />independent of Metacat.</p>
<p>1. Query Engine</p>
<p>The back-end Query Engine can be fully integrated with the Metacat<br />code base. It contains search engine functionality that is<br />generic to Metacat and should be relatively easy to factor out of <br />the Query application. Once it is part of Metacat, it can be<br />packaged as a library that can be distributed with the Query<br />application. After it is integrated with Metacat, the Query Engine <br />code can be maintained by all Metacat developers. If logical <br />improvements or performance optimizations are made to the Query <br />Engine code by the Metacat community, the LTER Query application<br />will benefit from these improvements and optimizations because <br />it will utilize the same code that Metacat utilizes.</p>
<p>2. Advanced Search Form</p>
<p>The Advanced Search Form is implemented as a JSP. It can be <br />reimplemented to eliminate the Struts-based custom tags that it <br />currently uses. JavaScript could be added to replace the <br />Struts-generated JavaScript for client-side form validation; <br />alternatively, form validation could be moved to the server side.</p>
<p>A LTER-customized version of the Advanced Search Form could be <br />maintained in the Query Application. It would be nearly identical<br />to the Metacat version, but it would contain additional input fields,<br />such as a drop-down list that allows the user to restrict the search<br />results to a particular LTER site.</p>
<p>If possible, a mechanism would be worked out to minimize the<br />duplication of effort that would be required to maintain both the <br />Metacat form and the custom LTER form and to keep them consistent.</p>
<p>3. Login Page, Simple Search Page, and Browse Page</p>
<p>These pages in the Query Application would not be integrated with <br />Metacat, since equivalent functionality already exists in the <br />default Metacat skin. These pages would continue to be part of the <br />Query application. Since the Query application uses Struts to manage <br />the functionality of these pages, we could continue to use Struts <br />in the Query application, though we would not need Struts in Metacat.</p>
<p>We may be able to utilize the Metacat skin to provide this <br />functionality for the Query application. Eventually, we may be<br />able to fully migrate all of the functionality of the Query application<br />to Metacat, though we would need to provide a way to extend the<br />Metacat skin with LTER customizations.</p>
<p>The current browse capability of the Query Application is intended<br />to be replaced by a browsable hierarchy of terms based on the work<br />that is being initiated in the LTER working groups for Ontologies<br />and Controlled Vocabularies. Since this work would be a valuable <br />contribution to Metacat as well, it would be useful to integrate <br />these new browse capabilities in the Metacat skin rather than <br />restrict them to just the Query application.</p>
<p>Work Estimates:</p>
<p>Task Effort (Weeks)<br />---- --------------</p>
<p>Phase One:</p>
<p>These tasks would fulfill Matt's requirements<br />to integrate the Advanced Search capability with<br />Metacat, while retaining the Query application as a<br />LTER custom application that shares some of its<br />software components with Metacat.</p>
<pre><code>Refactor Query Engine. Add code 1<br /> to Metacat. Refactor Query Application<br /> to use Metacat library.</code></pre>
<pre><code>Refactor Advanced Search Form to eliminate 1<br /> Struts custom tags.</code></pre>
<pre><code>Implement generic Advanced Search Form and 1<br /> integrate it with Metacat Skin. Maintain custom<br /> LTER form in the Query Application as an<br /> extension to the Metacat form.</code></pre>
<p>Phase Two:</p>
<p>This optional phase would deprecate the Query application<br />as a separate entity, eliminating the duplication of <br />effort needed to keep its advanced search functionality <br />consistent with Metacat's. The time estimates for these<br />tasks should be adjusted after Phase One is completed,<br />since we will have a better understanding of the effort<br />required at that point.</p>
<p>Fully migrate the Query Application to Metacat, 2<br />allowing for LTER customizations within Metacat.<br />Other organizations could use the LTER customizations<br />in Metacat as a model for their own customizations.</p>
<hr />
<p>On 9/6/2005, Mark Servilla wrote:</p>
<p>Hi Matt,</p>
<p>Attached, please find a brief statement of work proposed by Duane Costa<br />regarding the Advanced Query Interface for metacat. We consider the<br />re-unification of the two applications to be a high-priority to the LTER, NCEAS,<br />and the eco-community, and will begin the planning/work effort immediately. At<br />your earliest convenience, please review the SOW and let us know if this is<br />acceptable and/or if you have any questions/comments.</p>
<p>Sincerely,<br />Mark</p>
<hr />
<p>On 9/6/2005, Matt Jones wrote:</p>
<p>Hi Mark,</p>
<p>Thanks. In general this statement of work looks great -- no real modifications<br />on my part. It will be a great time-saver for many people who want an advanced<br />search in their metacat installation, so I appreciate it.</p>
<p>A couple of brief comments for context:<br />1) We need to revise our login infrastructure. Right now metacat uses cookies<br />for session state. That has worked well, and is pretty robust.<br /> We also have a more recent javascript login for managing the cookies on the KNB<br />and default skins -- this is incomplete and therefore broken, although it is<br />what is used on the main KNB page. The problem is that the session information<br />does not propagate across pages as one navigates through the app, especially in<br />the EML pages. We know why, but haven't fixed it. It would be a good time to do<br />so, so let us know if you have particular needs in your part of the login<br />infrastructure.<br />2) We've wanted an effective browsable hierarchy of terms for KNB datasets, but<br />there just is't consensus on a controlled vocabulary. The one on the KNB skin is<br />one I made up with feedback from Mark S and a few others. If you get consensus<br />with LTER, we'd probably want to switch the KNB in general over to using it and<br />creating a browsing interface that allows one to navigate it. So that might be<br />another area for shared work.<br />3) I think the advanced search page needs a map to draw a box for spatial<br />searches. We've found users simply don't know the lat/lon for their area of<br />interest.<br />4) We are working on a spatial option for metacat for Kruger that allows the<br />locations of data to be plotted against other GIS layers in a map and searched<br />using spatial queries. This is in prototype now, but will be released hopefully<br />with the next metacat release. Just a FYI in case a similar request has come<br />your way.<br />5) The new SEEK web developer located at LNO (in process of hiring replacement<br />for Tekell) will be working on a portal for access to EcoGrid data (both EML and<br />DarwinCore). I hope we will be able to adapt your client interface so that it<br />can be applied to the web services backend in EcoGrid, as I think the<br />requirements are essentially the same.</p>
<p>Thanks. Looking forward to working on this with you.</p>
<p>Matt</p>
<hr />
<p>On 9/23/05, Mark Servilla wrote:</p>
<p>Hi Matt,</p>
<p>Sorry for the delay in getting back to this matter. After discussing your<br />comments with Duane, the only item that impacts our involvement directly is<br />number 1 - the session management. It will be critical to work this problem to<br />completion. With respect to number 3, the map UI, we would appreciate any<br />suggestions in this area; short of installing a full-up ArcIMS/MapServer type of<br />application. Is there a simple javascript version for such a map? A first<br />version of this would require only the bounding lat/lon for the query. Thanks!</p>
<p>Sincerely,<br />Mark</p>
<hr />
<p>On 9/23/05, Matt Jones wrote:</p>
<p>Mark,</p>
<p>Thanks for the followthrough. I agree that (1) needs to be worked out, and I'd<br />like to see the GT4 GSI certificate stuff that NCSA did before we decide on a<br />solution. We should probably take an approach that accomodates that if we're<br />delving into the auth infrastructure. <br />Regarding (3), I think there are several open-source geospatial libs for doing<br />this (we use one of them in Morpho). Maybe Duane could talk to John Harris (who<br />is working on this stuff in metacat now) and Dan Higgins (who did the geospatial<br />map in morpho) and come up with a proposal? My impression is that the java lib<br />Dan used was pretty effective and easy to plug into morpho, and I think others<br />have come about. GEON has one in their portal search client, so we might be<br />able to borrow code or ideas from them. We definitely don't want an IMS for<br />this part -- our needs are much simpler.</p>
<p>Matt</p>