Metacat: Issueshttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362014-02-11T18:34:16ZEcoinformatics Redmine
Redmine Feature #6416 (In Progress): Do not allow restrictive access control change to content with a DOIhttps://projects.ecoinformatics.org/ecoinfo/issues/64162014-02-11T18:34:16Zben leinfelderleinfelder@nceas.ucsb.eduFeature #6362 (New): Add an id to the year element in the citation in eml-indentifier.xslhttps://projects.ecoinformatics.org/ecoinfo/issues/63622014-01-06T19:30:51ZLauren Walkerwalker@nceas.ucsb.eduTask #5994 (New): Create REST API for accessing statisticshttps://projects.ecoinformatics.org/ecoinfo/issues/59942013-05-25T01:16:03ZMatt Jonesjones@nceas.ucsb.edu
<p>For objects, users, packages, nodes, etc.</p> Bug #5830 (New): Deployment directory incorrecthttps://projects.ecoinformatics.org/ecoinfo/issues/58302013-01-29T23:05:21ZBrendan Hahnhahn@nceas.ucsb.edu
<p>Metacat stores its deployment directory in metacat.properties, where the value can lose sync with the actual deployment. The deployment directory is a discoverable feature of the environment and should be dynamically determined rather than configured as a property.</p> Bug #5821 (New): Allow certificate-based Metacat administrationhttps://projects.ecoinformatics.org/ecoinfo/issues/58212013-01-24T22:12:04Zben leinfelderleinfelder@nceas.ucsb.edu
<p>As we move toward the DataONE API where the MN does not provide identity and authorization services, perhaps the Metacat administrative functions should also follow suit. This would be a pretty large change for our users, but ultimately will simplify things so that we are not using two different identity/auth schemes to manage a single server.</p>
<p>In cases where the Metacat administrator did not have a useable (CILogon) identity we cold provide a utility to generate a client certificate for administrative use (or something akin to this). Ultimately this would need to be available in a browser UI where the bulk of our admin/config is performed.</p> Bug #5709 (Resolved): Cannot download XML for private datapackages shown in XSL displayhttps://projects.ecoinformatics.org/ecoinfo/issues/57092012-09-11T16:23:48Zben leinfelderleinfelder@nceas.ucsb.edu
<p>Meei-ru pointed out that the data file downloads <em>do</em> work but that you get a permission error ("public not allowed") when attempting to download the EML source (qformat=xml) from the page where you are already viewing the EML (styled by skin).</p>
<p>I traced it down to two things:<br />1. "sessionid" is not included in the EML download link like it is in the data download link.<br />2. The default skin login form does not seem to correctly set the session cookie. I expected that in lieu of the sessionid parameter, Metacat would look at my browser cookie for the sessionid and use that. This is the case for the admin login screen and for the dev skin login. Looking briefly at the default skin login, it uses the Metacat client to do the authentication call and then manually set the cookie in the browser (at path "/knb/style/skins/default/"). Using the dev skin, the cookie is set at "/knb").</p> Bug #5547 (New): Couldn't get the Register Data Form after login under Register Data tab on Sanpa...https://projects.ecoinformatics.org/ecoinfo/issues/55472011-11-21T18:17:38ZJing Taotao@nceas.ucsb.edu
<p>When you click "Register Data" tab on Sanparks skin, it will show a login form if you haven't login. However, it will show a successful page without any clue to get the register data form when user successfully login. I think the correct behavior should be showing the register data form.</p> Bug #3835 (In Progress): design and implement OAI-PMH compliant harvest subsystemhttps://projects.ecoinformatics.org/ecoinfo/issues/38352009-02-24T02:06:53ZMatt Jonesjones@nceas.ucsb.edu
<p>Metacat's current harvest mechanism works well but is a proprietary system. The Dryad project has proposed to implement an OAI-PMH compliant harvest susbstem for Metacat in order to allow Metacat to interact more effectively with other systems that implement this protocol. This is a tracking bug for the design and implementation of this feature. Other more detailed bugs will be filed for specific tasks. It would be useful if the final system allowed Metacat to act as both an OAI-PMH Data Provider and as an OAI-PMH Service Provider, allowing us to both serve and harvest documents from OAI-PMH servers.</p>
<p>Some issues to consider and discuss:<br />1) lack of record authorization mechanisms in OAI-PMH. Metacat currently allows harvest with access controls on harvested records. Reverting to a purely OAI-PMH system would eliminate this capability that is used by many of our harvest clients (especially for data, but somewhat for metadata as well). So the design needs to consider a hybrid that allows both public records to be exposed through OAI-PMH and restricted records to be exposed through a protocol like Metacat's that supports access control. What is our design goal here?</p>
<p>2) A corollary of (1) is how to determine who is allowed to update a given record. Does OAI-PMH assume providers always originate from a constant URL endpoint in order to get around authenticating data providers? This is probably not reasonable for even short periods of time (a few years). A number of sites change domain names over short period of times, and the harvester needs to be able to adjust to these changes, update endpoints, and still handle record replacement. Maybe this is a non-issue if PMH allows provider endpoints to be updated.</p>
<p>3) Date-based change detection in OAI-PMH versus GUID-based versioning in metacat. How should these be reconciled? If a PMH harvest occurs every ten days, but a metadata document is revised three times in that interval, does OAI-PMH only get the most recent version? How are the other versions archived and made accessible over time?</p>
<p>4) Data objects. The Metacat harvester allows one to transfer objects of any type, which is used to harvest both metadata objects of various formats (e.g., EML and FGDC) as well as the associated data objects. Each of these objects has their own unique identifier. How would this be handled under OAI-PMH?</p>
<p>A nice background set of slides is here:<br /><a class="external" href="http://www.oaforum.org/otherfiles/berl_oai-tutorial_e.ppt">http://www.oaforum.org/otherfiles/berl_oai-tutorial_e.ppt</a></p> Bug #3383 (In Progress): Create RPM/Deb installation utilitieshttps://projects.ecoinformatics.org/ecoinfo/issues/33832008-06-09T16:23:24ZMichael Daigledaigle@nceas.ucsb.edu
<p>Phase II of the turnkey installation project is the creation of an install utility for linux</p> Bug #2849 (New): Bounding box problems when spanning the meridianhttps://projects.ecoinformatics.org/ecoinfo/issues/28492007-05-22T16:35:33ZCallie Bowdishbowdish@nceas.ucsb.edu
<p>Bounding box problems when large areas span the meridian. Please see this reference <a class="external" href="http://purl.oclc.org/coordinates/a2.htm">http://purl.oclc.org/coordinates/a2.htm</a></p>
<p>"While there is no beginning or end on a globe, digital spatial data sets have an artificially defined beginning and end. Longitude extends from 180 degrees west (-180) to 180 degrees east (+180) of Greenwich, United Kingdom, and latitude extends from 90 degrees south (-90) to 90 degrees north (+90) of the Equator. This artificial segmentation of geographic coordinates results in a 'Global Gotcha' for bounding boxes of features spanning the 180-degree meridian." .. Consider the imaginary country of Boxtopia, which has a southwest corner at (170, 40) and a northeast corner at (-170, 50). The width of this box is 20 degrees. In a spatial database, Boxtopia would be represented by two rectangles, one which has a southwest corner at (170, 40) and a northeast corner at (180, 50) and a second that has a southwest corner at (-180, 40) and a northeast corner at (-170, 50). This split is required because the longitude must be between -180 and 180 degrees.. "unfortunately, no simple and elegant solution exists to solving the Global Gotchas. Multipart bounding boxes are a possible alternative, but they add complexity to the database and search process, defeating the simplicity of the bounding box." (Unlocking the Mysteries of the Bounding Box <a class="external" href="http://purl.oclc.org/coordinates/a2.htm">http://purl.oclc.org/coordinates/a2.htm</a>)</p>
<p>Rick Reeves recommends having the option to enter more than one bounding box with the KNB online registries. Currently people can enter in more than one keyword and more than one taxonomic entry through an Add button.</p>
<p>This has the potential of helping with searches when users make a large bounding box because they do not have the option of entering in a number of smaller bounding boxes. Bug 2732 mentions the problem of bring up all of the global data sets when doing a search using the KNB Data Catalog Map.</p> Bug #2501 (New): Add links to FGDC-tranformed version of EML documentshttps://projects.ecoinformatics.org/ecoinfo/issues/25012006-07-27T16:51:32ZWill Tyburczytyburczy@nceas.ucsb.edu
<p>When viewing EML documents, the user should be provided with a link (under "Metadata Downloads") that gives the EML-to-FGDC transformed version of the metadata.</p> Bug #2310 (Resolved): Advanced search functionality has to be integrated into various skins.https://projects.ecoinformatics.org/ecoinfo/issues/23102005-12-08T18:38:06ZSaurabh Gargsgarg@nceas.ucsb.edu
<p>The new advanced functionality needs to be integrated into all the skins. Right <br />now it is only part of the default skin.</p> Bug #2229 (New): Allowing web registry pull-down menu for "Station Name" to select multiple stat...https://projects.ecoinformatics.org/ecoinfo/issues/22292005-10-11T23:07:08ZWill Tyburczytyburczy@nceas.ucsb.eduBug #1300 (New): Changes in DataSet Orignatorhttps://projects.ecoinformatics.org/ecoinfo/issues/13002004-02-02T23:03:10ZSaurabh Gargsgarg@nceas.ucsb.edu
<p>1) Eliminate the label "Originator Address Information" <br />2) Change the Originator label to "Principal Data Set Owner" <br />3) Decerease # of roles to: PI, Custodian/Steward, Metadata Provider, Owner. <br />This change will need to be done at other places also where this list is being <br />used.</p> Bug #421 (In Progress): create simple turnkey installer for metacat Phase IIhttps://projects.ecoinformatics.org/ecoinfo/issues/4212002-02-13T18:32:47ZChad Berkleyberkley@nceas.ucsb.edu
<p>we need to use the previously protyped metacat installer to build a robust, one<br />click installer for metacat that includes Tomcat, Ant, Metacat, PostgresSQL and<br />any other tools that are necessary.</p>
<p>We should do this for the next release of Metacat.</p>