Kepler: Issueshttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362005-01-25T19:02:04ZEcoinformatics Redmine
Redmine Bug #1920 (New): Search based on semantic annotations of a dataset's attributeshttps://projects.ecoinformatics.org/ecoinfo/issues/19202005-01-25T19:02:04ZShawn Bowersbowers@gonzaga.eduBug #1919 (New): choose language for semantic annotations in kepler archiveshttps://projects.ecoinformatics.org/ecoinfo/issues/19192005-01-25T19:00:13ZShawn Bowersbowers@gonzaga.eduBug #1918 (New): Search based on the semantic annotation of an actor's porthttps://projects.ecoinformatics.org/ecoinfo/issues/19182005-01-25T18:59:11ZShawn Bowersbowers@gonzaga.eduBug #1917 (New): Design and implement workflow semantic type check.https://projects.ecoinformatics.org/ecoinfo/issues/19172005-01-25T18:57:59ZShawn Bowersbowers@gonzaga.edu
<p>Design and implement a feature similar to the Kepler type-system check (which<br />occurs after a workflow is executed), but for semantic annotations.</p>
<p>The semantic type-check should be a component (api) that can be called by<br />Kepler. Need a mechanism to report (through an interface) the semantic problems<br />of a workflow (if any exist), and possibly a mechanism to suggest ways to<br />correct the problems (a la the unit type system).</p> Bug #1916 (New): Implement semantic search for data and actors in local fileshttps://projects.ecoinformatics.org/ecoinfo/issues/19162005-01-25T18:54:03ZShawn Bowersbowers@gonzaga.edu
<p>The goal of this work is to decouple the semantic search as much as possible<br />from Kepler so we can shift the implementation to EcoGrid nodes and other remote<br />repositories.</p>
<p>Investigate whether it is feasible to combine the actor and data simple search<br />interfaces into a single set of search interfaces, that do not distinguish<br />between different object types.</p>
<p>Also, the resulting implementation should provide actor and data "smart" search<br />so that the implementations locally and remotely are the same.</p> Bug #1915 (New): Define a published interface for a semantic search servicehttps://projects.ecoinformatics.org/ecoinfo/issues/19152005-01-25T18:49:32ZShawn Bowersbowers@gonzaga.edu
<p>The purpose of this work is to define a generic api for "smart" search, which<br />implementation(s) will conform to. Each api operation will require both (1) a<br />public interface that external services will interface with (to call the desired<br />function), and (2) a description of the required backend information-storage<br />operations necessary to execute the desired functions. For example, this might<br />include the operation 'getObjectLSIDList(ObjectType) : ObjectLSIDList' that when<br />given an object type (such as "actor" or "dataset") will return all the LSIDs<br />for objects stored in the target backend repository.</p> Bug #1914 (In Progress): Implement the 'most recently used' concept for workflows and actorshttps://projects.ecoinformatics.org/ecoinfo/issues/19142005-01-24T18:45:25ZDan Higginshiggins@nceas.ucsb.eduBug #1911 (In Progress): Provide real-time feedback/animation for workflow progress as a defaulthttps://projects.ecoinformatics.org/ecoinfo/issues/19112005-01-24T18:05:57ZDan Higginshiggins@nceas.ucsb.edu
<p>Currently, one can set the workflow to show progress for SDF and some other<br />types of directors. Request is to make this the default (i.e. always show<br />progress). This may be difficult for PN networks.</p> Bug #1890 (In Progress): Add query builder to generic db actorhttps://projects.ecoinformatics.org/ecoinfo/issues/18902005-01-20T18:54:48ZEfrat Jaegerjaeger@ecoinformatics.org
<p>Modify the db actor to populate the query builder schema and use it through <br />the look inside option. Find out how to access MS Access schema in java <br />(Michael Finch?).</p> Bug #1884 (In Progress): Enable drag and drop of ports and relationshttps://projects.ecoinformatics.org/ecoinfo/issues/18842005-01-20T17:59:21ZChad Berkleyberkley@nceas.ucsb.edu
<p>you should be able to drag and drop the ports and relations instead of clicking<br />on the toolbar button and having the port appear somewhere. this functionality<br />should be similar to dragging an actor.</p> Bug #1749 (In Progress): Global toggle for port name displayhttps://projects.ecoinformatics.org/ecoinfo/issues/17492004-10-27T13:23:48ZBertram Ludaescherludaesch@sdsc.edu
<p>Port names can be quite informative (in particular when chosen carefully ;-) and<br />help understand a workflow. The display of portnames seems to be a local<br />property of actor ports now. I would like to suggest a global switch to turn<br />on/off the display of all portnames. The following would probably be good global<br />options:</p>
<p>- turn ON GLOBAL port name display (overriding local settings)<br />- turn OFF GLOBAL port name display (overriding local settings)<br />- turn ON LOCAL port name display (as provided by the local settings)</p>
<p>Bertram</p> Bug #1655 (In Progress): DIALOGS: Implement New UI for Sources Dialog (was "integrate ecogrid reg...https://projects.ecoinformatics.org/ecoinfo/issues/16552004-08-16T19:25:37ZMatt Jonesjones@nceas.ucsb.edu
<p>Currently EcoGrid access in Kepler works but the EcoGrid node that is queried is<br />a single configurable parameter. This needs to be changed to dynamically access<br />the EcoGrid registry and get the list of nodes to be queried from the registry.<br /> Then the kepler ecogrid query would be launched against these nodes, possibly<br />with the ability for the user to configure which nodes to search.</p>
<p>When searching multiple nodes, the results from each node need to be integrated.<br />The code for integrating the resultsets needs to accomodate different namespaces<br />(e.g., EML and Darwin Core) in the result set. The EcoGrid web interface will<br />also need this capability, so we can hopefully use the same resultset<br />integration code in both applications.</p>
<p>The current registry provides minimal metadata about each node, but eventually<br />we expect to have rich metadata (such as supported query namespaces, load,<br />coverage, etc). Once this metadata is available, the kepler client can be<br />smarter about which nodes are searched, possibly suggesting an appropriate<br />subset of nodes from the list.</p> Bug #1587 (In Progress): Define and implement EcoGrid "dataQuery" methodhttps://projects.ecoinformatics.org/ecoinfo/issues/15872004-06-07T16:46:10ZJing Taotao@nceas.ucsb.edu
<p>This ecogrid server side data query task. Bug 1586 will implement dataQuery in<br />kepler side (client side, query local data). In task, kepler will send a sql<br />query from kepler to ecogrid node. Ecogrid will excute this query and return<br />partial data object to client.<br />This bug will be done on the base of bug 1584.</p> Bug #1548 (In Progress): consolidating data access user interfaceshttps://projects.ecoinformatics.org/ecoinfo/issues/15482004-04-30T18:52:02ZMatt Jonesjones@nceas.ucsb.edu
<p>Currently Kepler contains several distinct methods for binding data sources to a<br />workflow. These include the EML200DataSource actor, the JDBC data source<br />actor(s), the incipient EcoGrid access interfaces, the GridFTP actor, and<br />probably others. Each of these exposes the data in a different way, and is<br />therefore multiply representing data in a confusing way. We need to consolidate<br />these approaches to find a single UI that can encapsualte all of the data access<br />approaches.</p>
<p>This proposal is to use and adapt the user interface described in<br />kepler/docs/dev/screenshots and related design documents to data access in<br />EcoGrid, GridFTP, JDBC, and other sources. This would allow a user to view data<br />uniformly in the workflow, regardless of which data access protocol is used to<br />get the data. This would also allow the user to specify subsetting constraints<br />(WHERE clause) uniformly, and to choose which attributes from the joined<br />relations are exposed to the workflow. Finally, it would allow us to use richer<br />metadata descriptions of underspecified data sources (like those found at the<br />other end of JDBC connections) so that the user (and ultimately the SEEK SMS<br />system) can reason about these data sources effectively.</p> Bug #1143 (In Progress): need SAS actorhttps://projects.ecoinformatics.org/ecoinfo/issues/11432003-09-15T18:03:34ZMatt Jonesjones@nceas.ucsb.edu
<p>Need to be able to run SAS jobs from within Ptolemy. Initially this could be a<br />port of the Monarch engine that hadles this.</p>
<p>Later on this could be run by having SAS on a server exposed as a Grid Service,<br />and therefore accessible through a GridService agent in Ptolemy. I'll post a<br />separte bug for creating GridService agents.</p>
<p>To close this bug, simply create an initial mechanism for running SAS jobs from<br />within Ptolemy.</p>