[kepler-dev] Schema matching tool for interface alignment
goguen at cs.ucsd.edu
Mon Oct 18 15:59:26 PDT 2004
>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 [220.127.116.11]); pass=YES; Mon, 18 Oct 2004 09:41:40 -0700
>X-Scanned-By: milter-spamc/0.15.245 (gradlab.ucsd.edu [18.104.22.168]); pass=YES; Mon, 18 Oct 2004 09:41:39 -0700
>X-Spam-Status: NO, hits=-4.90 required=5.00
>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;
>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.
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
More information about the Kepler-dev