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

[Shawn Bowers]

Edward A Lee wrote:

> At 09:53 AM 8/21/2004 -0700, Shawn Bowers wrote:
> 
>> - I would change the bullet from "semantic registration of MoML" to
>> "semantic registration of Actors and Workflows".  I think we need unique
>> id's for actors/workflows for sem. reg. as well (just like for saving
>> products to EcoGrid), to do this. Annotating MoML directly is more 
>> trouble
>> than it is probably worth, and would be much less efficient generally 
>> than
>> storing an external annotation.
> 
> 
> I like Bertram's ideas of a more human readable modeling language...
> XML is horrible in this regard... Nonetheless, although I'm not sure 
> what the
> requirements are, some of what has been mentioned is easily done in MoML...
> 
> E.g., versioning:
> The class ptolemy.kernel.attributes.VersionAttribute is used to represent
> in a model the version of Ptolemy II that was used to create the model.
> Its subclass, ptolemy.kernel.attributes.RequireVersion, when present in
> a model, is an assertion that a certain version (or later) of Ptolemy II
> is required to run a model.
> 
> We could create similar attributes for individual actors, and easily
> tie their values to the CVS version numbers, and build in the semantics
> of CVS branches, etc.  If we worked out hot swapping of classes (which
> in theory is possible), we could, in these attributes, provide URLs that
> would result in automatic updates of the class files when a model is run
> that requires a newer version of an actor.
> 
> In another dimenstion, MoML has an extension mechanism via 
> ConfigurableAttributes.
> Basically, you can have:
> 
>   <property name="foo" class="ptolemy.kernel.util.ConfigurableAttribute">
>      <configure>
>         anything here, with the only constraint being that if
>         "<configure>" appears, then there is a matching "</configure>".
>      </configure>
>   </property>
> 
> This is used to embed foreign languages (other XML schemas or entirely
> different languages, like Python, MATLAB, etc.).
> 
> Conceivably, we could create a subclass of CompositeActor that contains
> a subclass of ConfigurableAttribute where the contents of the 
> CompositeActor
> are given in a human-readable (vs. MoML) modeling language.
> Then, we could override "Look Inside" so that it reveals that 
> human-readable
> specification in a context-sensitive text editor.
> 
> Just some ideas...
> 
> Edward

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

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.

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.

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.

shawn

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