[kepler-dev] seek/kepler conference call notes

[Shawn Bowers]

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