[kepler-dev] [Bug 1546] New: - dynamic data and actor views using ontologies

bugzilla-daemon@ecoinformatics.org bugzilla-daemon at ecoinformatics.org
Fri Apr 30 11:06:15 PDT 2004


http://bugzilla.ecoinformatics.org/show_bug.cgi?id=1546

           Summary: dynamic data and actor views using ontologies
           Product: Kepler
           Version: 0.0
          Platform: Other
        OS/Version: other
            Status: NEW
          Severity: enhancement
          Priority: P1
         Component: interface
        AssignedTo: tao at nceas.ucsb.edu
        ReportedBy: jones at nceas.ucsb.edu
         QAContact: kepler-dev at ecoinformatics.org


Current lists of actors (and planned data sets) are static in that the tree is
statically written into a MoML model and displayed.  This severely limits the
user's ability to find appropriate actors (and data sets) as the number of
actors grows.  The current tree is a combination of functional and project
oriented folders, with no consistent classification.

This proposal is to generate dynamic views of the actors and data sets by
organizing the actors into trees using simple ontologies and controlled
vocabularies.  Each actor (in its MoML code) and each data set (in its metadata
description) would contain term references that are drawn from one or more
ontologies.  For example, an actor might be classified as belonging to the Class
"SimulationModel" while another actor might belong to the Class
"AnalyticalModel".  If both AnalyticalModel and SimulationModel are subclasses
of "Model", then we could display a dynamically generated tree like this:

  Model
   |__ SimulationModel
   |__ AnalyticalModel
   |__ NumericalModel
   |__ IndividualBasedModel

with each of the Actors displayed at the appropriate node in the tree.  Of
course, if SimulationModel has subclasses itself, those could either be
collapsed to show all models under SimulationModel, or additional levels of the
tree can be added.

The same scenario applies to data sets, allowing people to browse data according
to a particular classification ontology.  For example, data could be classified
as applying to certain types of measurements:
  PhysicalMeasurement
  ChemicalMeasurement
  BiologicalMeasurement
    |__ MolecularMeasurement
    |__ CellularMeasurement
    |__ TissueMeasurement
    |__ OrganismMeasurement
    |__ PopulationMeasurement
    |__ CommunityMeasurement
    |__ EcosystemMeasurement

Although this example is somewhat contrived, it illustrates the type of ontology
one might use.  Need to talk to some domain scientists to determine an
appropriate set of classifications for data.

Switching classification schemes would be done dynamically, on-the-fly.  The set
of ontologies that are available for display would need to somehow be limited to
a meaningful set (all of the classes in even a small, simple ontology would
overwhelm the user).  This could probably be set through a configuration.  In
addition, the ontologies would need to be stored in a Kepler-accessible
location, possibly included with the release.



More information about the Kepler-dev mailing list