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

[Matt Jones]

Cool, I hoped you might say something like that :)

When you say trivial, are you including as "trivial" the integration of 
prolog code into the Java code base in Kepler, and working with the 
complex drag and drop mechanism that is implicit in Ptolemy?  Or do you 
mean, trivial in that we can generate an ASCII-art view of the tree in 
prolog?  I can see the latter being trivial if sparrow-tk already 
handles the use case, but not the former based on my knowledge of 
Kepler.  What are your the specific plans for how the sparrow-tk prolog 
code base will be called and integrated with our various Java-based 
projects?

Matt

Shawn Bowers wrote:
> 
> I don't know if you saw this, but I have a use case for exactly what you 
> describe below in that earlier design doc I sent aroud. And if there 
> were ontologies and registrations to services and datasets, the 
> implementation is trivial using sparrow-tk (our generic sms toolkit 
> under development)
> 
> shawn
> 
> 
> bugzilla-daemon at ecoinformatics.org wrote:
> 
>> 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.
>> _______________________________________________
>> kepler-dev mailing list
>> kepler-dev at ecoinformatics.org
>> http://www.ecoinformatics.org/mailman/listinfo/kepler-dev

-- 
-------------------------------------------------------------------
Matt Jones                                     jones at nceas.ucsb.edu
http://www.nceas.ucsb.edu/    Fax: 425-920-2439    Ph: 907-789-0496
National Center for Ecological Analysis and Synthesis (NCEAS)
University of California Santa Barbara
Interested in ecological informatics? http://www.ecoinformatics.org
-------------------------------------------------------------------