Extending the ACUITy Problem/Vantage/Frame Ontology Using the ACUITy Editor
Introduction
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:
- 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
- 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:
- instantiate a specific instance of SimpleDataTable (an Individual), say
MyXYZTabData
- 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:
- the subject (an individual or class)
- the property (an object or a data type property)
- the restriction type
- 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.
- 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.
- 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.)
- 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.)
- 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.
| // 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