head	1.5;
access;
symbols;
locks; strict;
comment	@# @;


1.5
date	2005.09.21.03.56.08;	author MattJones;	state Exp;
branches;
next	1.4;

1.4
date	2005.09.21.03.55.25;	author MattJones;	state Exp;
branches;
next	1.3;

1.3
date	2005.09.21.03.54.59;	author MattJones;	state Exp;
branches;
next	1.2;

1.2
date	2005.09.21.03.54.43;	author MattJones;	state Exp;
branches;
next	1.1;

1.1
date	2005.09.21.03.21.38;	author MattJones;	state Exp;
branches;
next	;


desc
@
.
@


1.5
log
@
.
@
text
@---++ Kepler 

The [[http://kepler-project.org][Kepler scientific workflow system]] is an analysis and modeling environment for composing and executing complex scientific models in a reproducable, visual programming environment.  Kepler can access ecological monitoring data from the [[http://knb.ecoinformatics.org][KNB]] with the same calls that it accesses biodiversity collections data through the GBIF DiGIR portal and the GEON Data Portal by making direct calls to the EcoGrid.

Kepler uses LSID identifiers internally to track all of the analytical components that are associated with a given Kepler workflow.   Each analytical component has its own unique [[LSID]], and workflows reference these [[LSID]]s in the process of creating more complex hierarchical models.  The final analytical model that is created in Kepler can be archived in a special format that preserves all of the model dependencies through an XML serialization of the model (MoML).  The references to external model components are accomplished through the use of [[LSID]]s.

The [[http://seek.ecoinformatics.org][SEEK project]] is working to build a distributed repository of executable modeling components using [[LSID]]s to uniquely identify the components and store them on the EcoGrid.  Using this system, the same programmatic EcoGrid APIs that can be used to discover and access environmental data will be able to be used to reference models and statistical analyses that use those data.

----
[[ExistingProjects][Back to existing projects using LSIDs]]@


1.4
log
@
.
@
text
@d5 1
a5 1
Kepler uses LSID identifiers internally to track all of the analytical components that are associated with a given Kepler workflow.   Each analytical component has its own unique LSID, and workflows reference these LSIDs in the process of creating more complex hierarchical models.  The final analytical model that is created in Kepler can be archived in a special format that preserves all of the model dependencies through an XML serialization of the model (MoML).  The references to external model components are accomplished through the use of [[LSID]]s.
@


1.3
log
@
.
@
text
@d5 1
a5 1
Kepler uses LSID identifiers internally to track all o fthe analytical components that are associated with a given Kepler workflow.   Each analytical component has its own unique LSID, and workflows reference these LSIDs in the process of creating more complex hierarchical models.  The final analytical model that is created in Kepler can be archived in a special format that preserves all of the model dependencies through an XML serialization of the model (MoML).  The references to external model components are accomplished through the use of [[LSID]]s.
@


1.2
log
@
.
@
text
@d7 1
a7 1
The [[http://seek.ecoinformatics.org][SEEK project]] is working to build a distributed repository of executable modeling components using LSIDs to uniquely identify the components and store them on the EcoGrid.  Using this system, the same programmatic EcoGrid APIs that can be used to discover and access environmental data will be able to be used to reference models and statistical analyses that use those data.
@


1.1
log
@Initial revision
@
text
@d5 1
a5 1
Kepler uses LSID identifiers internally to track all o fthe analytical components that are associated with a given Kepler workflow.   Each analytical component has its own unique LSID, and workflows reference these LSIDs in the process of creating more complex hierarchical models.  The final analytical model that is created in Kepler can be archived in a special format that preserves all of the model dependencies through an XML serialization of the model (MoML).  The references to external model components are accomplished through the use of LSIDs.
@