Extending the ACUITy Problem/Vantage/Frame Ontology Using the ACUITy Editor


ACUITy embodies the Work-Centered Support concept of "the user finishes the design." We leverage this concept in the approach taken by the ACUITy Editor in the sense that a developer and/or subject matter expert can begin with the ACUITy problem/vantage/frame (APVF) ontology imported into an essentially empty domain-specific application ontology and build the application model as an extension of the APVF ontology. This can be done in two ways:

  1. Interactively by adding to the application model one class, individual, or property at a time via the various editing actions available in the ACUITy editor
  2. In a kind of batch processing mode by importing all or part of an application model specification from a comma-separated-value (CSV) file, normally created and maintained via some kind of spreadsheet tool, e.g., Microsoft Excel.

Both of these modes of model development use the same basic design patterns. However, the latter lends itself to using design patterns as a template which can be pasted into the spreadsheet and modified to create complex and possibly repetitive structures. In this document we will first provide an overview of basic editor concepts and then discuss each mode of model development. Finally, we will provide a library of design patterns suitable for use as guide during interactive model construction or for customization and use as a spreadsheet model specification prior imported into the application.

Overview of Editor Concepts

Normally a domain-specific application of ACUITy will instantiate at least two namespaces: 1) the definition of classes and properties which extend the APVF ontology and other upper-level ontologies (the t-box), and 2) the instances which are created in the process of using the application (the a-box). An application is made extensible at the concept level by importing portions of the ACUITy Editor ontology and by adding an "Application Editor" vantage to the application's Frame class. This makes the ACUITy Editor functionality available within the application interface. Class definitions, including restrictions, and property definitions that are added interactively become part of the application model (t-box) namespace. Note that following the process described in Creating a new ACUITy-powered application will result in an empty project model which includes the ACUITy Editor.

At the heart of the ACUITy Editor are the concepts of instantiation, extension, restriction, and defaults. For example, given an APVF concept, e.g., SimpleDataTable, it is possible to:

  1. instantiate a specific instance of SimpleDataTable (an Individual), say MyXYZTabData
  2. extend the SimpleDataTable class by creating a subclass, say XYZTabData, with appropriate restrictions and/or defaults to define the unique nature of the class

Creating new classes and individuals are both supported by the ACUITy Editor. However, they are normally used under somewhat different circumstances. One purpose of the ACUITy Editor is to both guide and teach the user the subtleties of this and other issues and trade-offs inherent in building an ACUITy application.

To illustrate, suppose that we wish to create a new kind of SimpleDataTable in an application and populate it with data from a particular database source. Since many different users may wish to create instances of the new type of SimpleDataTable , and each instance may have unique properties such as position in the display, we probably want to create a new subclass of SimpleDataTable, call it XYZTabData. By constrast, the data source is probably not going to be different for each instance of XYZTabData so there is no need to create a new class of DBConnection. Likewise, if the data will be retrieved by the same SQLStatement (query) for each instance of the table, a new SQLStatement subclass is not needed. Rather the user should create a new instance of DBConnection, say MyXYZDataSource, to capture the information necessary to connect to the database and a new instance of  SQLStatement, say SelectXYZ, to specify the instructions for data retrieval. The new SimpleDataTable subclass, XYZTabData, should be given a hasValue restriction that it "encodes" the Individual SelectXYZ, which in turn "hasDBConnection" MyXYZDataSource.

The user-interface of the ACUITy Editor is built using ACUITy--it is part of an ACUITy application. The editor model defines DisplayObjects, InteractionObjects, and ServerSideScripts which allow the user to see the application model and modify it by creating new instances, subclasses, properties, and defaults that extend the existing domain ontology in particular ways consistent with the assumptions of ACUITy. Once an extension is made by adding a new class or property, that class or property is available for further extension and for use in the domain application. It is also available for inspection in the application Vantage of which it is a part, if any. Customized editors are possible by extending or modifying the editor ontologies.

Editing an Application Model Interactively

The heart of the ACUITy Editor is an editable data table with row spanning. The data table has a "subject" individual or class. If the subject is an individual, cells in the first column of the table identify properties of the individuals. If the subject is a class, cells in the first column identify properties restricted or given defaults on the class. The second column displays the kind of restriction for classes, e.g., SomeValuesFrom, or N/A for individuals. The third column displays the value of the property for an individual or the value of the restriction or the default value if a class. The value may be a primitive data type, e.g., xsd:string, or an individual or a class, depending on the subject and the preceding columns. The fourth column contains a magnifying glass icon for drilling down (making the class or individual in the cell to the left the root of the table) where appropriate. The fifth column contains an icon for opening up a blank row to add a new property, restriction, or default. Note that the current editor, because the data is sorted, will move a new row to the top of the table but will move it down as it is given values.

