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

Fri Apr 30 14:26:16 PDT 2004

Matt:

I agree that the command line solution is not the optimal interface in 
terms of performance. But it is close to optimal in terms of
convenience and rapid prototypying.

And the overhead (a la CGI or command line) is not necessarily the
bottleneck either.

But certainly for those situations where we have lots of actor-like
tools say in Prolog (or Perl, or Python, or awk, or ... ) we certainly 
should think of "native generic actor"...

Bertram

>>>>> "MJ" == Matt Jones <jones at nceas.ucsb.edu> writes:
MJ> 
MJ> Hi Shawn,
MJ> Wrapping the command-line tools is a good short-term hack to try things 
MJ> out, but a poor long-term solution.  In general, executing a command 
MJ> line tool spawns a new process on most OS's, and it is both time and 
MJ> resource intensive.   Web server implementors learned this early because 
MJ> of the design of the CGI specification.  If used frequently, this type 
MJ> of design slows applications to a halt.  It would be much better to 
MJ> create a java class that represents the prolog processor and can stay 
MJ> resident in memory with access to the prolog libraries through JNI or 
MJ> something similar. Then, any requests for prolog processing can be made 
MJ> to the prolog processing library directly instead of through the slow 
MJ> command line.
MJ> 
MJ> I've been delving into the Ptolemy tree viewer and MoML Configuration a 
MJ> lot over the last week while trying to create the data set viewer.  Its 
MJ> quite complicated, but it'll work out fine I think.  I think we should 
MJ> put this on the agenda for Scotland -- to try to work out a design that 
MJ> we can implement and expect to work from both of our systems perspectives.
MJ> 
MJ> Thanks,
MJ> Matt
MJ> 
MJ> 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
>>> 
>>> 
>>> 
MJ> 
MJ> -- 
MJ> -------------------------------------------------------------------
MJ> Matt Jones                                     jones at nceas.ucsb.edu
MJ> http://www.nceas.ucsb.edu/    Fax: 425-920-2439    Ph: 907-789-0496
MJ> National Center for Ecological Analysis and Synthesis (NCEAS)
MJ> University of California Santa Barbara
MJ> Interested in ecological informatics? http://www.ecoinformatics.org
MJ> -------------------------------------------------------------------