Semtools: Issueshttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362011-04-04T21:33:37ZEcoinformatics Redmine
Redmine Bug #5372 (Resolved): Update annotation entries when updated in Metacathttps://projects.ecoinformatics.org/ecoinfo/issues/53722011-04-04T21:33:37Zben leinfelderleinfelder@nceas.ucsb.edu
<p>There is a new MetacatEventService that allows components (SemtoolsPlugin) to register as a listener for MetacatEvents that occur like 'insert', 'update', and 'delete'.<br />Annotations are added or removed as appropriate when these actions take place in Metacat. So a save in Morpho to Metacat makes the annotation available for query immediately.</p> Bug #5370 (Resolved): AnnotationManager: persistence layer [re]initializationhttps://projects.ecoinformatics.org/ecoinfo/issues/53702011-04-04T21:18:19Zben leinfelderleinfelder@nceas.ucsb.edu
<p>When using the server-based persistence layer, Annotations that have previously been processed/imported will remain in the DB and can be immediately queried. The Metacat plugin, however, currently loops through every annotation document it finds during restart to load into this DB. We should add a configuration switch that is set in Metacat once the annotations have been imported so that it only happens once (and again when Metacat is upgraded/redeployed in the future, but not on every application restart). This is very similar to how the spatial cache works. Typically the annotations will be processed individually when they are inserted/updated/deleted (using the event handler).</p>
<p>Note: this will not work if we are using the in-memory Derby DB (like we would in Morpho and other smaller client-side deployments of the SMS library).</p> Bug #5134 (Resolved): Editing multiple data packages changes annotation for both windowshttps://projects.ecoinformatics.org/ecoinfo/issues/51342010-08-09T23:26:46Zben leinfelderleinfelder@nceas.ucsb.edu
<p>Was watching over Margaret's shoulder and we noticed that when two DP windows were open, changes made to one annotation (Column Annotation tab) would show in the other's window. This included ontology class selection and the selected column.</p> Bug #5102 (Resolved): Save Measurement template classhttps://projects.ecoinformatics.org/ecoinfo/issues/51022010-07-27T20:52:55Zben leinfelderleinfelder@nceas.ucsb.edu
<p>Currently only the Entity, Characteristic, Standard and Protocol are saved in the annotation even if those values came from a Measurement defined in the ontology. We should save the Measurement class that was selected. It's unclear which of those will the be the 'authority' in cases where they conflict. But for some query capabilities it will be good to have this information since it can quickly exploit more complex measurements (that might rely on additional context details).</p> Bug #5035 (Resolved): Lost Annotations; discarded Annotation changeshttps://projects.ecoinformatics.org/ecoinfo/issues/50352010-05-28T17:46:00Zben leinfelderleinfelder@nceas.ucsb.edu
<p>Scenario 1:<br />1. open an annotated DP<br />2. edit the an annotation class selection (say, MeasurementStandard)<br />3. edit an EML field (say, the DP title)<br />4. frame will refresh, and the annotation change is discarded.<br />The reason this is happening is because Morpho disposes and then recreates another frame each time the DP is edited. The annotation plugin responds to the frame disposal as though the DP was being closed and clears out the annotation changes, reloading the annotation from the version stored on disk.</p>
<p>Scenario 2:<br />1. open a local annotated DP<br />2. attempt to save to the network<br />3. docid revision must be incremented (conflict on server)<br />4. network save fails (in my case I am trying to save over a previously deleted DP on Metacat - save should fail)<br />5. the frame refreshes with the updated docid revision and no location (this DP docid is not saved locally nor to metacat).<br />6. as in Scenario 1, the old frame has been discarded along with the annotation for that DP even though it was associated with the new docid.<br />7. because there is no location from which to reload the annotation from disk, the annotation appears to be missing.</p>
<p>I think the solution I will try to implement is that if the DP has a blank location, the annotation will not be discarded in favor of a version on disk (because we don't really know where that should come from - local v. network). When opening a DP, we will load the annotation from the location we are opening the DP from. When the frame for that DP closes, we will discard the existing annotation only if the location is known, otherwise the annotation will persist in memory so that frame refreshes will not discard annotations or changes to those annotations. I'm concerned we might end up with annotation changes that we really do want to discard, but at the moment I can't think of a better solution than to try this.</p> Bug #5000 (Resolved): oboe-core: comment all classes and propertieshttps://projects.ecoinformatics.org/ecoinfo/issues/50002010-05-12T16:08:53ZShawn Bowersbowers@gonzaga.edu
<p>Provide comments for each class and property definition. Many of these can be taken from oboe.owl.</p> Bug #4951 (Resolved): Add "?" help buttons/info on the annotation tabshttps://projects.ecoinformatics.org/ecoinfo/issues/49512010-04-19T20:37:04Zben leinfelderleinfelder@nceas.ucsb.edu
<p>Full, Column and Context tabs all need help buttons to walk future users through the UI/annotation process.<br />There is help content accessible via the "Annotate Current Column..." dialog which could be used in these other locations.</p> Bug #4950 (Resolved): Toggle "edit mode" on Annotation tabshttps://projects.ecoinformatics.org/ecoinfo/issues/49502010-04-19T20:35:22Zben leinfelderleinfelder@nceas.ucsb.edu
<p>Currently the Column Annotation and Context Annotation tabs are always in edit mode, so to speak. Any changes made to the UI are auto-saved when a different column is selected or a different tab is clicked. This can be: <br />-overkill (if you've not actually made any changes) <br />-confusing/annoying (if you didn't want to save the changes)<br />-complicated (on the implementation side)</p>
<p>An alternate mode could be that the fields are disabled until switching to "edit mode" at which point the editable fields become such. Exiting edit mode will save the changes made, while switching to another column or tab will prompt to save if still in edit mode, or do nothing if edit mode is disabled.</p> Bug #4949 (Resolved): Add class label under madlib fieldshttps://projects.ecoinformatics.org/ecoinfo/issues/49492010-04-19T20:30:49Zben leinfelderleinfelder@nceas.ucsb.edu
<p>Easier said than done considering the limited vertical space: ever-present reminders of the appropriate class for a madlib field would be helpful (i.e. "Entity").</p> Bug #4948 (Resolved): Clarify importance of Measurement "template" fieldhttps://projects.ecoinformatics.org/ecoinfo/issues/49482010-04-19T20:26:18Zben leinfelderleinfelder@nceas.ucsb.edu
<p>In the Column Annotation (and also the search UI) you can select a single Measurement subclass and have the other 4 class fields populate from the ontology (provided there are full definitions). This is not very obvious in the current UI - perhaps an indication of "--OR--" would be helpful.</p> Bug #4947 (Resolved): Search ontology tree only using class namehttps://projects.ecoinformatics.org/ecoinfo/issues/49472010-04-19T20:20:10Zben leinfelderleinfelder@nceas.ucsb.edu
<p>We are currently searching classname and all descriptions/labels for contains (not starts-with). This should be limited to the classname. Debate over starts-with/contains is ongoing.</p> Bug #4945 (Resolved): Add scrollbars to search UIhttps://projects.ecoinformatics.org/ecoinfo/issues/49452010-04-19T20:16:35Zben leinfelderleinfelder@nceas.ucsb.edu
<p>If you add enough criteria, you will exceed the size of the window.</p> Bug #4922 (Resolved): DB-driven Annotation Managerhttps://projects.ecoinformatics.org/ecoinfo/issues/49222010-03-31T23:22:46Zben leinfelderleinfelder@nceas.ucsb.edu
<p>The current AnnotationManager implementation reads XML serializations into Annotation objects in memory. Any operations (search, edit) operate on the in-memory version and are then serialized to XML (save). This doesn't scale and also doesn't make it all that easy to issue complex searches.<br />I'd still keep the XML serializations as a transport mechanism and archive method (<cough> Metacat)</p>
<p>Pros:<br />-allows us to index annotations by various criteria<br />-efficient querying<br />-won't run out of memory<br />Cons:<br />-DB overhead/configuration<br />-not binding to actual data (or are we?)</p> Bug #4906 (Resolved): Annotation query implementation (SPARQL)https://projects.ecoinformatics.org/ecoinfo/issues/49062010-03-29T18:33:27Zben leinfelderleinfelder@nceas.ucsb.edu
<p>Matt recommends materializing the Annotation and Ontology as instances in the OBOE model for running searches.<br />I need to investigate how this can be done.</p> Bug #4905 (Resolved): iTunes-inspired search UIhttps://projects.ecoinformatics.org/ecoinfo/issues/49052010-03-29T18:30:06Zben leinfelderleinfelder@nceas.ucsb.edu
<p>Compound search should be more flexible and allow 2-levels of any/all grouping.<br />Example query that should be expressible:<br />---<br />Any<br /> All<br /> Entity is Vertegrate<br /> Entity is not Amphibian<br /> Characteristic is Length<br /> All<br /> Entity is Vertebrate<br /> Entity is not Mammal<br /> Characteristic is SkullWidth<br /> All<br /> Measurement is AmmoniumConcentration<br /> x is y<br /> y is z</p>