[kepler-dev] seek/kepler conference call notes

Edward A Lee eal at eecs.berkeley.edu
Mon Aug 23 12:42:28 PDT 2004

At 11:39 AM 8/23/2004 -0700, Shawn Bowers wrote:
>I guess my biggest thing when it comes to semantically annotating MoML 
>directly is the following.
>There are two main uses that have been proposed in SEEK for semantic 
>annotations on actors/workflows: (1) to search for and discover actors via 
>their semantic markup and (2) to use the semantic markup to help compose 
>heterogeneous actors (i.e., actors that don't have compatible input/output 
>For (1), if we were to store the annotations directly in MoML, then 
>searching based on semantic types would require obtaining, loading, and 
>parsing *every* MoML file that describes/represents an actor/workflow. 
>(Note also that the majority of time parsing MoML in this case would be 
>spent on non-semantic markup.) We could alternatively create some form of 
>semantic-annotation "index." But then it seems the index would end up just 
>being the proposed external semantic annotation.

Hmm... First, It seems that if you keep the annotations together with the
actor/workflows, then _any_ scheme requires some level of parsing
the file, regardless of what the format is.

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.

Third (much more interestingly), if you use a custom class (subclass
of Attribute) to specify semantic markup, then you could have actors
that transparently (in the background) update a dynamically maintained
peer-to-peer index of actors/workflows ... a Napster of actors.
Yang Zhao has, in fact, prototyped a mechanism like this...  This
index could be updated whenever an instance of this custom attribute
is instantiated, for example.

I think that if you have a separate file that is the semantic markup,
separately maintained from the actor/workflow source, then keeping
the two consistent will be very challenging...

>A smaller issue is that we would need to change/extend the existing parser 
>for MoML. Whereas using external semantic annotations, we could build our 
>own, and possibly keep this parser at the location of the semantic 
>annotations (e.g., on the "EcoGrid").  It also seems that building our own 
>parser for this is probably just quicker and easier to get going.

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

>Perhaps there are other ways around these issues for MoML that I am 
>unaware of. But generally speaking, it seems like it is reasonable to 
>store "extra" information in MoML so long as it isn't used as the 
>mechanism to query and search for actors.

I'm thinking that the information should be in MoML, but that your
annotation classes could generate rapidly searchable indexes.  This way,
the "source" is all together, but the search is quick...


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