[kepler-dev] seek/kepler conference call notes
bowers at sdsc.edu
Mon Aug 23 11:39:58 PDT 2004
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
>> than it is probably worth, and would be much less efficient generally
>> 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
> Basically, you can have:
> <property name="foo" class="ptolemy.kernel.util.ConfigurableAttribute">
> anything here, with the only constraint being that if
> "<configure>" appears, then there is a matching "</configure>".
> 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
> are given in a human-readable (vs. MoML) modeling language.
> Then, we could override "Look Inside" so that it reveals that
> specification in a context-sensitive text editor.
> Just some ideas...
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
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
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.
> 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