SEEK: Issueshttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362008-06-09T18:32:12ZEcoinformatics Redmine
Redmine Bug #3387 (New): ontology validationhttps://projects.ecoinformatics.org/ecoinfo/issues/33872008-06-09T18:32:12ZChad Berkleyberkley@nceas.ucsb.edu
<p>when an ontology is uploaded to metacat it should be validated in several ways (in addition to the xml validation that metacat already does):</p>
<ul>
<li>if it references other documents, the user should be asked to upload those documents as well.</li>
<li>referential integrity should be checked</li>
<li>owl validitiy should be checked</li>
</ul>
<p>Any errors should be reported back to the user.</p> Bug #3386 (New): ontology management with metacathttps://projects.ecoinformatics.org/ecoinfo/issues/33862008-06-09T18:17:33ZChad Berkleyberkley@nceas.ucsb.edu
<p>User should be able to browse ontologies in the system. Should also be able to update existing ontologies.</p> Bug #3145 (New): Fix [or remove] web interface for ecogrid queryhttps://projects.ecoinformatics.org/ecoinfo/issues/31452008-02-11T22:05:25Zben leinfelderleinfelder@nceas.ucsb.edu
<p>The Kepler user manual docs (chapter 6) have link to:<br /><a class="external" href="http://seek.ecoinformatics.org/Wiki.jsp?page=EarthGridPortal">http://seek.ecoinformatics.org/Wiki.jsp?page=EarthGridPortal</a><br />which in turn has a link to:<br /><a class="external" href="http://ecogrid.ecoinformatics.org/ecogrid/advancedQuery.jspx">http://ecogrid.ecoinformatics.org/ecogrid/advancedQuery.jspx</a></p>
<p>This search returns no data for KNB. Jing and I suspect it is due to the change in ecogrid query service names. The search should probably be updated to reflect those new endpoints. Also note that it has an option for searching GEON, too. The GEON service has not been operational for sometime, and could also be commented out, at the very least.</p> Bug #3112 (New): Deploy ecogrid-1.0.0 services for DiGIR and enforce namespaceshttps://projects.ecoinformatics.org/ecoinfo/issues/31122008-01-30T18:52:54Zben leinfelderleinfelder@nceas.ucsb.edu
<p>It was originally thought that the change in ecogrid namespaces (beta to 1.0) would be incompatible with the current DigirQueryService deployment (using beta namespaces). This appears not to be the case (they work together!) But, really, the namespaces <em>should</em> be enforced.<br />When the enhancements for doing faster (cached?) and better (dynamic providers listing?) digir queries are ready, we should deploy an updated version of this service.<br />Dave Vieglais sounds keen on this and will assist.</p> Bug #2730 (New): Publication problemhttps://projects.ecoinformatics.org/ecoinfo/issues/27302007-01-17T01:30:39Zxianhua liurobertliu325@yahoo.com
<p>For publication let's use be use to implement both short and long full text and guid. The rest is unnecessary for now.</p> Bug #2650 (New): ecogrid returnfields need to support more xpathhttps://projects.ecoinformatics.org/ecoinfo/issues/26502006-11-08T18:26:25ZChad Berkleyberkley@nceas.ucsb.edu
<p>When you are dealing with documents that store a lot of information in xml attributes instead of CDATA nodes, it is imperative that xpath attribute queries work correctly. AFAICT, they don't work at all with the ecogrid returnfields. For instance, the element:</p>
<p><property name="semanticType000" class="org.kepler.sms.SemanticType" <br /> value="urn:lsid:localhost:onto:1:1#Variable"><br /></property></p>
<p>The only meaniful way to get one of the attributes values based on another is via an attribute query like:</p>
<p>//property/[@name='semanticType000']/@value</p>
<p>which should return the value attribute of any property node with a name attribute equal to 'semanticType000'.</p> Bug #2649 (New): Ecogrid returnfields don't return enough informationhttps://projects.ecoinformatics.org/ecoinfo/issues/26492006-11-08T18:21:16ZChad Berkleyberkley@nceas.ucsb.edu
<p>When using returnfields in an ecogrid query, the original xpath used in the returnfield is not returned with the results, making it very difficult to parse the results. When a query is submited, a ResultsetTypeRecordReturnfield object is returned. This object only has two useful methods: get_value() and getId(). I thought getId() would return the original xpath query used to create the returnfield, but instead it returns a cryptic identifier starting with 'f' then a number.</p>
<p>Example:<br />Given these returnfields:<br /><returnField>/entity/@name</returnField><br /><returnField>/entity/property/@name</returnField><br /><returnField>/entity/property/@value</returnField></p>
<p>And this input document:</p>
<p><entity name="Variable Setter" class="ptolemy.kernel.ComponentEntity"><br /> <property name="entityId" value="urn:lsid:kepler-project.org:actor:10:2" <br /> class="org.kepler.moml.NamedObjId"/><br /> <property name="documentation" class="org.kepler.moml.DocumentationAttribute"><br /> null<br /> </property></p>
<pre><code>&lt;property name="class" value="ptolemy.actor.lib.SetVariable" <br /> class="ptolemy.kernel.util.StringAttribute"><br /> &lt;property name="id" value="null" <br /> class="ptolemy.kernel.util.StringAttribute"/><br /> &lt;/property&gt;</code></pre>
<pre><code>&lt;property name="kepler:input" class="org.kepler.moml.PortAttribute"&gt;<br /> &lt;property name="direction" value="input" <br /> class="ptolemy.kernel.util.StringAttribute"/><br /> &lt;property name="dataType" value="unknown" <br /> class="ptolemy.kernel.util.StringAttribute"/><br /> &lt;property name="isMultiport" value="false" <br /> class="ptolemy.kernel.util.StringAttribute"/><br /> &lt;/property&gt;</code></pre>
<pre><code>&lt;property name="variableName" class="ptolemy.kernel.util.StringAttribute" <br /> value="parameter"><br /> &lt;/property&gt;<br /> &lt;property name="delayed" class="ptolemy.data.expr.Parameter" value="true"&gt;<br /> &lt;/property&gt;<br /> &lt;property name="semanticType000" class="org.kepler.sms.SemanticType" <br /> value="urn:lsid:localhost:onto:1:1#Variable"><br /> &lt;/property&gt;<br /> &lt;property name="semanticType111" class="org.kepler.sms.SemanticType" <br /> value="urn:lsid:localhost:onto:2:1#LocalInput"><br /> &lt;/property&gt;<br /> &lt;property name="_location" class="ptolemy.kernel.util.Location" <br /> value="{250, 300}"><br /> &lt;/property&gt;<br /> &lt;property name="karId" class="ptolemy.kernel.util.StringAttribute" <br /> value="urn:lsid:kepler-project.org:kar:11:1"><br /> &lt;/property&gt;<br />&lt;/entity&gt;</code></pre>
<p>You will get returnfields (in the format getId():get_value()) like this:<br />returnfield: f0:Variable Setter<br />returnfield: f1:entityId<br />returnfield: f2:urn:lsid:kepler-project.org:actor:10:2<br />returnfield: f1:documentation<br />returnfield: f1:class<br />returnfield: f2:ptolemy.actor.lib.SetVariable<br />returnfield: f1:kepler:input<br />returnfield: f1:variableName<br />returnfield: f2:parameter<br />returnfield: f1:delayed<br />returnfield: f2:true<br />returnfield: f1:semanticType000<br />returnfield: f2:urn:lsid:localhost:onto:1:1#Variable<br />returnfield: f1:semanticType111<br />returnfield: f2:urn:lsid:localhost:onto:2:1#LocalInput<br />returnfield: f1:_location<br />returnfield: f2:{250, 300}<br />returnfield: f1:karId<br />returnfield: f2:urn:lsid:kepler-project.org:kar:11:1</p>
<p>Instead, there either needs to be a new method, getQuery(), that would return the query for each field, or the getId() should return the query or some other more meaninful identifier.</p> Bug #2301 (New): deploy ecogrid-1.0.0beta2 services for metacat, srb, digir, geonhttps://projects.ecoinformatics.org/ecoinfo/issues/23012005-11-29T21:28:11ZMatt Jonesjones@nceas.ucsb.edu
<p>Need to coordinate the deployment of the beta2 release so that all services are<br />deployed at the same time. Deployment really can not occur until all of the<br />migration to web services bugs are complete (bug 2294, bug 2295, bug 2296, bug<br />2297, bug 2298).</p> Bug #1790 (New): Add ITIS data to TOS db v1.1.0https://projects.ecoinformatics.org/ecoinfo/issues/17902004-11-29T18:35:44ZAimee Stewartastewart@ku.eduBug #1663 (New): Create web prototypehttps://projects.ecoinformatics.org/ecoinfo/issues/16632004-08-30T21:34:39ZRobert Galesrgales@eecs.ku.edu
<p>By TDWG - Create a web-based prototype of the current version of the Taxon<br />service that is easily modified for future versions</p> Bug #1648 (New): Create taxon developer web site which calculates metrics of codehttps://projects.ecoinformatics.org/ecoinfo/issues/16482004-07-27T04:11:46ZAimee Stewartastewart@ku.eduBug #1591 (New): generate browsing ontologieshttps://projects.ecoinformatics.org/ecoinfo/issues/15912004-06-07T17:52:31ZChad Berkleyberkley@nceas.ucsb.edu
<p>need to generate simple browsing ontologies for kepler. Need to include<br />habitats, spatial regions, TL taxa, etc. See the knb.ecoinformatics.org home<br />page for example categories.</p> Bug #1163 (New): install and configure certificate authority system for ecogridhttps://projects.ecoinformatics.org/ecoinfo/issues/11632003-09-26T21:43:59ZMatt Jonesjones@nceas.ucsb.edu
<p>We need a common mechanism for authenticating users for EcoGrid. We have<br />general agreement that the OGSA Grid Security Infrastructure (GSI) is the right<br />way to handle this. For that to work, every user needs to have a public key<br />certificate which is signed by a certificate authority (CA). In Seattle Sept 23<br />the EcoGrid team agreed that the best way to handle this is through a<br />hierarchichal certificate granting structure. A root EcoGrid CA will sign<br />certificates for various organizations such as LTER and NCEAS, and they in turn<br />will sign certificates for users in their organization. This 'chain-of-trust',<br />if properly managed, should establish strong security and be scalable to the ><br />5000 scientists in our current personnel directories.</p>
<p>Each of these trusted CA's would probably also act as one of the distributed<br />EcoGrid Registries for locating services throughout the grid.</p>
<p>For this to work, we need a simple system in place for users to request<br />certificates and for the CA admins to sign them. Matt agreed to tackle this.</p>
<p>The tricky issues remaining here include:<br /> 1) What system can be used for distributing DN info to mapfiles?<br /> 2) How can browser-based interfaces be used with certificates?</p> Bug #1070 (New): propose a flexible system for transformation stepshttps://projects.ecoinformatics.org/ecoinfo/issues/10702003-05-20T17:16:49ZMatt Jonesjones@nceas.ucsb.edu
<p>In any workflow, linking any two steps is likely to require some sort of<br />transformation to get the outputs of one step to match the inputs of the next. <br />This transformation is sometimes a simple cast (e.g., int -> float), sometimes a<br />more complex cast (e.g., string -> date), sometimes will require more complex<br />processing (e.g., statistical processing), and sometimes will require schema<br />transformations. In all cases, the transformation between step A and step Z can<br />be represented as one or more intermediate tansformation steps:<br /> A -> T1 -> T2 -> TN -> Z</p>
<p>Our challenge includes:</p>
<p>1) use the SMS to locate candidate transformation steps T1..TN based on type<br />signature and ontologies<br />2) determine how to generate transformation steps automatically for simple<br />transforms such as unit conversions<br />3) create a simple GUI for creating transformation steps that map between two<br />existing steps<br />4) determine the pros and cons of having transformation steps be directly<br />associated with links (e.g., a link property) rather than simply introducing new<br />transform steps that do the same tasks directly into the pipeline</p>
<p>So, the objective of this bug is to:<br />1) propose a flexible system for discovering and generating transformation steps<br />2) identify the suite of complex issues involved in generating a mapping from<br />one step to another (especially when this might require several intermediate steps)<br />3) propose a plan of work for completing this plan</p> Bug #1059 (New): create testing harness for ecogridhttps://projects.ecoinformatics.org/ecoinfo/issues/10592003-05-19T19:57:31ZMatt Jonesjones@nceas.ucsb.edu
<p>We need a common testing harness that can be used to launch client queries<br />against ecogrid nodes and validate that the results returned are correct. This<br />system would be a basic client application, and so the core of it could be<br />reused in other clients if it is properly designed.</p>
<p>Who: Higgins<br />Target: June 9</p>