[kepler-dev] seek/kepler conference call notes

[Matt Jones]

Well, two more issues I can see cropping up.

1) We need to make semantic annotations for individual actors, as well 
as models.  As far as I know there is not a MoML provided for individual 
actors independently of a model?  How do we annotate, for example, the 
GarpAlgorithm actor outside of a MoML model so that we can use these 
annotations in the discovery service?  Should we be providing a 
standalone MoML for every actor that contains only the actor and its 
port descriptions, and then attach the 'configure' annotations to that?

2) Some of our actors have a set of ports that are defined and loaded at 
design time rather than compile time, and are determined by an external 
source.  For example, the EMLDataSource actor gets its port definitions 
by reading the metadata about a data source, and the WebService actor 
gets its port definitions by reading the WSDL document for the service. 
I had thought that having external annotations would be good because 
they could be associated with the WSDL or EML rather than the actor 
itself.  We'll need a way to annotate these dynamically created ports as 
well as those that are statically defined within an actor.  I envision 
this to be common.  Another example is instantiating a hypothetical R 
actor with the ports needed for data flow into and out of a specific R 
script, rather than using the CommandLine as we currently do (which 
bypasses all of our typing mechanisms).

Matt

Shawn Bowers wrote:
> 
> Edward,
> 
> This is great, Thanks!
> 
> Basically, the configure() is a hook that we can use to, like you say, 
> do indexing, notify EcoGrid, update a P2P catalog, etc.
> 
> 
> Thanks,
> Shawn
> 
> 
> Edward A Lee wrote:
> 
>>
>> Shawn:
>>
>> Thanks for your reply... I think I'm getting a clearer understanding of
>> the issues, so I can be more concrete in my ideas. Following the
>> thread:
>>
>> At 03:29 PM 8/23/2004 -0700, Shawn Bowers wrote:
>>
>>> ...
>>>
>>>> Second, the parsing could be greatly speeded up if, for example,
>>>> you first searched the MoML file for a full class name that matched
>>>> the class used to specify the semantic markup.
>>>
>>>
>>>
>>> In general, a semantic annotation isn't a class name, and could be as 
>>> complex as a query.
>>
>>
>>
>> Yes, I realize this, but in Ptolemy II, the semantic annotation
>> could be stored with the model as an attribute.  I.e., you include
>> in the library a kepler.misc.SemanticAnnotation attribute, which a
>> user drags into a model and double clicks to add the annotation.
>> A custom editor comes up to create the annotation.  When you save
>> to MoML, you get:
>>
>>    <entity name="myModel" class="...">
>>      <property name="semanticAnnotation"
>>                class="kepler.misc.SemanticAnnotation">
>>        <configure>
>>           ... semantic annotation in any (textual) language ...
>>        </configure>
>>      </property>
>>    </entity>
>>
>> Now a (fast) browser would search MoML files for the string
>> "kepler.misc.SemanticAnnotation" and then extract only the
>> pertinent parts of the XML to parse.
>>
>> But more interestingly would be to include in the configure()
>> method for the SemanticAnnotation class networking P2P code
>> that updates an index with the semantic annotation.
>>
>>
>>> ...
>>>
>>>>
>>>> I don't see why you would need to extend the parser for MoML (?).
>>>> Can you give me an example of what it might look like?  I'll show
>>>> then how it can be done in MoML with no changes to the parser 
>>>> (hopefully)...
>>>
>>>
>>>
>>> I guess I was thinking that you would have to at least extend the 
>>> parser to extract the semantic annotation part and forward it to some 
>>> other service to start up annotation-handler code.
>>>
>>> There are two types of annotations for an actor. The simplest form is 
>>> to just say that an actor represents some instance of a particular 
>>> ontology class (e.g., EcoNicheModel). This type of annotation could 
>>> also be made more specific, e.g., by giving more details on how it 
>>> instantiates a class (which by the way, essentially creates a new 
>>> class "on-the-fly"). For example, we might say it is an instance of 
>>> an EcoNicheModel that uses a specific type of 
>>> LogisticRegressionModel, etc.  An actor might also be an instance of 
>>> multiple ontological concepts (its an instance of an EcoNicheModel 
>>> and something else ... which doesn't really fit this example, but 
>>> anyway).
>>>
>>> For input/output types, semantic annotations are similar to the unit 
>>> stuff, but generally resemble views (queries). Mainly because we need 
>>> finer levels of detail. For example, an actor might take as input a 
>>> list of records:
>>>
>>> [{lt1=double, lt2=double, ln1=double, ln2=double, s=int, n=int}]
>>>
>>> and the input annotation might be (where here record attributes 
>>> denote values from the same tuple in the list):
>>>
>>> Community(C), LatLonPt(NW), lat(NW, lt1), lon(NW, ln1), LatLonPt(SE), 
>>> lat(SE, lt2), lon(SE, ln2), BBox(B), nwCorner(B, NW), seCorner(B, 
>>> SE), communityLocation(C, B), communitySpeciesCount(C, s), 
>>> communityPopulation(C, n)
>>
>>
>>
>> So, for example, you might have:
>>
>>    <entity name="myActor" class="...">
>>      <port name="input" class="...">
>>        <property name="semanticAnnotation"
>>                  class="kepler.misc.SemanticAnnotation">
>>          <configure>
>> Community(C), LatLonPt(NW), lat(NW, lt1), lon(NW, ln1), LatLonPt(SE), 
>> lat(SE, lt2), lon(SE, ln2), BBox(B), nwCorner(B, NW), seCorner(B, SE), 
>> communityLocation(C, B), communitySpeciesCount(C, s), 
>> communityPopulation(C, n)
>>        </property>
>>       </port>
>>    </entity>
>>
>> In this case, the parser for the semantic annotation would
>> be part of the SemanticAnnotation class... No extension to the
>> MoMLParser is needed.
>>
>> Edward
>>
>>
>> ------------
>> Edward A. Lee, Professor
>> 518 Cory Hall, UC Berkeley, Berkeley, CA 94720
>> phone: 510-642-0455, fax: 510-642-2739
>> eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal

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