[seek-dev] Re: [kepler-dev] seek/kepler conference call notes

Wed Aug 25 11:57:40 PDT 2004

Matt,

I'm not sure I'm not reinventing something that's obvious to the
Keplerites, but shouldn't WSDL, EML and R be seen as actor definition
languages (as opposed to  configuration) in kepler? Is a mechanism where
a user query for data or the loading of a script creates an actor
definition (instance of an abstract EML/WDSL/R actor that provides the
generalized methods for it to do its work) conceivable in the current
implementation? That would clean the design up quite a bit.

ferdinando

On Wed, 2004-08-25 at 14:31, Matt Jones wrote:
> 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
-- 
Ferdinando Villa, Ph.D., Associate Research Professor, Ecoinformatics
Gund Institute for Ecological Economics and Dept of Botany, Univ. of Vermont
http://ecoinformatics.uvm.edu