[kepler-dev] [Bug 1546] New: - dynamic data and actor views using ontologies
Matt Jones
jones at nceas.ucsb.edu
Fri Apr 30 12:21:01 PDT 2004
Hi Shawn,
Wrapping the command-line tools is a good short-term hack to try things
out, but a poor long-term solution. In general, executing a command
line tool spawns a new process on most OS's, and it is both time and
resource intensive. Web server implementors learned this early because
of the design of the CGI specification. If used frequently, this type
of design slows applications to a halt. It would be much better to
create a java class that represents the prolog processor and can stay
resident in memory with access to the prolog libraries through JNI or
something similar. Then, any requests for prolog processing can be made
to the prolog processing library directly instead of through the slow
command line.
I've been delving into the Ptolemy tree viewer and MoML Configuration a
lot over the last week while trying to create the data set viewer. Its
quite complicated, but it'll work out fine I think. I think we should
put this on the agenda for Scotland -- to try to work out a design that
we can implement and expect to work from both of our systems perspectives.
Thanks,
Matt
Shawn Bowers wrote:
>
> Good question.
>
> Our "vision" is that sparrow-tk is a set of command line tools, which
> becomes the mechanism for integration of Kepler with sparrow-tk. (These
> command line tools would work equally well under linux and windows --
> since prolog is a cross platform application.)
>
> For example, one simple way to do the integration is to wrap all the
> command line tools into Java classes, that could then be directly used
> within Kepler.
>
> Yes -- the "trivial" part I mention is the underlying reasoning, data
> access, etc., and not the actual Kepler UI stuff. But, I think you
> could just use the existing tree-viewer in Kepler. So, the command-line
> tool would generate the information needed to populate the tree-view. I
> remember vaguely helping Ilkay fight with this in Ptolemy, because the
> tree-view component reads in the MoML stuff, etc., to populate nodes.
> So, there is probably some design and implementation work to get any
> type of population mechanism to work for tree-view in Kepler, but once
> that is figured out, it should be very straightforward.
>
> What do you think?
>
> shawn
>
> Matt Jones wrote:
>
>> 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
-------------------------------------------------------------------
More information about the Kepler-dev
mailing list