Kepler

This sounds interesting. Below are some resources.

Currently, Ptolemy has two unit systems in place, so
some of this data is available. See ptolemy.data.unit.

There is some work involving properties such as the
const-ness of a data port. See ptolemy.data.properties
See also http://chess.eecs.berkeley.edu/pthomas

The key to adding metadata is to do it in such a manner
that the token size is not increased substantially
and processing time does not take longer. Look at
the nil token work as a possible solution.

To address axis labeling (and any alternate naming for R objects for that matter), the RExpression now sets a "name" attribute for every object it makes available in the R environment. The attribute value is set to the port name of the upstream source port.
See the KEPLER/demos/R/upstream-axis-labels-R.xml workflow for an example.

Turns out there is a strict vector test that does not allow extra attributes on a vector (used in barplot() method). we'll have to find another way to add metadata - hopefully one that will not adversely affect existing R actors or place undo burden on custom script authors.

I've commented out the R object metadata that adds a "name" attribute to every R object created for use in Kepler.

I've done some "proof of concepting" with TokenMetadata. General gist of it is:
-add metadata at EMLDataSource (name, description)
-travels along the relationships to downstream actors
-modified most of the Plotter-based actors to use the TokenMetadata names for axis labeling.

It's pretty slick and minimally invasive, but not clear how to introduce the metadata into the R environment.

Also to think about: An ArrayToken has TokenMetadata but it is a list of Tokens that too can have TokenMetadata. For instances of ArrayToken that represent the values of a column of tabular data, having a single TokenMetadata for the list is all that is necessary (all the Tokens in the list share the same metadata). The current implementation adds TokenMetadata to each and every Token in the ArrayToken list (overkill!). Are there instances that come to mind where each Token in an ArrayToken must have its own distinct TokenMetadata? My hunch is that there are indeed cases where the the array contains semantically heterogeneous data Tokens.

Original Bugzilla ID was 2962