[seek-dev] Re: [kepler-dev] seek/kepler conference call notes
Matt Jones
jones at nceas.ucsb.edu
Wed Aug 25 12:17:17 PDT 2004
Hi Ferdinando,
That's how it works now (for EML/WSDL). The abstract EMLDataSource
actor is instantiated by reading an EML doc and the instance has the
signature found in the EML document. Ditto for WSDL. The R case is
planned but not implemented yet (except using the Commandline actor,
which bypasses all of our typing mechanisms for data flow).
My point for thinking about semantic descriptions, and whether they
should go in MoML's 'configure' section, is that these dynamically
created actors instances need to be accomodated *before* they are
instantiated in Kepler -- ie, the semantic description of ports, etc,
needs to be attached to the EML and WSDL to accomodate the semantic
discovery phase (ie, prior to building a model in Kepler). In my mind,
this argues for a semantic annotation capability that is maintained
outside of MoML, EML, WSDL, R, etc.
Matt
Ferdinando Villa wrote:
> 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
--
-------------------------------------------------------------------
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
-------------------------------------------------------------------
More information about the Seek-dev
mailing list