Bug #1546
closeddynamic data and actor views using ontologies
0%
Description
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
|__ IndividualBasedModelwith 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.
Files