| At line 91 added 4 lines. |
| + **** Improving the Annotation Tool |
| + ***** Filling in Annotations via ontology constraints |
| + ***** Defining what makes a "good" annotation, and how to guide users towards these |
| + ***** Improvements to the UI, including selecting ontologies and "templated" annotations |
| Lines 112-113 were replaced by lines 116-126 |
| - *** Scalability of 'knowledge reasoning' approaches to data integration (e.g., incorporating instance data) |
| - **** Discuss possibility of the reasoner (e.g., Jena) developing an 'integration plan' that is implemented in another system (e.g., R) to avoid having to load instance data from multiple voluminous data sets (e.g., 3 100MB data files) into the reasoner itself (e.g., Jena) |
| + ** Data Management support for sms |
| + *** The EML actor as entry point for data integration |
| + *** How do we carry out integration specifications given by sms? |
| + **** For example, using "R" to load instance data from multiple voluminous data sets (e.g., 3 100MB data files) and executing data integration "recipes" |
| + **** A database-style approach? (e.g., SQL) |
| + ** What approach do we use for representing data conversions? |
| + *** Examples: unit conversions, count/area = density, rescaling/projection |
| + *** Represent conversions within ontology? |
| + *** Represent conversions as actors (searched via annotations, e.g.) |
| + *** Define a new or leverage an existing representation for conversions (Prolog, SWRL, XML syntax a la STMML, MoML attributes) |
| + *** Use potpourri approach (i.e., try to accomodate multiple mechanisms) |