The five columns described above form a "set". If an individual or class is in the 3rd column of the set, the properties of that individual can be seen as the next set and may be shown to the right of the individual or class. The depth of the table, which can be modified via a dropdown list, defines the number of sets visible in the table. An ellipsis (...) to the right of a row of a set indicates that there are more sets that may be made visible by drilling down.

To add a new statement to the model, click on the "Insert Row" icon (). This will result in an empty row being added to the table. Note that currently, because of table sorting, the row may not appear near the row in which the insertion was initiated. The first cell of the set in the new row will contain a list of possible properties along with the option to create a new property. Once the property and restriction type have been set, the third column of the set will allow the value of the restriction to be specified. In the case of object properties or data type properties with range xsd:boolean, a selection list containing an appropriate list of classes, individuals, or values will appear. For object properties, this list will contain "Create New Class" or "Create New Individual". For non-boolean data type properties, a text input box will allow a value to be specified.

Importing Model Specifications via a CSV File

The specification of a model or part of a model in a comma-separated-value (CSV) file follows the same basic layout as the editor's editable data table described in the preceding section except that each row contains only a single "set" and the subject of the set is explicitly stated in the first column. The columns are:

  1. the subject (an individual or class)
  2. the property (an object or a data type property)
  3. the restriction type
  4. the restriction value

The syntax for cells in the CSV spreadsheet must be adhered to rigorously. All OWL resources (class, individual, or property) are represented as an opening angle bracket, followed by an optional namespace prefix followed by a colon, followed by the local name of the resource, followed by a closing angle bracket. Similarly, restriction types are enclosed in angle brackets. Data property values are not enclosed in angle brackets. A cell which specifies a resource may also specify the class of an individual or the super class of a class or the super property of a property by using the same syntax, followed by a colon, followed by the resource. Below are some examples of valid cell syntax.

Cell Content Interpretation
<apvf:Frame> the "Frame" class in the APVF ontology
<apvf:Frame>:<AppModelFrame> a class or an individual of type "apvf:Frame" with local name "AppModelFrame" in the current model (other cells in the row disambiguate whether it is a class or individual)
<apvf:hasVantage> the "hasVantage" property in the APVF ontology
<someValuesFrom> the restriction type some values from
<seeAlso defValue> the restriction type rdfs:seeAlso default value (see Default Values templates, Using an OWL Repository for Inductive and Abductive Learning [paper])
true the value "true"
64 the value 64
SELECT salary from PERSONNEL where PERSON_ID = ${CurrentPerson} a string value (presumably an SQLquery) which has an anchor referencing the script "CurrentPerson", probably in the application model (not an imported model, no prefix is given)

Before getting into design patterns (examples of complete rows in a CSV file), it should be noted that the ACUITy editor has an editing action, "Export to/Import from Spreadsheet", allowing importation of CSV files. Selecting a CSV file will cause the file to be analyzed  and a preview of the expected results of importing the file to be displayed in tabular form. The editor also supports doing the actual import and exporting portions of the current model to a CSV file. It is possible, for example, to export the model, edit the CSV file to add additional model components, preview the modified model for the expected model additions (useful for validating the content before importing), and import the file. Note that importing a CSV file does not automatically save the model changes. Changes must be saved with the appropriate editor action just as for interactive changes. Note also that if changes are not saved, it is necessary to restart the application server to restore the model to its original state because of imported model caching in the Jena repository interface. By the way, a master CSV file stored in a source code repository such as CVS is an excellent way to keep track of model changes and inspect differences between different versions of an application model. Unlike the XML content of an OWL file, the order will not be unpredictable.

When the subject of a row in the import file is a class and the property and restriction type columns match something that already exists in the model, the model will be updated with the restriction value from the import file. When the subject is an individual (instance of a class) and the property matches something that already exists in the model (normally the restriction type will be "<N/A>" or will be left empty for this case), one of four things can happen.

  1. The import file's 4th column restriction value is the same as the that in the model so nothing happens. (The editor's Preview Import Results table shows a Resulting Actions in the 5th column, which will be empty in this case.
  2. The import file's 4th column restriction value is different from the import file and the property is functional so the restriction value in the current model will be REPLACED by the value in the import file. (Notification of this replacement will appear in the Preview Import Results table's Resulting Action column.)
  3. The 4th column's restriction value is different from the import file and the property is NOT functional so a new property value will be ADDED to the model. (Notification of this addition will appear in the Preview Import Results table's Resulting Action column.)
  4. It may be the case that the 4th column's restriction value is different from the import file and the property is NOT functional but we still wish to replace the value rather than add another value. This can be accomplished by placing a line in the import file preceding this line with the same subject and property columns but a special "!clean" command in the restriction type column (nothing needed in the restriction value column). This will clear the old value(s) of the property on the subject so that this line will assign the new value as the only value.

