[kepler-dev] seek/kepler conference call notes

Bertram Ludaescher ludaesch at sdsc.edu
Sat Aug 21 10:13:22 PDT 2004


>>>>> "SB" == Shawn Bowers <bowers at sdsc.edu> writes:
SB> 
SB> Just a couple of quick comments:
SB> 
SB> - For ontology based browsing of actors, I think we also need at least
SB> some test ontologies/actors.  I think the biodiversity domain would be
SB> good to use as a first case. But, there wasn't a bullet there that
SB> mentions actual ontologies for testing/using the proposal.
SB> 
SB> - I would change the bullet from "semantic registration of MoML" to
SB> "semantic registration of Actors and Workflows".  I think we need unique
SB> id's for actors/workflows for sem. reg. as well (just like for saving
SB> products to EcoGrid), to do this. Annotating MoML directly is more trouble
SB> than it is probably worth, and would be much less efficient generally than
SB> storing an external annotation.

I'm not worried about efficiency here, but agree that a separate
language will be better (at least initially) for many reasons: for
one, MOML is very good at what it is (a "internal" language for
capturing Ptolemy models/Kepler workflows). While we experiment with
extensions we should not spoil or clutter MOML with our transient
features. Let's go our MoL (Model Language) or WofL (Workflow
Language) going first, demonstrate the utility and when it's mature
think whether languages can be merged. 

I've already started (as part of a recent meeting) a very rough first
(and still buggy) attempt at MoL/WofL in Sparrow syntax =B-)

Actually, a small correction: It's not MoL/WofL but rather the version 
for Q-PN/Q-SDF (a query version of PN/SDF, I'm working on with
Liying).

Here is a snippet (details of this language will change!!)

% two databases and their schemas
db d1 :: [r1(x,y)].
db d2 :: [r2(y,z)].

% some channels (actually, better name: ports) with the signatures
channel i1.
channel o1(x,y).
channel i2(x,y).
channel o2(x,z).

% some queries
query q1(x,y) <- r1(x,y).
query q2(x,z) <- i2(x,y), r2(y,z). 

% some actors and their signatures
actor a1 :: [i1]/d1/q1(x,y) -> [o1(x,y)].
actor a2 :: [i2(x,y)]/d2/q2(x,z) -> [o2(x,z)].

% the network topology 
link o1(x,y) - i2(x,y).

Note that this language (or improvements thereof) are BOTH human and
machine readable.

The "grammar" for the above is very simple given any Prolog parser:

:- op(1150, fx, actor).
:- op(1150, fx, db).
:- op(1150, fx, channel).
:- op(1150, fx, link).
:- op(1150, fx, query).
:- op(1100, xfx, ::).
:- op(1050, xfx, <-).

that's all that is needed to parse the above (operator precendence syntax)

SB> - I think Ikay's idea of a blue box recorder is already implemented by our
SB> MyGrid colleagues -- so perhaps we can borrow what they have done?

If they have sth, we could try to use it. the upcoming link-up meeting 
might be a good opportunity to take a closer look..

Bertram

SB> 
SB> shawn
SB> 
SB> 
SB> On Thu, 19 Aug 2004, Matt Jones wrote:
SB> 
>> Hi,
>> 
>> Thanks for the productive conference call.  We made some decisions about
>> our target October 15 release date for a beta version of Kepler.  My
>> notes from the meeting are on the SEEK wiki here:
>> 
>> http://seek.ecoinformatics.org/Wiki.jsp?page=KeplerConferenceCallNotes19Aug2004
>> 
>> Cheers,
>> Matt
>> 
SB> 
SB> _______________________________________________
SB> kepler-dev mailing list
SB> kepler-dev at ecoinformatics.org
SB> http://www.ecoinformatics.org/mailman/listinfo/kepler-dev



More information about the Kepler-dev mailing list