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

[Shawn Bowers]

My general opinion about efficiency in this regard is don't fix it until 
it is broken.  So, I generally agree with you.  There are also other 
options for integration that can be explored, including existing Java 
and C interfaces to Prolog, or as in BIRN, rewriting the prolog to Java 
(of course, Java in and of itself has its own efficiency problems).




shawn


Matt Jones wrote:

> 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
>>>
>>>
>>>
>>>
>