Note that rdfs:label is treated as if it were functional even thought it is not. Given the way that ACUITy uses labels, it does not make sense to have more than one. Note that this would need to be more sophisticated to support multiple languages, presumably allowing one label per language. Note that in the current release, the Resulting Action column reports that the label will be added when it fact it will be used to replace any existing label.

Design Patterns

Example 1: The Vantages of an Application (AddingAVantage.csv)

// Adding a Vantage to an application      
<apv:Frame>:<AppModelFrame> <apvf:hasVantage> <someValuesFrom> <apvf:Vantage>:<MainVantage>
<MainVantage> <rdfs:label> <N/A> Main
<AppModelFrame> <apvf:hasVantage> <someValuesFrom> <apvf:Vantage>:<PreliminaryInvestigationVantage>
<PreliminaryInvestigationVantage> <rdfs:label> <N/A> Preliminary Investigation

Example 2: The Contents of a Vantage (VantageContent.csv)

// Adding content to a Vantage      
<apvf:Vantage>:<MainVantage> <apvf:containsPresentationObject> <someValuesFrom> <apvf:DateInputObject>:<InputDesiredDate>
<MainVantage> <apvf:containsPresentationObject> <someValuesFrom> <apvf:SimpleDataTable>:<EventsOnDate>
<MainVantage> <apvf:containsPresentationObject> <someValuesFrom> <apvf:GraphObject>:<NumberOfEventsByDay>

Note:  The declaration of the super class of <MainVantage> in the second row, first cell would not be needed if either the vantage already existed in the model or the import file had a definition of <MainVantage> at a previous line as would be the case if Example 1 was found first in the same import file.

Example 3: Defining a SimpleDataTable (SimpleDataTable.csv)

// Adding a SimpleDataTable to a Vantage      
<apvf:SimpleDataTable>:<EventsOnDate> <apvf:encodes> <hasValue> <apvf:SQLStatement>:<EventsOnDateQuery>
<EventsOnDateQuery> <apvf:hasDBConnection> <N/A> <apvf:DBConnection>:<MyDBConnection>
<MyDBConnection> <apvf:dbConnectionString> <N/A> jdbc:oracle:thin:@host.mycom.com:1234:ABCD
<MyDBConnection> <apvf:dbPasswordString> <N/A> mypassword
<MyDBConnection> <apvf:dbDriverString> <N/A> oracle.jdbc.driver.OracleDriver
<MyDBConnection> <apvf:dbLoginString> <N/A> mydbuserid
<EventsOnDateQuery> <apvf:dbSQLString> <N/A> select * from events where event_date = TO_DATE('${GetCurrentDate}', 'MM/DD/YYYY')

Note: of course the referenced database ("ABCD") would have to exist with compatible schema to make this example work.

Example 4: Defining a Graph with SimpleDataSeries (GraphObjectWithSimpleDataSeries.csv)

// Adding a Graph to a Vantage      
<apvf:GraphObject>:<NumerOfEventsByDay> <apvf:containsPresentationObject> <someValuesFrom> <apvf:SimpleDataSeries>:<EventsByDaySeries>
<EventsByDaySeries> <apvf:encodes> <hasValue> <apvf:SQLStatement>:<EventsByDayQuery>
<EventsByDayQuery> <apvf:hasDBConnection> <N/A> <MyDBConnection>
<EventsByDayQuery> <apvf:dbSQLString> <N/A> select ... count ... event_date >= TO_DATE('${GetCurrentDate}', 'MM/DD/YYYY') - 5 AND event_date <= TO_DATE('${GetCurrentDate}', 'MM/DD/YYYY') + 5

Note: this assumes that <MyDBConnection>, defined in Example 3 already exists  or is defined earlier in the import file. Note also that the SQL query string is abbreviated.

Additional Design Patterns

For additional design patterns, see ACUITy Design Patterns and Concepts and Design Patterns in APVFPLUS.

See also:

Copyright General Electric Company 2006
Last revised 05/14/2007