SEEK: Issueshttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362007-01-17T01:30:39ZEcoinformatics Redmine
Redmine 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 #2292 (In Progress): out of memory problems on DiGIR EcoGrid implementationhttps://projects.ecoinformatics.org/ecoinfo/issues/22922005-11-29T20:14:33ZMatt Jonesjones@nceas.ucsb.edu
<p>When resultsets are large, the DiGIR implementation can run out of memory. This<br />is a problem related to how the resultset is built up in memory and needs to be<br />fixed to support arbitraily large (or at least very large) result sets.</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 #1761 (In Progress): Update object model (v1.1.0) to more closely mirror TCShttps://projects.ecoinformatics.org/ecoinfo/issues/17612004-11-08T15:43:46ZAimee Stewartastewart@ku.edu
<p>Relationships are handled slightly differently, return values for<br />getRelatedConcept change, objects mirror TCS more closely.</p> Bug #1677 (In Progress): Modify concept package objects to handle relationships for TOS v1.1.0https://projects.ecoinformatics.org/ecoinfo/issues/16772004-09-13T17:34:46ZAimee Stewartastewart@ku.edu
<p>Create CRelationshipTo objects to be held within CConcept objects. Create<br />CRelationshipAssertion objects to be used for 3rd party relationships. Remove<br />CRelatedConcept.</p> Bug #1673 (In Progress): Work with XSLT parser to convert ITIS data for input to Taxon DBhttps://projects.ecoinformatics.org/ecoinfo/issues/16732004-09-09T22:53:50ZAimee Stewartastewart@ku.edu
<p>Modify and use XSLT parser written by Dave Thau to convert existing ITIS data<br />from v0.51 into current (0.71) schema.</p> Bug #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 #1166 (In Progress): create a schema for registry metadatahttps://projects.ecoinformatics.org/ecoinfo/issues/11662003-09-26T22:09:19ZMatt Jonesjones@nceas.ucsb.edu
<p>Need a schema that defines the metadata associated with an EcoGrid Registry. <br />Minimally this is the GSH of the registry, but it also will likely include other<br />information, such as contact info for the maintainers, and mechanisms to get<br />lists of the services registered there (probably already part of the ogsa<br />registry interface). Matt agreed to start this, and Raja will review it.</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>