[kepler-dev] Schema matching tool for interface alignment

[Joseph Goguen]

Dear Shawn,

>Date: Mon, 18 Oct 2004 09:41:27 -0700
>From: Shawn Bowers <bowers at sdsc.edu>
>User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
>X-Accept-Language: en-us, en
>CC: ludaesch at sdsc.edu, bzhu at sdsc.edu, tao at nceas.ucsb.edu, rods at ku.edu,
>        seek-dev at ecoinformatics.org, kepler-dev at ecoinformatics.org
>X-Spam-Flag: Spam NO
>X-Scanned-By: milter-spamc/0.15.245 (fast.ucsd.edu [132.239.15.4]); pass=YES; Mon, 18 Oct 2004 09:41:40 -0700
>X-Scanned-By: milter-spamc/0.15.245 (gradlab.ucsd.edu [132.239.55.107]); pass=YES; Mon, 18 Oct 2004 09:41:39 -0700
>X-Spam-Status: NO, hits=-4.90 required=5.00
>X-Spam-Level: Level 
>
>Joseph Goguen wrote:
>
>>Our schema matching tool, SCIA, is getting close to ready for beta release.
>>We have succesfully wrapped an older version as a stand-alone Kepler actor,
>>so it should be feasible to include it in Kepler as a transformation tool to
>>translate data between actors in a pipeline having different input/output
>>requirements.  Issues that remain include: 1) obtaining Kepler support for
>>actor input/output interface description in DTD/XML Schema, which seems also
>>needed for work of Bertram and Shawn on semantic annotation for actors (this
>>relates to the type system of Ptolemy); 
>
>Just a note that XML Schema and/or DTD support isn't really part of what 
>we've been focussing on. In particular, annotation for actors and data 
>isn't based on XML schema or DTD.  An earlier paper we wrote considered 
>XML, but since we've adopted Ptolemy's native type system + relational.

We would have to write another parser to make this work, but that is probably
not too big of a deal.

>It doesn't seem like this would be a limiting factor in SCIA either ... 
>although there is probably slightly less to automatically match on since 
>there are fewer "tags."

The less to match, the easier the parser will be!

>>(4) decide whether SCIA should be a hidden actor that is launched 
>when needed, or be
>>explicitly added to a pipeline by a user pulling it from the actor library;
>>and 
>
>I think at some point, it would be nice to (possibly in Kansas), sit 
>down and discuss the best interface approach for helping scientists 
>connect actors in kepler ... For now, I would think that it would best 
>to add it as a part of the Kepler UI, e.g., through a menu-list item or 
>a button on the gui or something.  For example, when one wishes to 
>connect two actors, they could connect them graphically, then hit a 
>button or something to further specify the connection using your tool. 
>Make sense?

Yes, that makes a lot of sense.

> >(5) develop a set of interesting use cases.
>
>This is going to be the hard one I think ...

Possibly not as hard as writing the code in the first place!

>>We are pleased that Jianting Zhang at UNM is interested to work with us on
>>making the tool really useful for ecologists, and we hope that closer
>>collaborations can be estabalished with other SEEKers to reach this goal.
>>
>>  -- Joseph Goguen and Jenny Wang
>>_______________________________________________
>>kepler-dev mailing list
>>kepler-dev at ecoinformatics.org
>>http://www.ecoinformatics.org/mailman/listinfo/kepler-dev