[kepler-dev] MoML authoring use cases

Paul Allen pea1 at cornell.edu
Fri Mar 13 09:41:53 PDT 2009


Yes, I now understand they do not have the same meaning. I think that 
this highlights my original conundrum about what actor specifications a 
workflow authoring tool should use as actor prototypes.

For non-Kepler workflows, the MoML files defining actors (gotten from 
exportMoML()) contain the entirety of the information an authoring tool 
needs to allow a user to manipulate and plumb together actors. For 
Kepler workflows, one would need both the MoML specifications of the 
actors plus the actor metadata in XML from the actor KAR files (assuming 
that the authoring environment wasn't Java-based and couldn't 
instantiate the Java class for the actor). For example, without access 
to Java, an authoring tool couldn't tell the difference between a Port 
and a PortParameter if it had just the KAR file.

Is there some way that the MoML for a class and the XML specification 
from the KAR could be combined into a single, non-redundant 
specification that non-Java authoring tools could use?

Shawn Bowers wrote:
> These aren't the same.
>
> The metadata does not "live" with the actor's Java code. So, in the
> case of KAR, you have the metadata of the actor, and in the second you
> created a moml version of the "naked" actor -- without the various
> metadata elements. This is somewhat similar to having a mechanism to
> generate a "bare bones" eml file from any csv data set (in this case,
> the export moml command on the actor class instance). And then taking
> this generated eml file and adding the other eml metadata attributes
> to it (like author, geographic coverage, units, etc.). And then
> regenerating the original eml from the dataset -- in which case you
> lose all the added eml elements.
>
> You can get a moml file also from the KAR file, which will contain the
> metadata, as Matt described in his email.
>
> Shawn
>
> On Fri, Mar 13, 2009 at 7:59 AM, Paul Allen <pea1 at cornell.edu> wrote:
>   
>> Yes, those are from the same actor. The KAR actor description is exactly
>> from the unzipped KAR file for CreateDate (a standard Kepler actor). The
>> MoML was generated with the following Java code:
>>
>>         MoMLParser parser = new MoMLParser();
>>         String stringURL = "http://sciencepipes.org/misc/pipes/empty.xml";
>>         URL url = new URL(stringURL);
>>         TypedCompositeActor toplevel = (TypedCompositeActor)
>> parser.parse(null, url);
>>         CreateDate actor2= new CreateDate(toplevel, "CreateDate");
>>         System.out.println(actor2.exportMoML());
>>
>> Shawn Bowers wrote:
>>
>> Hi Paul,
>>
>> Out of curiosity, are you saying that the moml generated below is for
>> the *same* actor? I think in Kepler that many of the same properties
>> also show up in the output moml, e.g., semantic types (which are just
>> regular old ptolemy properties), actor ids (again, just regular old
>> ptolemy properties), documentation, etc.
>>
>> We had some issue w.r.t. searching actors within external repositories
>> using the moml representation produced by moml export, which is one
>> reason we wanted to have a similar, but that contains a bit more
>> information.  Of course, some of this was done quite a while ago, and
>> the moml support in ptolemy may have changed a bit -- It isn't clear
>> to me if this is the case, so I'm not really sure whether the issues
>> were addressed.
>>
>> Shawn
>>
>> On Fri, Mar 13, 2009 at 7:19 AM, Paul Allen <pea1 at cornell.edu> wrote:
>>
>>
>> Recent discussions on this mailing list have helped clarify my thinking
>> about workflow (MoML) authoring tools. (See
>> http://mercury.nceas.ucsb.edu/kepler/pipermail/kepler-dev/2009-March/013865.html
>> http://mercury.nceas.ucsb.edu/kepler/pipermail/kepler-dev/2009-March/013903.html)
>>
>> Abstractly, the issue I'm trying to tackle is how to implement a MoML
>> authoring tool that isn't Java-based and thus doesn't have access to the
>> actor implementations themselves. See the attached PDF diagram. I've been
>> working with Christopher Tuot's KFlex package which uses the actor XML
>> specifications from KAR files to understand how to visually represent actors
>> and the semantics of their ports, links, and relations. I misunderstood the
>> actor XML representations from KAR files and now understand that they are
>> quite different from the MoML you get when you run Ptolemy's exportMoML()
>> for an actor (see below).
>>
>> I'd be happy to other people's thoughts about whether a non-Java MoML
>> authoring tool should be trying to deal with KAR actor descriptions or the
>> actor MoML directly.
>>
>> --------------------------------------------------------------------------------------------------------
>> KAR actor description:
>> --------------------------------------------------------------------------------------------------------
>> <?xml version="1.0"?>
>> <entity name="CreateDate" class="ptolemy.kernel.ComponentEntity">
>> <property name="entityId"  value="urn:lsid:kepler-project.org:actor:541:1"
>> class="org.kepler.moml.NamedObjId"/>
>> <property name="class" value="org.kepler.date.CreateDate"
>> class="ptolemy.kernel.util.StringAttribute">
>>  <property name="id" value="urn:lsid:kepler-project.org:class:541:1"
>> class="ptolemy.kernel.util.StringAttribute"/>
>> </property>
>> <property name="kepler:output" class="org.kepler.moml.PortAttribute">
>>  <property name="direction" value="output"
>> class="ptolemy.kernel.util.StringAttribute"/>
>>  <property name="dataType" value="date"
>> class="ptolemy.kernel.util.StringAttribute"/>
>>  <property name="isMultiport" value="true"
>> class="ptolemy.kernel.util.StringAttribute"/>
>> </property>
>> <property name="kepler:trigger" 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="true"
>> class="ptolemy.kernel.util.StringAttribute"/>
>> </property>
>> <property name="kepler:format" class="org.kepler.moml.PortAttribute">
>>  <property name="direction" value="input"
>> 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 name="_showName" class="ptolemy.kernel.util.Attribute">
>> </property>
>> </property>
>> <property name="kepler:input" class="org.kepler.moml.PortAttribute">
>>  <property name="direction" value="input"
>> 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 name="_showName" class="ptolemy.kernel.util.Attribute">
>> </property>
>> </property>
>> <property name="firingCountLimit" class="ptolemy.data.expr.Parameter"
>> value="NONE">
>> </property>
>>
>> <property name="NONE" class="ptolemy.data.expr.Parameter" value="0">
>> </property>
>>
>>
>> <property name="semanticType00" class="org.kepler.sms.SemanticType"
>> value="urn:lsid:localhost:onto:2:1#Time">
>> </property>
>>
>> <property name="KeplerDocumentation"
>> class="ptolemy.vergil.basic.KeplerDocumentationAttribute">
>> <property name="description"
>> class="ptolemy.kernel.util.ConfigurableAttribute"><configure>null</configure></property>
>> <property name="author"
>> class="ptolemy.kernel.util.ConfigurableAttribute"><configure>Daniel
>> Crawl</configure></property>
>> <property name="version"
>> class="ptolemy.kernel.util.ConfigurableAttribute"><configure>null</configure></property>
>> <property name="userLevelDocumentation"
>> class="ptolemy.kernel.util.ConfigurableAttribute"><configure>&#10;Create a
>> date token. If a date string is not given on &lt;i&gt;input&lt;/i&gt;, &#10;
>>   the current date and time is used.</configure></property>
>> <property name="port:output"
>> class="ptolemy.kernel.util.ConfigurableAttribute"><configure>The date and
>> time token.</configure></property>
>> <property name="port:trigger"
>> class="ptolemy.kernel.util.ConfigurableAttribute"><configure>If connected,
>> the actor will not run until a token is available.</configure></property>
>> <property name="prop:input"
>> class="ptolemy.kernel.util.ConfigurableAttribute"><configure>A string date
>> and time. If not used, the current date and time  is
>> used.</configure></property>
>> <property name="prop:format"
>> class="ptolemy.kernel.util.ConfigurableAttribute"><configure>The format of
>> the input date and time. See   java.text.SimpleDateFormat for the
>> syntax.</configure></property>
>> <property name="prop:firingCountLimit"
>> class="ptolemy.kernel.util.ConfigurableAttribute"><configure>If a positive
>> integer, then the number of iterations before the  actor indicates to the
>> scheduler that it is finished by returning  false in its postfire()
>> method.</configure></property>
>> </property></entity>
>>
>>
>> --------------------------------------------------------------------------------------------------------
>> Output from exportMoML:
>> --------------------------------------------------------------------------------------------------------
>> <entity name="CreateDate" class="org.kepler.date.CreateDate">
>>   <property name="firingCountLimit" class="ptolemy.data.expr.Parameter"
>> value="NONE">
>>   </property>
>>   <property name="NONE" class="ptolemy.data.expr.Parameter" value="0">
>>   </property>
>>   <property name="format" class="ptolemy.actor.parameters.PortParameter"
>> value="">
>>   </property>
>>   <property name="input" class="ptolemy.actor.parameters.PortParameter"
>> value="">
>>   </property>
>>   <port name="output" class="ptolemy.actor.TypedIOPort">
>>       <property name="output"/>
>>       <property name="multiport"/>
>>   </port>
>>   <port name="trigger" class="ptolemy.actor.TypedIOPort">
>>       <property name="input"/>
>>       <property name="multiport"/>
>>   </port>
>>   <port name="format" class="ptolemy.actor.parameters.ParameterPort">
>>       <property name="input"/>
>>       <property name="_showName" class="ptolemy.kernel.util.Attribute">
>>       </property>
>>   </port>
>>   <port name="input" class="ptolemy.actor.parameters.ParameterPort">
>>       <property name="input"/>
>>       <property name="_showName" class="ptolemy.kernel.util.Attribute">
>>       </property>
>>   </port>
>> </entity>
>>
>>
>>
>> _______________________________________________
>> 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
>>
>>
>>     
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mercury.nceas.ucsb.edu/kepler/pipermail/kepler-dev/attachments/20090313/4b14ecfa/attachment-0001.html>


More information about the Kepler-dev mailing list