{"action":"closed","issue":{"url":"https://api.github.com/repos/NCEAS/metacat/issues/347","repository_url":"https://api.github.com/repos/NCEAS/metacat","labels_url":"https://api.github.com/repos/NCEAS/metacat/issues/347/labels{/name}","comments_url":"https://api.github.com/repos/NCEAS/metacat/issues/347/comments","events_url":"https://api.github.com/repos/NCEAS/metacat/issues/347/events","html_url":"https://github.com/NCEAS/metacat/issues/347","id":302246831,"number":347,"title":"Advanced Search integration","user":{"login":"mbjones","id":766407,"avatar_url":"https://avatars0.githubusercontent.com/u/766407?v=4","gravatar_id":"","url":"https://api.github.com/users/mbjones","html_url":"https://github.com/mbjones","followers_url":"https://api.github.com/users/mbjones/followers","following_url":"https://api.github.com/users/mbjones/following{/other_user}","gists_url":"https://api.github.com/users/mbjones/gists{/gist_id}","starred_url":"https://api.github.com/users/mbjones/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mbjones/subscriptions","organizations_url":"https://api.github.com/users/mbjones/orgs","repos_url":"https://api.github.com/users/mbjones/repos","events_url":"https://api.github.com/users/mbjones/events{/privacy}","received_events_url":"https://api.github.com/users/mbjones/received_events","type":"User","site_admin":false},"labels":[{"id":822385528,"url":"https://api.github.com/repos/NCEAS/metacat/labels/Category:%20metacat","name":"Category: metacat","color":"ededed","default":false},{"id":822385150,"url":"https://api.github.com/repos/NCEAS/metacat/labels/Component:%20Bugzilla-Id","name":"Component: Bugzilla-Id","color":"ededed","default":false},{"id":822385147,"url":"https://api.github.com/repos/NCEAS/metacat/labels/Priority:%20Normal","name":"Priority: Normal","color":"ededed","default":false},{"id":822385142,"url":"https://api.github.com/repos/NCEAS/metacat/labels/Status:%20Resolved","name":"Status: Resolved","color":"ededed","default":false},{"id":822385145,"url":"https://api.github.com/repos/NCEAS/metacat/labels/Tracker:%20Bug","name":"Tracker: Bug","color":"ededed","default":false}],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":{"url":"https://api.github.com/repos/NCEAS/metacat/milestones/13","html_url":"https://github.com/NCEAS/metacat/milestone/13","labels_url":"https://api.github.com/repos/NCEAS/metacat/milestones/13/labels","id":3157877,"number":13,"title":"1.6","description":null,"creator":{"login":"mbjones","id":766407,"avatar_url":"https://avatars0.githubusercontent.com/u/766407?v=4","gravatar_id":"","url":"https://api.github.com/users/mbjones","html_url":"https://github.com/mbjones","followers_url":"https://api.github.com/users/mbjones/followers","following_url":"https://api.github.com/users/mbjones/following{/other_user}","gists_url":"https://api.github.com/users/mbjones/gists{/gist_id}","starred_url":"https://api.github.com/users/mbjones/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mbjones/subscriptions","organizations_url":"https://api.github.com/users/mbjones/orgs","repos_url":"https://api.github.com/users/mbjones/repos","events_url":"https://api.github.com/users/mbjones/events{/privacy}","received_events_url":"https://api.github.com/users/mbjones/received_events","type":"User","site_admin":false},"open_issues":0,"closed_issues":16,"state":"open","created_at":"2018-03-03T02:31:10Z","updated_at":"2018-03-05T10:31:47Z","due_on":null,"closed_at":null},"comments":5,"created_at":"2018-03-05T10:31:43Z","updated_at":"2018-03-05T10:31:47Z","closed_at":"2018-03-05T10:31:46Z","author_association":"CONTRIBUTOR","body":"---\n\n\nAuthor Name: **Duane Costa** (Duane Costa)\nOriginal Redmine Issue: 2207, https://projects.ecoinformatics.org/ecoinfo/issues/2207\nOriginal Date: 2005-09-26\nOriginal Assignee: Duane Costa\n\n---\n\nOver the past year, the LTER Network Office has developed an Advanced Search web\r\napplication that uses the Metacat client to run an advanced search on criteria\r\nsuch as subject, author, spatial, and taxon. In its current form, the Advanced\r\nSearch interface exists as a separate web application, outside of the Metacat\r\ncode base. The goal of this task is the integrate the Advanced Search web\r\napplication with the Metacat code base, as described in more detail below.\r\n\r\n----\r\n\r\nProposal to Integrate Advanced Search Capability \r\nwith Metacat Distribution\r\n\r\nThe goal is to refactor the Query application so that major parts\r\nof it would be integrated with Metacat, while other parts of it\r\ncould be customized for LTER-specific needs and maintained\r\nindependent of Metacat.\r\n\r\n\r\n1. Query Engine\r\n\r\nThe back-end Query Engine can be fully integrated with the Metacat\r\ncode base. It contains search engine functionality that is\r\ngeneric to Metacat and should be relatively easy to factor out of \r\nthe Query application. Once it is part of Metacat, it can be\r\npackaged as a library that can be distributed with the Query\r\napplication. After it is integrated with Metacat, the Query Engine \r\ncode can be maintained by all Metacat developers. If logical \r\nimprovements or performance optimizations are made to the Query \r\nEngine code by the Metacat community, the LTER Query application\r\nwill benefit from these improvements and optimizations because \r\nit will utilize the same code that Metacat utilizes.\r\n\r\n\r\n2. Advanced Search Form\r\n\r\nThe Advanced Search Form is implemented as a JSP. It can be \r\nreimplemented to eliminate the Struts-based custom tags that it \r\ncurrently uses. JavaScript could be added to replace the \r\nStruts-generated JavaScript for client-side form validation; \r\nalternatively, form validation could be moved to the server side. \r\n\r\nA LTER-customized version of the Advanced Search Form could be \r\nmaintained in the Query Application. It would be nearly identical\r\nto the Metacat version, but it would contain additional input fields,\r\nsuch as a drop-down list that allows the user to restrict the search\r\nresults to a particular LTER site.\r\n\r\nIf possible, a mechanism would be worked out to minimize the\r\nduplication of effort that would be required to maintain both the \r\nMetacat form and the custom LTER form and to keep them consistent.\r\n\r\n\r\n3. Login Page, Simple Search Page, and Browse Page\r\n\r\nThese pages in the Query Application would not be integrated with \r\nMetacat, since equivalent functionality already exists in the \r\ndefault Metacat skin. These pages would continue to be part of the \r\nQuery application. Since the Query application uses Struts to manage \r\nthe functionality of these pages, we could continue to use Struts \r\nin the Query application, though we would not need Struts in Metacat.\r\n\r\nWe may be able to utilize the Metacat skin to provide this \r\nfunctionality for the Query application. Eventually, we may be\r\nable to fully migrate all of the functionality of the Query application\r\nto Metacat, though we would need to provide a way to extend the\r\nMetacat skin with LTER customizations.\r\n\r\nThe current browse capability of the Query Application is intended\r\nto be replaced by a browsable hierarchy of terms based on the work\r\nthat is being initiated in the LTER working groups for Ontologies\r\nand Controlled Vocabularies. Since this work would be a valuable \r\ncontribution to Metacat as well, it would be useful to integrate \r\nthese new browse capabilities in the Metacat skin rather than \r\nrestrict them to just the Query application.\r\n\r\n\r\nWork Estimates:\r\n\r\nTask                                               Effort (Weeks)\r\n----                                               --------------\r\n\r\nPhase One: \r\n\r\nThese tasks would fulfill Matt's requirements\r\nto integrate the Advanced Search capability with\r\nMetacat, while retaining the Query application as a\r\nLTER custom application that shares some of its\r\nsoftware components with Metacat.\r\n\r\n  Refactor Query Engine. Add code                         1\r\n  to Metacat. Refactor Query Application\r\n  to use Metacat library.\r\n\r\n  Refactor Advanced Search Form to eliminate              1\r\n  Struts custom tags.\r\n\r\n  Implement generic Advanced Search Form and              1\r\n  integrate it with Metacat Skin. Maintain custom\r\n  LTER form in the Query Application as an\r\n  extension to the Metacat form.\r\n\r\n\r\nPhase Two:\r\n\r\nThis optional phase would deprecate the Query application\r\nas a separate entity, eliminating the duplication of \r\neffort needed to keep its advanced search functionality \r\nconsistent with Metacat's. The time estimates for these\r\ntasks should be adjusted after Phase One is completed,\r\nsince we will have a better understanding of the effort\r\nrequired at that point.\r\n\r\n\r\nFully migrate the Query Application to Metacat,           2\r\nallowing for LTER customizations within Metacat.\r\nOther organizations could use the LTER customizations\r\nin Metacat as a model for their own customizations.\r\n\r\n----\r\n\r\nOn 9/6/2005, Mark Servilla wrote:\r\n\r\nHi Matt,\r\n\r\nAttached, please find a brief statement of work proposed by Duane Costa\r\nregarding the Advanced Query Interface for metacat.  We consider the\r\nre-unification of the two applications to be a high-priority to the LTER, NCEAS,\r\nand the eco-community, and will begin the planning/work effort immediately.  At\r\nyour earliest convenience, please review the SOW and let us know if this is\r\nacceptable and/or if you have any questions/comments.\r\n\r\nSincerely,\r\nMark\r\n\r\n----\r\n\r\nOn 9/6/2005, Matt Jones wrote:\r\n\r\nHi Mark,\r\n\r\nThanks. In general this statement of work looks great -- no real modifications\r\non my part.  It will be a great time-saver for many people who want an advanced\r\nsearch in their metacat installation, so I appreciate it.\r\n\r\nA couple of brief comments for context:\r\n1) We need to revise our login infrastructure.  Right now metacat uses cookies\r\nfor session state.  That has worked well, and is pretty robust.\r\n We also have a more recent javascript login for managing the cookies on the KNB\r\nand default skins -- this is incomplete and therefore broken, although it is\r\nwhat is used on the main KNB page.  The problem is that the session information\r\ndoes not propagate across pages as one navigates through the app, especially in\r\nthe EML pages.  We know why, but haven't fixed it. It would be a good time to do\r\nso, so let us know if you have particular needs in your part of the login\r\ninfrastructure.\r\n2) We've wanted an effective browsable hierarchy of terms for KNB datasets, but\r\nthere just is't consensus on a controlled vocabulary. The one on the KNB skin is\r\none I made up with feedback from Mark S and a few others.  If you get consensus\r\nwith LTER, we'd probably want to switch the KNB in general over to using it and\r\ncreating a browsing interface that allows one to navigate it.  So that might be\r\nanother area for shared work.\r\n3) I think the advanced search page needs a map to draw a box for spatial\r\nsearches.  We've found users simply don't know the lat/lon for their area of\r\ninterest.\r\n4) We are working on a spatial option for metacat for Kruger that allows the\r\nlocations of data to be plotted against other GIS layers in a map and searched\r\nusing spatial queries.  This is in prototype now, but will be released hopefully\r\nwith the next metacat release.  Just a FYI in case a similar request has come\r\nyour way.\r\n5) The new SEEK web developer located at LNO (in process of hiring replacement\r\nfor Tekell) will be working on a portal for access to EcoGrid data (both EML and\r\nDarwinCore).  I hope we will be able to adapt your client interface so that it\r\ncan be applied to the web services backend in EcoGrid, as I think the\r\nrequirements are essentially the same.\r\n\r\nThanks.  Looking forward to working on this with you.\r\n\r\nMatt\r\n\r\n----\r\n\r\nOn 9/23/05, Mark Servilla wrote:\r\n\r\nHi Matt,\r\n\r\nSorry for the delay in getting back to this matter.  After discussing your\r\ncomments with Duane, the only item that impacts our involvement directly is\r\nnumber 1 - the session management.  It will be critical to work this problem to\r\ncompletion.  With respect to number 3, the map UI, we would appreciate any\r\nsuggestions in this area; short of installing a full-up ArcIMS/MapServer type of\r\napplication.  Is there a simple javascript version for such a map?  A first\r\nversion of this would require only the bounding lat/lon for the query.  Thanks!\r\n\r\nSincerely,\r\nMark\r\n\r\n----\r\n\r\nOn 9/23/05, Matt Jones wrote:\r\n\r\nMark,\r\n\r\nThanks for the followthrough.  I agree that (1) needs to be worked out, and I'd\r\nlike to see the GT4 GSI certificate stuff that NCSA did before we decide on a\r\nsolution.  We should probably take an approach that accomodates that if we're\r\ndelving into the auth infrastructure. \r\nRegarding (3), I think there are several open-source geospatial libs for doing\r\nthis (we use one of them in Morpho).  Maybe Duane could talk to John Harris (who\r\nis working on this stuff in metacat now) and Dan Higgins (who did the geospatial\r\nmap in morpho) and come up with a proposal?  My impression is that the java lib\r\nDan used was pretty effective and easy to plug into morpho, and I think others\r\nhave come about.  GEON has one in their portal search client, so we might be\r\nable to borrow code or ideas from them.  We definitely don't want an IMS for\r\nthis part -- our needs are much simpler.\r\n\r\nMatt\n\n\n"}}
{"actor":{"display_login":"mbjones"}}