[kepler-dev] custom actor MOML question
Matt Jones
jones at nceas.ucsb.edu
Thu Mar 12 22:31:20 PDT 2009
Hi Paul,
OK, this is not an area I'm very familiar with, but I looked into it a
bit and here's my take on it. The extra information in our Moml files
is only used in our system for the actor library and kar file system
and searching. The ActorMetadata class is used to encapsulate this,
and when someone is manipulating the library and KAR files, the
changes occur in ActorMetadata and are stored in the objectmanager
cache. These systems are not used in Kepler for execution. Rather,
before an actor is put in a model that is passed to MoMLParser, they
are converted to a standard NamedObj, using code like this:
ActorCacheObject aco = (ActorCacheObject) cache.getObject(actorLSIDs[j]);
ActorMetadata am = aco.getMetadata();
NamedObj actorEntity = am.getActorAsNamedObj(null);
So... I'm not quite sure what you are trying to do, nor how to help.
If you open a standard moml document in kepler, it will execute both
in the gui and on the commandline. If you Import a KAR file into
Kepler that contains an actor with a kepler metadata document, the
objectmanager handles the conversion to a namedobj for you. There's
no way in the Kepler system to open a kar file and try to execute it
as if it were a moml model directly, which is what you are seeming to
try to do, I think. I would recommend that you use KAR files and
their associated moml only for the library packaging and searching,
and that you let kepler handle the conversions needed to do the
execution. If you startup execution via the kepler commandline, you
really should pass a stnadard moml as input, because as you point out
MoMLSimpleApplication will not be happy with our KAR files and
ActorMetadata format, as they are not part of ptolemy. Maybe we need
to expand the commandline utility to recognize a kar file and be able
to execute it as well, rather than just being able to import it. That
has its own set of issues, though.
I'm going to cc Shawn on this as he had a hand in creating this system
with Chad, and might be able to add some more insights while Chad is
away. Based on your experience with this, we probably need to
revisit how KAR files and moml files interact. Thanks for pointing out
the issues.
Hope this helps, even though I didn't provide a pat solution,
Matt
On Thu, Mar 12, 2009 at 8:05 AM, Paul Allen <pea1 at cornell.edu> wrote:
> Thanks Matt. I think I understand what you are saying as well as Edward's
> bigger picture thoughts.
>
> So could somebody show me the place in Kepler code that I could hook into to
> get functionality similar to ptolemy.moml.MOMLParser? I've tried to trace
> the Kepler startup code, but it's opaque to me. I especially don't
> understand how those special "kepler:" properties get stripped off when
> starting up org.kepler.loader.Kepler with the -nogui flag since it appears
> to directly call ptolemy.actor.gui.MoMLSimpleApplication which presumably
> doesn't do anything special with those "kepler:" properties (since it is
> pure ptolemy code).
>
> Thanks.
>
> Matt Jones wrote:
>
> Hi Paul,
>
> Kepler stores a variety of things in the MoML document that ptolemy
> does not, including documentation for entities and ports, semantic
> types for entities and ports, and other things. For a variety of
> reasons, which I could go into in more detail if I chat with Chad a
> bit, the MoML parser does not deal well with these uses, even though
> they are syntactically valid MoML. Turns out that the MoML parser has
> expectations that are not declared in the MoML DTD itself (such as
> that there can be no representation in MoML of a port defined in Java,
> else the MoML parser will not be happy). The bottom line is that
> Kepler stores an extended version of MoML, but strips out these
> extensions before passing the documents onto the ptolemy MoML parser
> (much of this is handled in the core module under
> objectmanager.ActorMetadata and the org.kepler.moml package). So if
> you are not using Kepler to do your parsing, you'll find that the
> ptolemy MoML parser chokes on Kepler's MoML (even though it is
> syntactically valid).
>
> I realize this is not an ideal solution for our extensions because it
> breaks compatibility with ptolemy. We've discussed various
> alternative approaches to representing the extensions we need -- such
> as MoML-based semantic types for all ports (whether defined in moml or
> in java). Is there a reason your tools can't use Kepler to do the
> parsing for now? Hope this helps,
>
> Matt
>
> On Wed, Mar 11, 2009 at 11:53 AM, Paul Allen <pea1 at cornell.edu> wrote:
>
>
> Could somebody explain why Kepler adds a "kepler:" prefix to the port names
> in my custom actors when I instantiate the actor by class name and then save
> the kar for that component via the Kepler GUI? That change is confusing some
> downstream tools I'm using mainly because the port names in the <link>
> section of the MOML don't use the "kepler:" prefix.
>
> Here's the MOML from the KAR for the actor.
>
> <?xml version="1.0"?>
> <entity name="GoogleBarChart" class="ptolemy.kernel.ComponentEntity">
> <property name="entityId" value="urn:lsid:sciencepipes.org:actor:1:1"
> class="org.kepler.moml.NamedObjId"/>
> <property name="class" value="edu.cornell.birds.is.bap.actor.GoogleBarChart"
> class="ptolemy.kernel.util.StringAttribute">
> <property name="id" value="null"
> class="ptolemy.kernel.util.StringAttribute"/>
> </property>
> <property name="kepler:url" class="org.kepler.moml.PortAttribute">
> <property name="direction" value="output"
> class="ptolemy.kernel.util.StringAttribute"/>
> <property name="dataType" value="string"
> class="ptolemy.kernel.util.StringAttribute"/>
> <property name="isMultiport" value="false"
> class="ptolemy.kernel.util.StringAttribute"/>
> </property>
> <property name="kepler:title" class="org.kepler.moml.PortAttribute">
> <property name="direction" value="input"
> class="ptolemy.kernel.util.StringAttribute"/>
> <property name="dataType" value="unknown"
> class="ptolemy.kernel.util.StringAttribute"/>
> <property name="isMultiport" value="false"
> class="ptolemy.kernel.util.StringAttribute"/>
> </property>
> <property name="kepler:secondary title"
> class="org.kepler.moml.PortAttribute">
> <property name="direction" value="input"
> class="ptolemy.kernel.util.StringAttribute"/>
> <property name="dataType" value="unknown"
> class="ptolemy.kernel.util.StringAttribute"/>
> <property name="isMultiport" value="false"
> class="ptolemy.kernel.util.StringAttribute"/>
> </property>
> <property name="kepler:values" class="org.kepler.moml.PortAttribute">
> <property name="direction" value="input"
> class="ptolemy.kernel.util.StringAttribute"/>
> <property name="dataType" value="unknown"
> class="ptolemy.kernel.util.StringAttribute"/>
> <property name="isMultiport" value="false"
> class="ptolemy.kernel.util.StringAttribute"/>
> </property>
> <property name="kepler:labels" class="org.kepler.moml.PortAttribute">
> <property name="direction" value="input"
> class="ptolemy.kernel.util.StringAttribute"/>
> <property name="dataType" value="unknown"
> class="ptolemy.kernel.util.StringAttribute"/>
> <property name="isMultiport" value="false"
> class="ptolemy.kernel.util.StringAttribute"/>
> </property>
>
> <property name="height" class="ptolemy.data.expr.Parameter" value="240">
> </property>
>
> <property name="width" class="ptolemy.data.expr.Parameter" value="240">
> </property>
>
> <property name="show zero" class="ptolemy.data.expr.Parameter" value="true">
> </property>
>
> <property name="orientation" class="ptolemy.data.expr.StringParameter"
> value="horizontal">
> </property>
>
> <property class="org.kepler.sms.SemanticType" name="semanticType00"
> value="urn:lsid:localhost:onto:1:1#ExternalGraphicalOutputActor"/>
> <property class="org.kepler.sms.SemanticType" name="semanticType11"
> value="urn:lsid:localhost:onto:2:1#TextualOutput"/>
>
>
> <property name="_location" class="ptolemy.kernel.util.Location"
> value="[260.0, 60.0]">
> </property>
>
>
> </entity>
>
> I've attached the MOML for the model in question.
>
>
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at kepler-project.org
> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
>
>
>
>
>
>
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at kepler-project.org
> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
>
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Matthew B. Jones
Director of Informatics Research and Development
National Center for Ecological Analysis and Synthesis (NCEAS)
UC Santa Barbara
jones at nceas.ucsb.edu Ph: 1-907-523-1960
http://www.nceas.ucsb.edu/ecoinfo
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
More information about the Kepler-dev
mailing list