[kepler-dev] seek/kepler conference call notes

Edward A Lee eal at eecs.berkeley.edu
Tue Aug 24 05:10:20 PDT 2004


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




More information about the Kepler-dev mailing list