No subject

Tue Mar 22 16:37:17 PST 2005


For "semantic types", one necessary feature required is to support 
semantic type "annotation" at a very fine granularity. In particular, for 
a given port, with a structured type of record, e.g., we need to "attach" 
a concept to single components of the record and to groups of components 
of the record. (I say "attach" because there are different 
ways/interpretations for the attachment that must be characterized as 
well).  If the record contains additional sub-structure (i.e., one of  its 
components has a structured type), we may also need to attach concepts to 
those substructures as well, etc. (E.g., this is what is done for XML).  

At a higher level, we also will need to attach concepts to individual 
ports, and groups of ports.  

To perform the "constraint" checking for semantic types, we would need to 
insert our own algorithm, and so having a componentized architecture for 
this checking is great.  (I am assuming you designed it this way, but 
didn't look into the code.) 

Having the "hooks" for the unit type system seems like it offers a great 
start. Thanks for the heads-up.


> Edward
> At 02:40 AM 5/10/2004 -0700, Bertram Ludaescher wrote:
> >Since we just chatted about some of this I wanted to through out the
> >question again as to what people think how we might extend Ptolemy's
> >type system to support (a) XML Schema (-like) types as they are used
> >in web services and other apps, and (b) semantic types (in the SEEK
> >sense).
> >
> >It seems that Ptolemy II already has an XML token type. However I
> >think the (somewhat unnecessarily complex) XML Schema types are not
> >supported, in the sense that there are no XML Schema port types (as
> >far as I know), so no static type checking when linking XML ports is
> >done.
> >
> >Maybe Relax NG could also be a (simpler and apparently
> >better/extensible etc) alternative to XML Schema, should we decide to
> >support static XML types in Kepler. The type extension mechanism could
> >(wild speculation ahead) possible be also (mis-)used for our semantic
> >typing extensions...
> >
> >Bertram
> >a
> >PS
> >_______________________________________________
> >kepler-dev mailing list
> >kepler-dev at
> >
> ------------
> Edward A. Lee, Professor
> 518 Cory Hall, UC Berkeley, Berkeley, CA 94720
> phone: 510-642-0455, fax: 510-642-2739
> eal at eecs.Berkeley.EDU,
> _______________________________________________
> seek-dev mailing list
> seek-dev at

More information about the Kepler-dev mailing list