[kepler-dev] web service actor

Thu Apr 1 02:11:03 PST 2004

>>>>> "SAN" == Stephen Andrew Neuendorffer <neuendor at eecs.berkeley.edu> writes:
SAN> 
SAN> This seems like a good time for me to chime in..

good time for me to chime in too (just a month or so later ;-)

I like your observation about the distinction between structural and
semantic types. As a rule of thumb one may say sth like this:

1. The structural type of a port can be automatically determined by
looking at the data values. (This is probably strictly true for Java
object types, since I can ask the object what type it has. It is also
quite true for XML data, since one can infer *some* XML DTD/Schema
from looking at one (or more) instances)

2. The semantic type is "external" in that it cannot be inferred (by a 
machine) from looking at the data values. (So instead it has to be
provided by the workflow designer.)

Bertram

SAN> I realized the other day that the type inference infrastructure in Ptolemy 
SAN> II currently
SAN> requires that the type of a value is derivable from the value...  (or, put 
SAN> another way,
SAN> the type system computes an abstract interpretation of a model)
SAN> 
SAN> However, it seems to me that although semantic types can be expressed in a
SAN> similar way, semantic types are rarely derivable from values.  I may assert 
SAN> semantic types
SAN> on an output port and an input port and require that they be consistent, 
SAN> but those
SAN> semantic types are not present (or really meaningful) at run time.  The 
SAN> semantic type
SAN> constraints of an actor cannot (generally) be derived from the function 
SAN> that an
SAN> actor computes.
SAN> 
SAN> Steve
SAN> 
SAN> At 06:35 AM 2/27/2004 -0800, Bertram Ludaescher wrote:
SAN> 
>> Dear all:
>> 
>> Here some of my own musings on the same topic:
>> 
>> (1) First, here is a good paper for our XML typing discussions:
>> http://homepages.inf.ed.ac.uk/wadler/papers/xml-essence/xml-essence.pdf
>> I'd like to suggest it as required reading, as it deals with
>> validating XML *objects* (or "documents", "fragments") wrt. XML Schema
>> type. It also has some sobering statements such as this one:
>> 
>> "So the essence of XML is this: the problem it solves is not hard, and
>> it does not solve the problem well."
>> 
>> But we knew that one already, right ;-)
>> 
>> (2) The following is written from a databases point of view:
>> http://www.acm.org/sigmod/record/issues/0203/dansuciu-lipkin.pdf
>> It's a good introduction to the problem of typechecking *queries*.
>> 
>> I think our problem, XML types for Kepler, has aspects of both
>> (1), which deals with the problem from a programming languages POV and
>> (2), which deals with the problem from a database POV.
>> 
>> (3) We want to make sure that an XML token that "shows up" at a port
>> of an actor corresponds to the (XML Schema) type of that port. That's
>> (1).  At the same time, consider the problem of an actor which
>> implements a database transformation, say specified in XQuery or in
>> XSLT. Can we determine from the type at the input port(s) and the
>> knowledge of the XML transformation, the type at the output port. This
>> is the problem discussed in (2). While we're at it, we can apply the
>> same schema reasoning to a whole (process) network.
>> 
>> (4) We can call the XML Schema type of a port, its *structural type*.
>> If we associate a port with a concept expression (say from an OWL
>> ontology), then we can call this its *semantic type*. The question now
>> is: if a connection between two actors is semantically type correct
>> (here subtyping is defined as concept subsumption), but not
>> structurally, can we infer a structural transformation that "does the
>> trick", based on a "semantic registration" of the structural types.
>> Uff... just read this (quite preliminary) work by Shawn and myself:
>> http://www.sdsc.edu/~ludaesch/Paper/dils04.pdf
>> 
>> (5) Another interesting question is this one: Can we solve the problem
>> of semantic typing of ports by resorting to structural types. More
>> specifically we used named types over a type system such as
>> Hindley-Milner, possibly extended in various ways.
>> I just came across this interesting work here: "Sexy Types in action"
>> http://www.eecs.harvard.edu/~ccshan/cs252/usage.pdf
>> Maybe it can help us with some answers...
>> 
>> 
>> So coming back to Chad's original request, i.e., how about Java
>> object types (since SOAP allows it) for actor ports: yep, why not.
>> At the same time, we can take the opportunity to look at semantic
>> types issues as well (Shawn will have a natural interest in that ;-)
>> and solve the whole thing once and for all...
>> 
>> 
>> Bertram
>> 
>> 
>> 
>> 
>> >>>>> "EAL" == Edward A Lee <eal at eecs.berkeley.edu> writes:
EAL> 
EAL> At 12:39 PM 2/26/2004 -0800, Shawn Bowers wrote:
>> >> However, the classic notion of subtyping in programming languages doesn't
>> >> otherwise pop up much for XML.  One reason is that XML is inherently
>> >> "distributed."  Gven two schemas from different organizations, just
>> >> because they have the same structure, or one is a subtype in terms of
>> >> structure, there is absolutely no guarantee that these schemas have
>> >> anything to do with each other.  The same is true if we also consider tag
>> >> names (it may just be coincidence that some of the tag names are the
>> >> same).  Because the schemas were developed independently, it would 
>> also be
>> >> pretty unusual that even for otherwise identical schemas, that the tag
>> >> names or structure *would* be the same.
EAL> 
EAL> Yes, good point...
EAL> 
EAL> However, there might be real potential for subtyping.
EAL> Consider for example an XML schema that represents actors
EAL> and their interconnection (to pick a random example :-)
EAL> and another that extends this with visual annotations (where
EAL> on the screen an actor should be rendered, for example).
EAL> A tool that used the former type would be unaffected by
EAL> the addition of the latter data. In the current state of
EAL> affairs, I think that such a tool (if it validates the XML)
EAL> would have to reject a model with visual annotations, no?
EAL> 
EAL> Edward
EAL> 
EAL> 
EAL> 
EAL> ------------
EAL> Edward A. Lee, Professor
EAL> 518 Cory Hall, UC Berkeley, Berkeley, CA 94720
EAL> phone: 510-642-0455, fax: 510-642-2739
EAL> eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal
>> _______________________________________________
>> kepler-dev mailing list
>> kepler-dev at ecoinformatics.org
>> http://www.ecoinformatics.org/mailman/listinfo/kepler-dev
SAN> 