Overview of The AcuityController

A. W. Crapo, last revised 06/14/2005

Copyright General Electric Company 2005, 2006

Introduction

The AcuityController is a Java class that, along with other supporting classes, provides an application programmers interface (API) to a semantic model of a Problem/Vantage/Frame implementation of Work Centered Support(1, 2). The semantic model is ontology-based and is intended to be robust and extensible, capable of supporting adaptive user-interfaces. While the AcuityController is largely domain-independent, it is designed to be extended (sub-classed) if needed to create domain-specific interfaces. In general, domain-specific knowledge is captured in the ontology and a customized controller is not needed. The Problem/Vantage/Frame knowledge is expressed in the Web Ontology Language (OWL) and it is assumed that domain-specific knowledge will be similarly expressed. This document describes the overall architecture and design approach used to create the AcuityController along with selected functionality. Additional documentation of possible interest includes:

A Hierarchy of Ontologies

The AcuityController supports hierarchies of ontologies through use of the OWL import functionality. For example, a very basic classification of things that exist, e.g., physical versus abstract, is represented in the Acuity upper-level ontology (http://research.ge.com/Acuity/aulo.owl, abbreviated as prefix aulo), which is then extended to include Problem/Vantage/Frame concepts in the Acuity Problem/Vantage/Frame ontology (http://research.ge.com/Acuity/apvf.owl, abbreviated as prefix apvf). The latter ontology uses the "owl:imports" construct to  reference the former. Similarly, a domain-specific ontology can be placed in one or more owl files and can then import these domain-independent ontologies. An ontology can use any number of "owl:imports" to include existing ontologies, which can be used and/or extended in the importing ontology. Note that even if an application uses the relational database ontology storage option (described below), it will probably be the case that the ontology will be designed in individual owl files and subsequently be moved to the database storage.

Note that while OWL ontologies, including those that are imported, have a public namespace, it may be desirable to actually load them from a different URI. Jena, upon which the AcuityController is built and which is used to load the ontologies, allows a mapping between public and actual URIs to be specified in an ontology policy file, usually named ont-policy.rdf.

Instance Data and Persistent Memory

Any OWL ontology can include instances as well as the declarations of classes and properties (relations). In Description Logics (DL) nomenclature, the abstract class and property declarations are the tbox (terminology) and the instance data is the abox (assertions). It is our objective to distinguish between the extension of an ontology by defining new classes and/or properties (new abstractions) and the extension of an ontology by including (remembering) new instances. The former is at the heart of an extensible user-interface capable of handling new kinds of problems while the latter is a simpler form of learning useful in achieving adaptive behavior. For example, each time a particular user (an instance of Person) chooses to see a particular piece of information related to a particular problem, remembering the problem and the information used (instances) allows the AcuityController to adapt future displays for this particular user to make the information the user is most likely to consider relevant more prominent. Since the ontology captures the generalizations, e.g., owl:Classes, to which instances belong, it is often more useful to aggregate information to the Class level in order to, for example, provide default information for a new instance of a class of problems based on the remembered history of other instances of that class.

In implementing an instance memory, a potential conflict of objectives is encountered. It may be desirable to load a domain's ontology hierarchy, as described above, as URIs from a web server. However, since it is not generally possible to write the instance data acquired in the course of a session back to a URI, a file storage medium may be desirable. The problem is resolved by using the "owl:imports" tab described in the previous section. The instance data (abox), which may be loaded from a local file, imports the abstract declarations (tbox) from a server. At the end of the session, the instance data may be written back to the file system ready for use in subsequent sessions by calling the AcuityController save method. In this way, the core knowledge can be loaded from a central repository (web server) while each application can use its own instance memory. The core knowledge can be extended without affecting instance memory as long as changes are not made which render existing instances inconsistent with the terminology. Note that a local instance cache of this type must be initialized in some way as described below.

Alternatively, a database backend can be used to store both tbox and abox information. In general, better performance for small ontologies is achieved with the file-based approach described above. The AcuityController method convertModelToDatabaseModel allows an ontology to be converted to a database model using Jena functionality. Existing instance (abox) content is converted and can be augmented with additional instance data in the database model in a persistent manner. An alternate AcuityController constructor allows the database model to be loaded as the active model. Note that unlike the file-based instance storage described above, where the save method must be called to persist instance data new in this session, when db-based persistence is used the save method must be called to delete any temporary instance data, which is not to be persisted, from the database.

Initialization of an AcuityController

Consistent with the above design considerations, the following information must be provided to create an instance of and initialize an AcuityController. Where defaults can be provided, constructors are provided which use the default values noted. For constructor details see the JavaDoc documentation.

If the model is loaded from an OWL file, either local or at a URI, the following information is needed:

  1. The Jena ontology policy file. If this mapping file is not specified (a constructor is used without this argument) or is null, all imported ontologies must actually be found at their public URIs.
  2. The path and name of the local instance file persistent store. This can be unspecified or null if no instance data is to be persisted.
  3. The URI of the ontology to be used for initialization if no content is found in the local instance file. This initialization content will be replicated, along with any new instance data, in the content written to the local instance file, if named, when save is called. Note that at a minimum the initialization file should specify the namespace of the instance data to be remembered and an owl:imports tag with the location of the tbox ontology. Of course this tbox can import other ontologies, etc. While this initialization ontology is not used when there is an existing instance store, it must be present for an instance store to be created and would not normally be null.
  4. An OntModelSpec (a Jena class) identifying the reasoner (if any) to be used. By default the OntModelSpec.OWL_MEM_TRANS_INF (OWL in-memory transitive reasoner) is used.
  5. The trace level for debug or informational output from the AcuityController and the underlying Jena library. By default, no tracing is enabled (0). The possible values of this flag are found in the AcuityConstants Java class.

If the model is loaded from a database (DB model, which provides instance persistence) the following information is needed:

  1. The database ontology's public URI (namespace).
  2. The database URI, e.g., "jdbc:mysql://<host>/<dbname>" where host and dbname are specified as part of the database instance creation and must be setup in advance.
  3. The database user.
  4. The database user's password.
  5. The database type, e.g., "MySQL". This value is recognized by the Jena database backend.
  6. The database driver Java class name, e.g., "com.mysql.jdbc.Driver".
  7. An OntModelSpec (a Jena class) identifying the reasoner (if any) to be used. By default the OntModelSpec.OWL_MEM_TRANS_INF (OWL in-memory transitive reasoner) is used.
  8. The trace level for debug or informational output from the AcuityController and the underlying Jena library. By default, no tracing is enabled (0). The possible values of this int flag are found in the AcuityConstants Java class.

Interaction with an Initialized AcuityController

Once initialized by loading the knowledge base (tbox) and local instance data (abox), the AcuityController API supports several different kinds of interaction. It is useful to remember the essential role of RDF triples in all OWL ontologies. An RDF triple can be thought of as a pseudo-English sentence in the form of (subject, predicate, object). In Jena terminology, an RDF triple is a Statement. For example, to tell the knowledge base that George is a Person (is of type Person), the information content of the tell expression (omitting namespace information) would be the Statement or triple:

(George, type, Person)

Namespace Considerations

However, in order to make the three parts of the RDF triple "machine understandable", each must actually be a fully qualified URI. Such a URI can be constructed from two parts; a namespace designator (URI followed by a "#") and a fragment identifier or local name within the namespace. For example, type in the triple above is really:

http://www.w3.org/1999/02/22-rdf-syntax-ns#type

If Person is defined in the namespace http://research.ge.com/Acuity/aulo.owl and George is an instance in namespace http://research.ge.com/Acuity/rbProto.owl, the complete RDF triple would be:

(http://research.ge.com/Acuity/rbProto.owl#George, http://www.w3.org/1999/02/22-rdf-syntax-ns#type, http://research.ge.com/Acuity/aulo.owl#Person)

AcuityConstants Namespace Named Static String

To facilitate the correct use of namespaces, the AcuityConstants class contains the namespace for the aulo.owl file (AcuityConstants.ULO_NS) and the apvf.owl file (AcuityConstants.PVF_NS), along with some other important and frequently referenced namespaces, as static Strings. Below are some examples of how to use these constants along with their actual values in parenthesis.

The AcuityConstants class also provides the static function, createNS(nsDesignator, fragID), to combine the namespace designator and the fragment identifier. This method can be used to create the argument to the Jena OntModel methods createResource, createProperty, createIndividual, etc. For example, if an AcuityController ac has been created which loads the rbProto.owl file, the Java code to create the Jena Resource for George is:

AcuityController ac = ...;
Resource cls = ac.getResource(AcuityConstants.createNS(AcuityConstants.ULO_NS, "Person"));    // find the Resource for the class Person
Resource r = ac.createIndividual(AcuityConstants.createNS(AcuityConstants.ULO_NS, "Person"),   AcuityConstants.createNS("http://research.ge.com/Acuity/rbProto.owl#", "George"));    // create a new instance of Person

Domain-specific implementations can extend the AcuityConstants class with additional namespaces. For example, the ErpConstants class contains the following Java code:

public class ErpConstants extends AcuityConstants {
        public static final String ERP_KB_PUB = "http://research.ge.com/Acuity/aerpData.owl";
}

In this way any extension of AcuityConstants, e.g., ErfConstants, can be used to reference any namespace defined either in the subclass or in the super class.

Namespace Prefixes

Alternatively, RDF files in general and OWL files more specifically allow the designation of a namespace prefix in the opening RDF tag. For example, one of the elements of this tag in the Acuity upper-level ontology file (aulo.owl) is:

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

This element defines the string "rdf" as the prefix for the namespace "http://www.w3.org/1999/02/22-rdf-syntax-ns#".  This information allows one to abbreviate a reference to "http://www.w3.org/1999/02/22-rdf-syntax-ns#type" as "rdf:type". Assuming the prefixes "rbproto" and "aulo", the RDF triple above becomes:

(rbproto:George, rdf:type, aulo:Person)

Whenever a Resource name is passed to a method in an AcuityController instance, if the name does not appear to be a complete URI, i.e., there is no "#" in the name, the AcuityController will look to see if a prefix is provided. If there is a colon in the name, the portion of the name before the colon is used to check for a prefix in the ontology model's namespace prefix map. If it matches a known prefix, the prefix is replaced with the corresponding namespace. Therefore, the code segment shown above to demonstrate the use of static Strings in the class AcuityConstants could also be implemented as follows, assuming the prefixes shown have been defined:

AcuityController ac = ...;
Resource cls = ac.getResource("aulo:Person");                                    // find the Resource for the class Person
Resource r = ac.createIndividual("aulo:Person", "rbproto:George");      // create a new instance of Person

The [Dubious] Assumption of Uniqueness

The AcuityController provides another means of assisting with namespace management. In many cases, the local name will be unique--the same local name will not be used in any referenced or imported ontologies used in the application. When this is the case, the AcuityController's getResourceURI(localName) method can be used explicitly. This method will find a namespace, assumed to be the only one, containing the local name and return the complete URI. Alternatively, the AcuityController will check a Resource name and if it appears to be neither a complete URI nor a prefix followed by a local name, an attempt to find a matching local name in the ontology. This of course will only work for existing Resources. Thus in the code example could be rewritten as:

AcuityController ac = ...;
Resource cls = ac.getResource( "Person");                                    // find the Resource for the class Person
Resource r = ac.createIndividual( "Person", "rbproto:George");      // create a new instance of Person

The second argument of the createIndividual method call cannot be "George" because this local name does not yet exist. However, the class "Person" does and so that Resource can be found. Care should be taken that the assumption of uniqueness is met and continues to be met as an ontology evolves if this AcuityController feature is used.

Instance Data Namespace

Two AcuityController methods make use of the instance data namespace a little easier. The instance data namespace can always be retrieved from an instance of the AcuityController by calling getInstanceDataNamespace. A local name fragment in the instance data namespace can be converted to a URI by calling mkInstanceDataURI. The example above could be rewritten as:

AcuityController ac = ...;
Resource cls = ac.getResource( "Person");                                                              // find the Resource for the class Person
Resource r = ac.createIndividual( "Person", ac.mkInstanceDataURI("George"));      // create a new instance of Person

Note that all Individuals created by the AcuityController have the instance data namespace even though the owl:Class of which they are an instance may be in a different namespace. 

Tell and Ask

Perhaps the most fundamental interaction with the AcuityController is to ask questions and tell new information. RDF triples are the primary expression used in either case. 

For example, given an AcutiyController instance ac1, the RDF expression, without namespace information, to tell the knowledge base that George is the user of this instance would be:

(ac1, hasUser, George)

Of course addition of the correct namespace information is essential for achieving the desired behavior from the ontology. If hasUser is an Object property in the apvf.owl ontology and AcuityController is a subclass of the aulo.owl class ArtificialAgent with instance ac1 defined in the rbProto.owl ontology, the fully qualified RDF triple for stating the above assertion is:

(http://research.ge.com/Acuity/rbProto.owl#ac1, http://research.ge.com/Acuity/apvf.owl#hasUser, http://research.ge.com/Acuity/rbProto.owl#George)

or, assuming the prefixes shown:

(rbproto:ac1, apvf:hasUser, rbProto:George)

The AcutiyController class provides a tell method for imparting new information to the knowledge base. This method requires three arguments: 1) a subject, 2) a predicate, and 3) an object. The following code segment illustrates use of the tell method to assert that George is the user of ac1, after first creating the necessary resources.

AcuityController a = ...;
Property p = a.getOntProperty("apvf:hasUser"))                                        // get the Property "hasUser"
Resource newPerson = a.createIndividual("aulo:Person", "rbproto:George"));     // create a new Person instance named "George"
Individual acInst  = a.getAcuityControllerInstance( );                                // the Individual representing this instance of AcuityController
a.tell(acInst, p, newPerson);                                                                     // tell the controller that the it hasUser George (the new person)

Note that the methods tell and addStatement are identical in function.

While telling is always in the form of the assertion of an RDF triple, asking has two forms. The first is through pattern matching. When any of the property (predicate), the subject, and the object of an RDF triple expression is set to null, pattern matching will be used to return all statements in the knowledge base, asserted or inferred, which match the query expression. For example, to ask for all of the individuals of type Person, one would make the following call:

AcuityController a = ...;
Iterator iter  = a.getMatchingStatements(null, "rdf:type", "aulo:Person");
while (iter.hasNext( )) {
    System.out.println(((Statement)iter.next( )).getSubject( ).getLocalName( ) + " is a Person");
}

Note that the method getMatchingStatements is identical to the ask method. Thus to ask for all of the instances of things related in any way to the AcutiyController instance ac1 (ac1 as the subject), along with the kind of relationship:

AcuityController a = ...;
Iterator iter  = a.ask(a.getAcuityControllerInstance( ), null, null);
while (iter.hasNext( )) {
    Statement s = (Statement)iter.next( );
    System.out.println("ac1," +  s.getPredicate( ).getLocalName( ) + ", " + s.getObject( ).toString( ));
}

The AcuityController also supports the SQL-like RDF query language RDQL. In RDQL, the two queries above (omitting namespace information) would be:

SELECT ?s WHERE (?s, <type>, <Person>)

SELECT ?p, ?s WHERE (<ac1>, ?p, ?o)

The real reason for using RDQL is to enable much more complex queries. For example, the following query in a geneology ontology finds everyone's aunt :

SELECT ?c, ?a WHERE (?c, <http://camfe.org/FamilyThreads/family.owl#hasParent>, ?p), (?p, <http://camfe.org/FamilyThreads/family.owl#hasParent>, ?gp), (?gp, <http://camfe.org/FamilyThreads/family.owl#hasChild>, ?a), (?a, <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>, <http://camfe.org/FamilyThreads/family.owl#Woman>) AND ! (?a eq ?p)

This expression says find all of the children (c) who have a parent (p) who in turn have a parent (gp) who in turn have a child (a) who is a Woman and who is not a parent (p) of the child (c).

Problem/Vantage/Frame Ontology at First Glance

While our approach to implementing the Problem/Vantage/Frame approach is discussed in greater detail in a later section of this document, a brief overview may be helpful in understanding the material preceding that detail. The AcuityController as a concept (owl:Class) is found in the apvf ontology, and each client session will instantiate an instance of this class. The Frame class is the highest-level container of the user-interface--it roughly corresponds to a session. A Vantage is the next level user-interface class. A Vantage represents a particular point-of-view. Each Frame instance can contain one or more Vantage instances. The apvf ontology assumes that only one Vantage will be the focus of attention at any given time--the focus Vantage.

Besides Frames and Vantages, the apvf ontology identifies two other classes of user-interface objects. InteractionObjects display information to the user, either as a menu or a text input box, and allow the user to send an "answer" back to the AcuityController. DisplayObjects only display information without any interaction possibility. A Vantage or Frame can contain any number of of InteractionObjects and DisplayObjects. Frame, Vantage, InteractionObject, and DisplayObject are all subclasses of PresentationObject. By ontological restriction, a Frame or Vantage class can be defined so that it must contain certain kinds of PresentationObjects within it.

Specifying Procedural Behavior using AcuityController Actions

Ontologies are very declarative in nature, meaning that they define what exists structurally but do not easily represent behavior. The AcuityController, in conjunction with the Problem/Vantage/Frame ontology (http://research.ge.com/Acuity/apvf.owl), implements some useful behaviors. These behaviors are grouped in two categories: 1) missing Properties, and 2) new Individuals.

What is a Missing Property

Missing Properties is the name we give to an inconsistency between the necessary conditions imposed by Restrictions on an OWL Class and an actual instance (Individual) of that Class. For example, our ontology might define the Class Mother as a Woman with a someValuesFrom restriction on the Property hasChild, which in turn has as range the class Person. If the instance data declares that Jane is an instance of the Class Woman but upon querying the ontology we find that Jane has no hasChild Properties, we may conclude that Jane has a missing Property (hasChild) with range Person. In the Problem/Vantage/Frame ontology, a Frame has necessary conditions that require it to have a focus Vantage (apvf:hasFocusVantage Property) and a VantageSelectionObject related to the Frame by an apvf:containsPresentationObject Property.

A Class definition in an ontology may include a Restriction that a particular Property must have someValuesFrom a particular range Class, or it may include a Restriction that  a particular Property has a cardinality greater than or equal to one or a minCardinality greater than or equal to one. When one or more of these Restrictions is included in the Class definition and an Individual of that Class exists but no Statement with that Individual as subject and the particular Property as predicate is found in the ontology, we refer to the situation as the Individual having a "missing Property". 

What to Do When an Expected Property is Missing

The missing Properties of a particular Individual or those of all Individuals in the ontology can be found by calling the AcuityController method getMissingProperties. The returned value will be null if no missing Properties are found or a List of InteractionContent structures (see Javadoc for details). Each InteractionContent instance in the List identifies, among other things, the subject (Individual), the predicate (missing OntProperty), the type of Restriction encountered which implies the missing Property along with the Class or Classes to which the object of the missing Statement must belong (which we shall loosely call range), and cardinality information.

The AcuityController identifies three basic types of actions that can be taken in the event of a missing Property:

  1. Automatically create a new Individual of the Class identified as the range of the missing Property. This behavior is accomplished by making the Property of the Restriction or cardinality constraint an rdfs:subProperty of apvf:autoInstantiateProperties. This will only work if the range of the restricted Property is a single Class. If the missing Property is sub typed in this way and the range includes multiple Classes an AcuityException will be thrown.
  2. Execute a user-defined procedure expressed as a Java method on a Java class. The procedure is fully identified by an Individual of type apvf:MissingObjectPropertyAction, which has Properties identifying the package, class name, and method name. The implementation method must take four arguments of type AcuityController, IndividualImpl, ObjectPropertyImpl, and OntClassImpl, which will be, when passed at runtime, the Java instance of the AcuityController doing the processing, the subject Individual, the predicate Property, and the range Class of the missing ObjectProperty. The method may return a List containing the URIs of the Individuals which can be the object of a new ObjectProperty and/or the OnDemandActions which can be taken. OnDemandActions are discussed below.
  3. Ask the user to identify an Individual to be the object of a new Statement with the the Individual missing the Property as subject and the missing Property as predicate. If the class has a hasValue Restriction on Property hasAskUserRDQLValueFilter, the value (an RDQL query string) will be used to generate the List of possible answers, presumably a subset of the Individuals which are of the type(s) identified by the range. If there is no such hasValue Restriction on hasAskUserRDQLValueFilter, all Individuals that are of the type(s) specified by the range of the Property will be identified as possible answers by calling the AcuityController method addPossibleAnswerURIs. Any Property which is a subProperty of the Property apvf:askUserPropertiesIncludeCreateNew, e.g., apvf:hasFrame, will, when it the predicate of a missing Property which is to be asked,  included the create new action by default in the list of possible answers. If the special instance (Individual) of class apvf:OnDemandAction named apvf:createIndividualOfRangeClass (see below) is associated with the Class by a hasValue Restriction it will also be included in the List.

OnDemandAction, MissingPropertyAction, and InstanceCreationAction are each an owl:subClass of AcuityControllerAction in the apvf ontology.  All AcuityControllerActions identify a Java static method in a specified package and class that implements the action. An OnDemandAction implementation method must have two arguments of type AcuityController and Object[], which will be this instance of the AcuityController followed by an array of arguments to the action. The second argument, if not an empty array, is expanded to form additional arguments to the method. The method has no return value (is void). OnDemandActions are associated with a Class as a hasValue Restriction on the Property apvf:hasOnDemandAction. Note that a special instance of OnDemandAction defined in the http://research.ge.com/Acuity/apvf.owl ontology and known explicitly to the AcuityController is the Individual apvf:createIndividualOfRangeClass. This individual doesn't actually have any Java code associated with it but makes available as an OnDemandAction the same Individual creation functionality identified as the "automatic creation," described in the first item in the list above.

Action when a New Individual is Created

When a Class has a hasValue Restriction on the apvf:hasInstanceCreationAction (which will necessarily have a value which is an Individual of type apvf:InstanceCreationAction), the Class is given a behavior defined by this value. In particular, the behavior is invoked whenever a new Individual which is an instance of this Class is created.

Of course the creation of a new Individual can result in new missing Properties and so lead to additional behavior through the mechanisms described above.

Summary of Action Classes and Properties

The figure below shows the AcuityControllerAction Class and its three subclasses representing the three basic types of action supported along with usage information.

 

Class Static Method Arguments and return type Description
InstanceCreationAction 1) this instance of AcuityController
2) the IndividualImpl newly created
3) the OntClassImpl of the Individual newly created
Method is void (does not return anything)		 The static method is called when the instance (Individual) of this class is the value of a hasValue Restriction on a hasInstanceCreationAction Property on a given Class of which a new instance (Individual) has just been created.
MissingObjectPropertyAction 1) this instance of AcuityController
2) the Individual which is the subject of the missing Statement
3) the OntProperty which is the missing Property
3) the OntClass which is the range of the object of the missing Statement
Method returns a List of possible object values and actions or null.		 The static method is called when the instance (Individual) of this class is the value of a hasValue Restriction on a hasMissingObjectPropertyAction Property on a given Class which is the range of the object of a missing Property. Note that this method may be executed multiple times. In particular, execution will be triggered when the subject of the missing Statement is the target of a getMissingProperties call. It will also be triggered when the subject of the missing Statement has just been created.
Note: if the method returns a non-null List, the MissingPropertyInfo instance passed back on a call to getMissingProperties will have the askUser flag set to true indicating missing Property is "askable." 
OnDemandAction 1) this instance of AcuityController
2) an array of type Object[] (which can be null) containing any additional arguments to be passed to the method by the application.
Method returns Object, which is passed back to the client application.		 The static method may be called by the client application by calling the AcuityController method processOnDemandAction(String actionURI, Object[] addlArgs). Alternatively, since OnDemandAction instances may be included in the list of possibilities for an askable missing Property, a call to processMissingPropertyAnswer(MissingPropertyInfo mpi, String actionURI, boolean bRemember) will be detected as an action rather than the object of a new Statement providing the missing Property allowing client applications to not need to distringuish between answers and actions. In this case the additional arguments to the method will be null.

            Types of AcuityControllerAction and Details of Usage
        

The table below lists the action-related Properties defined in the apvf (http://research.ge.com/Acuity/apvf.owl) ontology. The namespace is omitted in the table.

Property Name Summary of Usage
askUserProperties When an ObjectProperty is made a subProperty of this Property, discovery of a missing Property of the subProperty type will result in a "suggestion" to the client that the user should be asked for the object (Individual of range Class) to be used in a new Statement with predicate matching the subProperty and object the user-specified Individual.
askUserPropertiesIncludeCreateNew  When an ObjectProperty is made a subProperty of this Property, any list of Individuals offered to the user as options for a missing Property will include the "action" option of creating a new Individual to be the object of a new Statement matching the missing Property, i.e., a new Individual with type being the Class which is the range of the subProperty. (Note: this Property is a subProperty of askUserProperties above.)
hasAskUserRDQLValueFilter  When a Class has a hasValue Restriction on this Property, the String value is used as an RDQL query string to generate the list of Individuals which can be objects in the missing Statement.
autoInstantiateProperties When an ObjectProperty is made a subProperty of this Property, discovery of a missing Property of the subProperty type will result in  automatic creation of a new Individual of the range Class which will be used as the object of a new Statement with predicate matching the subProperty and object the new Individual.
hasAction  The range of this ObjectProperty is the Class AcuityControllerAction, which has DatatypeProperties identifying the package, class, and static method name of a Java procedure to be executed when the appropriate conditions, determined by subProperty distinctions, are met. The subProperties of this Property are the Properties actually instantiated in an application ontology, i.e. instances of hasInstanceCreationAction, hasMissingObjectPropertyAction, and hasOnDemandAction.
hasInstanceCreationAction  (subProperty of hasAction) When a Class has a hasValue Restriction on this Property, the Individual of type InstanceCreationAction which is the value defines the action to be taken as a side effect when a new Individual of the Class is created.
hasMissingObjectPropertyAction  (subProperty of hasAction) When a Class has a hasValue Restriction on this Property, the Individual of type MissingObjectPropertyAction which is the value defines the action to be taken when the Class is in the range of the missing Property.
hasOnDemandAction  (subProperty of hasAction) When a Class has a hasValue Restriction on this Property, the Individual of type OnDemandAction which is the value defines an action which is available as a user-invoked action.
includeAsMissingPropertyOption  When an Individual of type OnDemandAction includes a hasValue Restriction on this Property with value true, the Individual is included in the List of possible answers given to the client for an "askable" missing Property.

Action-Related Properties of the Acuity Problem/Vantage/Frame Ontology

Implementation of the Problem/Vantage/Frame Paradigm

PresentationObjects

Presentation Objects (POs) populate a Vantage and stand between the raw data and the presentation. It is useful to distinguish between POs used to display information to the user, such as a graph of one or more data series, and POs used to obtain information from the user and pass it to the AcuityController. This gives rise to two subclasses of PresentationObject: 1) DisplayObject (DO) and 2) InteractionObject (IaO). In the former case, a particular Vantage type will have certain DOs which will be associated with certain data sources (WorkDomainInformationObjects or WDIOs). A flexible implementation might allow a user to add additional DOs with their associated WDIOs to a Vantage. In the latter case, an IaO maps user input to possible assertions and/or deletions of RDF triples or to actions (see discussion of actions above). An IaO can be created from a InteractionContent Java class instance, which defines the data content of the IaO. Independent of any missing properties, IaOs may also be associated with a Vantage enabling the user to assert some Statement or set of Statements, such as [instanceOf AcuityController, hasFrame, instanceOf  Frame], at any time.

The apvf:Frame and apvf:Vantage classes themselves are also types of apvf:PresentationObject. The ObjectProperty apvf:containsPresentationObject has apvf:PresentationObject as both its domain and range and is inverse functional. In other words, every PO can contain any number of POs, but a PO can only be contained by (inverse Property apvf:isContainedByPresentationObject) a single PO. A partial hierarchy of InformationObjects in the Problem/Vantage/Frame ontology, including apvf:PresentationObject and some of its subclasses, are shown in the figure below.

The mapping between WDIOs and DOs captured by the ObjectProperty apvf:isEncodedBy, which has domain apvf:WorkDominInformationObject and range apvf:InformationObject. Its inverse Property is apvf:encodes. For example,  the class apvf:CachedRowsetDataTable has a hasSomeValuesFrom restriction on the apvf:encodes Property with range apvf:LegacyRelDataSet or apvf:StoredProcedure. In other words, an rowset returned from a relational database by an SQL query or a stored procedure can be encoded and therefore displayed in an instance of an apvf:CachedRowsetDataTable. As a more complex example, an apvf:GraphObject contains one or more apvf:DataSeries, which in turn encode an apvf:LegacyRelDataSet or an apvf:StoredProcedure.

Presentation Parameters

Presentation Parameters are those characteristics of PresentationObjects used by the user-interface to achieve an actual display. Presentation Parameters include things like Position (xPos, yPos, zOrder, etc.) and DisplayType (ListBox, DropdownListBox, etc.). Some Presentation Parameters are associated with a PresentationObject by DatatypeProperties, e.g., apvf:allowsMultipleSelection with range xsd:boolean. Other Presentation Parameters are "composite" in that the values are themselves Individuals of type Parameter associated by an ObjectProperty with the PresentationObject and with "indirect" DatatypeProperty values. The owl:Class Position is an example of a composite Parameter. The x and y coordinates (xPos, yPos), the zOrder, the height, width, and depth of a PresentationObject are aggregated together into an instance of Position. Thus for a given PresentationObject "myPO", the following Statements might exist (in pseudo-syntax):

<#myPO>, <apvf:hasPosition>, <#myPOsPosition>
<#myPOsPosition>, <apvf:xPos>, 321
<#myPOsPosition>, <apvf:yPos>, 452
<#myPOsPosition>,<apvf:zOrder>,0

There are two reasons why values of DatatypeProperties might be aggregated together to form composite or indirect parameters. The first is for convenience of organization, the reason for creating the <apvf:hasPosition> ObjectProperty with range Position. The second, and more compelling, is in order for PresentationObjects to persistently share parameters. The value of a DatatypeProperty is not a uniquely identified element of an OWL ontology and therefore cannot be shared between PresentationObjects. Rather the value, e.g., true for the apvf:allowsMultipleSelection, would be saved with each instance of the modified PresentationObject and there would be no way to represent (and remember) that the two POs have the value in common. A good example of this is the class apvf:Color, the range of the apvf:hasColor Property. It is quite conceivable that in some kind of brushing operation (highlighting the same data in multiple views), two POs might want to use the same Color. The RDF statements below would result:

<#myPO1>, <apvf:hasColor>, <#aColor>
<#myPO2>, <apvf:hasColor>, <#aColor>
<#aColor>,<blueVal>,<0>
<#aColor>,<greenVal>,<0>
<#aColor>,<redVal>,<255>

Now <#aColor> might be changed by changing it's DatatypeProperties, but the two POs will continue to share that same Color, whatever it becomes. For more information about when a composite  is changed directly and when a copy is made and then changed, see the discussion of Default Values below.

Note that while some parameters are single-valued (functional), as were the examples above, others can be multi-valued. A good example is the HighlightRegion class. A Graph2D type DisplayObject instance might have multiple instances of the composite Parameter HighlightRegion. Thus the apvf:hasHighlightRegion can have multiple values (objects) for a given PresentationObject (subject). The composite HighlightRegion has Parameter apvf:hasSlice with Range Slice. Slice in turn has as its Parameters the xsd:float values loThreshold and hiThreshold as well as hasColor. This suggests Statements similar to the following (in pseudo-syntax):

<#my2DGraph>, <apvf:hasHighlightRegion>, <#hlr-1>
    <#hlr-1>, <apvf:hasSlice>, <#slice-1>
        <#slice-1>, <apvf:loThreshold>, 0
        <#slice-1>, <apvf:hiThreshold>,100
        <#slice-1>, <apvf:hasColor>, <apvf:blue>
<#my2DGraph>, <apvf:hasHighlightRegion>, <#hlr-2>
    <#hlr-2>, <apvf:hasSlice>, <#slice-2>
        <#slice-2>, <apvf:loThreshold>, 200
        <#slice-2>, <apvf:hiThreshold>,300
        <#slice-2>, <apvf:hasColor>, <apvf:red>
<#my2DGraph>, <apvf:hasHighlightRegion>, <#hlr-3>
    <#hlr-3>, <apvf:hasSlice>, <#slice-3>
        <#slice-3>, <apvf:loThreshold>, 500
        <#slice-3>, <apvf:hiThreshold>,600
        <#slice-3>, <apvf:hasColor>, <apvf:yellow>

For more details on using SharedCompositeParameterSets to accomplish effects such as data brushing, see The SharedCompositeParameterSet.

PresentationParameterMap

The PresentationParameterMap Java class is a helper to the AcuityController class. For a given PresentationObject, a call to getPresentationObjectParameters returns an instance of the class PresentationParameterMap. Each PresentationParameterMap contains a subject (Individual of type PresentationObject or Parameter) and a Hashtable containing key/value pairs. (Actually, PresentationParameterMap extends java.util.Hashtable so the Hashtable behavior is entirely inherited.) Each key is a predicate (OntProperty) with the namespace removed and each corresponding value is an instanceOf one of the following:

Relating this to the example of multiple HighlightRegions above, the PresentationParameterMap returned by getPresentationObjectParameters("#my2DGraph") has subject "#my2DGraph" and a key "hasHighlightRegion" (and perhaps others). The value of this key is a PresentationParameterMap[] of size 3 whose elements have subjects "#hlr-1", "#hlr-2", and "#hlr-3", respectively. Each of the three PresentationParameterMaps will have the two keys "xMin" and "xMax" with the associated Literal values (0,100), (200,300), and (500,600).

The AcuityController provides a convenience method to get Statements reflected in a PresentationParameterMap:

    StmtIterator getMatchingParameters(PresentationParameterMap ppm, String propLocalName)

The StmtIterator allows access to the set of Statements which are associated with the first match of a key with propLocalName in the map or a sub-map. Note that only Statements associated with the first match is returned. If multiple matches exist in the map or its sub-maps, they will not all be returned.

The PresentationParameterMap class itself also has a convenience method for getting information from maps/submaps. Unlike the AcuityController's getMatchingParameters(..), this method does not query the ontology but returns just what is currently found in the map. This method's signature is:

    Hashtable getMatchingParameters(String propLocalName)

The returned Hashtable has subjects as keys and non-map objects as values for all entries matching the input predicate and not having an object which is a map--in other words, the map is "flattened."

Setting Parameters

The AcuityController provides a convenience method for setting/updating PresentationParameterMaps and the underlying ontology simultaneously:

    boolean updatePresentationParameterMap(PresentationParameterMap ppm, String propLocalName, Object newVal)

The PresentationParameterMap (ppm) is normally retrieved from an InteractionObject. The newVal argument can be a String which names an Individual, a String which may be converted to a number or a boolean value, or an Integer or Boolean. In any case, the newVal will be converted either to an Individual for an ObjectProperty or to a Literal for a DatatypeProperty. If the propLocalName identifies a DatatypeProperty, the rdfs:range will be retrieved and newVal will be validated. Invalid types will cause an AcuityException to be thrown.

InteractionObjects, Extended RDQL (xRDQL), and Anchors

Since an IaO provides a mechanism for the user to modify the knowledge base of the AcuityController, it can be thought of as providing access to a set of insertions, deletions, or updates of RDF triples in the ontology's instances namespace (aBox). Unfortunately, RDQL has not been extended to support INSERT, DELETE, and UPDATE, although the need has been recognized. The AcuityController implementation must assume such an RDQL extension, and uses the following syntax: 

Some assumptions are required to implement these additional operations.

  1. An INSERT will generally add new triples. However, to make use easier (require less knowledge on the part of the author of a statement) an INSERT of a triple which would result in a cardinality violation will have the effect, where possible, of doing an UPDATE.
  2. An UPDATE will only succeed where there is no triple or there is a single triple already existing that matches the UPDATE pattern. The first case is supported to require less knowledge on the part of the statement author. In the case of an existing triple, that triple will be removed and a new triple added with the new information. If there are multiple triples that match the pattern, which one to update is ambiguous and an AcuityException will be thrown.
  3. A DELETE maps to the Jena removeAll(Resource s, Property p, RDFNode o), which removes all matching Statements and which allows one or more of the arguments to be null to indicate that any value of that argument will match. Rather than "null", an unbound variable, e.g., ?x, may be placed as the unconstrained argument.
  4. Any subject, predicate, or object in a triple of an INSERT, DELETE, or UPDATE may contain an RDQL SELECT statement. Since the SELECT itself may have any number of comma-separated triples, it is wrapped in square brackets to make its extent easier to parse. If the RDQL SELECT returns multiple values, the INSERT, DELETE, or UPDATE will be done only for the value which the user identifies from the set (implying an interaction with a menu of choices).

Note that the SELECT used for the subject, predicate, or object of the triple, as described in #4 above and which is enclosed in square brackets, can be a conjuncion (union) and/or a difference of the form:

    [SELECT ... PLUS SELECT ... MINUS SELECT ...]

This is supported because the limitations of the RDQL SELECT make it otherwise difficult to combine and/or reduce a set of possible answers, e.g., provide a list of possible answers which are all of the POs in a Frame except those POs in the current Vantage.

In addition to adding INSERT, DELETE, and UPDATE to our extended RDQL (xRDQL), we need, in order to implement IaOs, someway of "anchoring" at design time the value of a subject or object at runtime. The ontology as designed identifies primarily the Classes of things that exist in the problem/vantage/frame implementation or in the work domain. It is usually not until the AcuityController is used that Individuals belonging to these Classes are created, and it is these runtime Individuals which serve as subjects and objects of RDF triples in the knowledge base. To facilitate this anchoring, the owl:Class apvf:InteractionAnchor is created. It has Individuals "self", "currentAC", "currentFrame", "currentUser", "focusVantage", and "containingPO". (The anchors "useRange" and "useAnswer" are special cases used in the apvf:hasEffect of IaO's as described below.) Note that the syntax is to place ${...} around the anchor in the query string.

To relate xRDQL expressions to a particular subclass of IaO, the DatatypeProperty apvf:hasEffect is implemented with domain apvf:InteractionObject and range xsd:String. An IaO may have multiple hasEffect properties, but the order of execution is not guaranteed. Therefore, any statements which are order-dependent should be placed in a single hasEffect value. The syntax of the value is simply a series of semi-colon-separated INSERT, DELETE, or UPDATE statements.

The following examples are meant to clarify the use of xRDQL and IaOs and to illustrate the usage of members of the InteractionAnchor Class as subjects and objects.

  1. An apvf:FrameSelectionObject, subclass of apvf:SelectionListPresentation which is a subclass of apvf:InteractionObject, is meant to allow the user to switch to another apvf:Frame or create a new one at any time. The Class is therefore given the necessary restriction that the Property hasEffect has value:
        
        UPDATE (${currentAC}, <apvf:hasFrame>, ${useRange})

    At runtime, the subject "${currentAC}" is replaced with the Individual that is the ontology instance of the current AcuityController. The object is the user's selection from the set of possibilities. (The "${userRange}" is initially processed to determine the set of possible answers and then replaced with "${useAnswer}" when the client returns a value.) This set is generated exactly as described above for missing properties: the eligible frames are defined by the apvf:hasAskUserRDQLValueFilter DatatypeProperty on Frame, if there is one, and the option of creating a new Frame is included because "hasFrame" is an rdfs:subPropertyOf askUserPropertiesIncludeCreateNew.
  2. An aePresentation:FleetSelectionObject is meant to allow the user to select an apvf:Fleet instance and make it the current Fleet of the current Frame. The aePresentation:FleetSelectionObject Class has the Property apvf:hasEffect with value:

        UPDATE (${currentFrame}, <aePresentation:hasCurrentFleet>, ${useRange})

    In this case the Fleet Class does not have any special Properties but since "hasCurrentFleet" has the Class Fleet as range, all instances of Fleet are in the set from which the user selects. The user's selection is the object of the updated RDF triple.
  3. The previous example is reexamined without the use of "currentFrame" and "useRange" to illustrate the use of RDQL SELECT statements. The value of the hasEffect could be:

        UPDATE ([SELECT ?frame WHERE (${currentAC}, <apvf:hasFrame>, ?frame)], <aePresentation:hasCurrentFleet>, [SELECT ?fleet WHERE (?fleet, <rdfs:type>, <apvf:Fleet>)])
  4. The aerf:HighlightEngineSelection allows the user to select a different engine with the desired side-effect of changing to the EngineDetail Vantage with the new Engine. The hasEffect value is:

        UPDATE (self, <aerf:hasEngine>, [SELECT ?engine WHERE (${focusVantage}, <aerf:hasFleet>, ?fleet), (?fleet, <apvf:hasMember>, ?engine)]); 
        UPDATE (${currentFrame}, <apvf:hasFocusVantage>, [SELECT ?vantage WHERE (?vantage, <rdfs:type>, <aerf:EngineDetail>), (${currentFrame}, <apvf:hasVantage>, ?vantage)])

    The first UPDATE allows the user to choose an Engine from those which are members of the current Fleet and associate it with the current ??. The second UPDATE changes the focus Vantage. Note that when a statement has a single object, as the second is expected to, the UPDATE is made automatically without user interaction.

The pre-defined anchors which can be used in an extended RDQL statement (Individuals of Class apvf:InteractionAnchor) are summarized in the following table:

Anchor Identifier Will be Replaced With
self The URI of the Individual which is the current InteractionObject
currentAC The URI of the Individual corresponding to the current AcuityController
currentFrame The URI of the Individual which is the current Frame associated ("hasFrame") with the current AcuityController
currentUser The URI of the Individual which corresponds to the current user
focusVantage The URI of the Individual Vantage which has the focus
containingPO The URI of the Individual PresentationObject which contains the current InteractionObject
useRange "useAnswer" after the set of possibilities is set from the Class which is the range of the Property having this object.
useAnswer The URI of the Individual which has been designated in the interaction as the answer
now The current date/time

The concept of anchors is made extensible through the Class apvf:InteractionAnchor, which must have DatatypePropery rdqlQueryString for non-built-in anchors. The results of the anchor query are used in the referencing query. For example, an instance of apvf:RDQLAnchor with name "aerf:currentFleet" can be created with associated query:

SELECT ?fleet WHERE (${currentFrame}, <aerf:hasCurrentFleet>, ?fleet)

Now a query to get all of the Engines in the currentFleet could be written:

SELECT ?engine WHERE (${currentFleet}, <apvf:hasMember>, ?engine)

Note that anchors can also be used in the SQL statements which are the values of the apvf:dbSQLString DatatypeProperty of the apvf:LegacyRelDataSet Class and in the apvf:storedProcedureSignature DatatypeProperty of the apvf:StoredProcedure Class. This allows SQL queries and stored procedure arguments to use specified runtime substitutions. For example, using the definition of the anchor "currentFleet" given above, an SQL query might be written as:

SELECT ESN FROM Engines WHERE Fleet = '${currentFleet}'

The results of an anchor's RDQL query may be referenced by name, as would be necessary if the query returned multiple variables. For example, if the currentFrame had a "hasCurrentEngine" as well as hasCurrentFleet, the anchor "currentFleetAndEngine" might be defined as:

SELECT ?fleet, ?engine WHERE (${currentFrame}, <aerf:hasCurrentFleet>, ?fleet), (${currentFrame}, <aerf:hasCurrentEngine>, ?engine)

Then an SQL query using this anchor to get the engine's hours and the owning Fleet's contact might look like:

SELECT hours, OwnerContact FROM Engines, FleetContacts WHERE ESN = '${currentFleetAndEngine:engine}' AND Fleet = '${currentFleetAndEngine:fleet}'

InteractionObjects and Missing Properties

An InteractionObject instance can be created because a particular Vantage (or other containing PO) has an IaO associated with it at the abstract Class level or because an askable missing Property is associated with the InteractionObject. This latter association is a bit problematic in the sense that it is perhaps most logical to associate the IaO with the Property which is missing and askable. However, using a Property as the Subject or Object of an RDF Statement would make the ontology OWL Full rather than the desired OWL DL. Therefore, we associate the IaO with the Class which is the range of the missing Property using a Restriction on the apvf:hasInteractionObject ObjectProperty.

Default Values, Specified and Learned

OWL does not currently support default values. Default values introduce non-monotonic reasoning and can significantly increase an application's complexity. However, there are times when the availability of default values for initializing a new Individual as the object of an ObjectProperty or Literal as object of a DatatypeProperty is very useful. One way to provide default values is through the use of InstanceCreationActions, as described above. This approach requires writing some Java code, the action, as well as adding the action to the ontology. The AcuityController provides another way of implementing default values that involves only additions to the ontology and supports learned default values.

It is desirable to be able to set a default value for a given Property on new Individuals of a given class. Associating this information with the Property is not possible in OWL DL as Properties cannot be reified in the ontology so that they can have their own Properties. Furthermore, this approach would make the default value information visible to other OWL reasoners and since there is currently no standard, might affect their behavior in undesirable ways. Even if making the ontology OWL Full were acceptable, the current tools ontology editing, e.g., the Protege OWL plugin, are geared toward OWL DL ontology development.

Classes (and Properties) in OWL can have one of several "annotation properties" including rdfs:comment and rdfs:label. Another annotation is called rdfs:seeAlso, which "is used to indicate a resource that might provide additional information about the subject resource" ("RDF Vocabulary Description Language 1.0: RDF Schema," http://www.w3.org/TR/rdf-schema/).  In this instance, we wish to do exactly that--provide additional information that will be used by the AcuityController. We create an apvf:Refining subclass called apvf:DefaultValue with subclasses apvf:ObjectDefault, apvf:IntegerDefault, apvf:BooleanDefault, etc. The subclasses (apvf:ObjectDefault, apvf:IntegerDefault, apvf:BooleanDefault, etc.) have apvf:hasObjectDefault (ObjectProperty), apvf:hasIntDefault (DatatypeProperty), apvf:hasBooleanDefault (DatatypeProperty), etc., respectively, with range Individual, xsd:int, xsd:boolean, etc. These associations allow the specification of the value of the default.

The simplest use of an apvf:DefaultValue instance is as the object of an rdfs:seeAlso annotation on a Property. This usage implies that this is always the default value when the Property occurs.

A more fine-grained use restricts application of the default to triples whose subject comes from a specified class. The apvf:DefaultValue class is the domain of the apvf:appliesToPropertyWithName DatatypeProperty (range xsd:string), which will have as value the name of the Property to receive the default value. With this set of Classes and Properties, we can now add an rdfs:seeAlso annotation to any Class and specify the default for a given Property. For ObjectProperties, the value of the annotation will be an Individual of type apvf:ObjectDefault. For DatatypeProperties, the value of the annotation will be an Individual of the class corresponding to the Property's range, e.g., IntegerDefault. In either case, the apvf:appliesToPropertyWithName value will be the name of the Property to receive the default value and the other Property (e.g., hasIntDefault) will provide the actual default value.

As an example, we wish the apvf:InteractionObject subclass apvf:FrameSelectionObject to have as default value of apvf:hasPresentationNature the Individual "ListBox", an instance of the class apvf:DisplayType. We create an rdfs:seeAlso annotation with object an instance of ObjectDefault with apvf:appliesToPropertyWithName value "apvf:hasPresentationNature" and apvf:hasObjectDefault value apvf:ListBox.

Note that one undesirable characteristic of this approach is that the apvf:appliesToPropertyWithName value is not a direct link to the actual Property to receive the default value but only an xsd:string which must match the Property's name. Consequently, if the name of the Property is changed, this xsd:string value must be edited as well to keep it synchronized with the actual Property name. Of course when it is sufficient to associate a default value with the Property alone--the default will be the same regardless of the class to which it is applied--the rdfs:seeAlso annotation is applied to the Property instead of the Class and apvf:appliesToPropertyWithName is not used.

As an example of an rdfs:seeAlso on a Property, the apvf:hasRowsetMaxRows Property has domain apvf:CachedRowsetDataTable and specifies the maximum number of rows to request from a legacy relational database table (so that if the actual number of rows is enormous the application will not stop responding). By creating an rdfs:seeAlso annotation on apvf:hasRowsetMaxRows with value an instance of apvf:IntegerDefault with apvf:hasIntDefault value 150, the AcuityController is provided with a default value that can be used to initialize the apvf:hasRowsetMaxRows Property on any Individual that it creates.

All instances of apvf:DefaultValue may have the additional DatatypeProperties apvf:thresholdFrequency and/or apvf:minimumSampleSize. The first, if present, indicates that the AcuityController should look at the historical instance data to see if some value has occurred frequently enough to be used as the default. If so, this learned default will be used instead of the specified default. The threshold frequency is expressed as a decimal fraction, e.g., 0.60 meaning this value occurred at least 60% of the time. The second Property, if present, indicates a minimum number of observations necessary before the learned default will be used. For example, if apvf:minimumSampleSize is 20, then at least 20 historical instances must be in the histogram before the learned default, assuming the threshold is met, will be used. If apvf:minimumSampleSize is specified but apvf:thresholdFrequency is not specified, as soon as the sample size requirement is met the most common historical value will be used as the default regardless of frequency. In the case of ties, the choice among the top contenders will be arbitrary.

More specifically, the histogram of values from which a learned default value of a given Property ("thisProperty") for a given Individual ("thisInstance") translates into the following RDQL query:

SELECT ?x WHERE (<URI of thisInstance>, <rdf:type>, ?instType), (?otherInst, <rdf:type>, ?instType), (?otherInst, <URI of thisProperty>, ?x)

This returns all of the values which "thisProperty" has been given for all Individuals of the same rdf:type as the current subject Individual. These values can be Individuals (ObjectProperties) or Literals (DatatypeProperties). 

The default value created by the RDQL query above is learned from all Individuals of the same rdf:type regardless of who (which user) generated the instances. Obviously this approach cannot learn user preferences. To handle user preferences we must restrict the learned value to those Individuals of the same rdf:type that were created by the current user. A more general user-based learned value could, say in the absence of sufficient data for a [new] user, look at preferences of users of the same rdf:type, e.g., other planners. Some thought is needed as to the meaning of "users of the same rdf:type." Certainly, all users have the same type at the owl:Thing level. Our approach is to expand the user restriction to all users who share some Property or Properties with the current user, e.g., hasSkill. 

The RDQL queries for these two situations (this user and the set of users sharing the Property apvf:hasSkill with this user) are, respectively:

SELECT ?x WHERE (<URI of thisInstance>, <rdf:type>, ?instType), (?otherInst, <rdf:type>, ?instType), (?otherInst, <apvr:hasUser>, currentUser), (?otherInst, <URI of thisProperty>, ?x)

SELECT ?x WHERE (<URI of thisInstance>, <rdf:type>, ?instType), (?otherInst, <rdf:type>, ?instType), (?otherInst, <apvr:hasUser>, ?u), (?u, <apvf:hasSkill>, ?skill), (currentUser, <apvf:hasSkill>, ?skill), (?otherInst, <URI of thisProperty>, ?x)

This gives rise to two more optional DatatypeProperties on instances of apvf:DefaultValue: 1) apvf:userPreference with range xsd:boolean, and 2) apvf:userGroupDefinedBy with range xsd:string. A value of true for apvf:userPreference causes the search for a learned value to begin with the target Property for Individuals of the same owl:Class with the same value of apvf:hasUser as the current subject. 

If the threshold or sample size conditions for an apvf:DefaultValue with apvf:userPreference true are not met, one of two things will happen. If there are no apvf:userGroupDefinedBy Properties on the default, the specified default will be used. However, if one or more values of apvf:userGroupDefinedBy are present, the values are used to identify a set of users with the same values of the specified group Properties and a learned default is sought from the Individuals of the subject type and owned by this group of users. This causes the set of users to be expanded from the current user to all users who share the named Property or Properties with the current user. Because apvf:userGroupDefinedBy can be multi-valued (is not functional), the user group from which the value is learned can be restricted by more than one shared Property. If this set does not meet the threshold or sample size conditions, the specified default value is used.

As a final degree of flexibility in setting default values, the RDQL query used to identify the members of the histogram can be explicitly given as the value of the DatatypeProperty learningSetQuery (range xsd:string). The query should have a single selected variable, like the ?x in the three examples above, and should return a set of Individuals or Literals. 

Note that apvf:userGroupDefinedBy and apvf:learningSetQuery are not implemented at this time (4/7/2005).

Learned defaults, particularly user preferences, are useful for editable Parameters. However, some Parameters, like apvf:Position and apvf:Color, are composite Parameters meaning that the Parameter value is an Individual which in turn has sub Parameters which are Literals. To learn a default value for a composite Parameter, we do not necessarily want to compare the various Individuals (the instance of Color or Position), but rather look at their sub Parameters.

Namespaces are used to determine when a complex Parameter can be re-used and when it must be duplicated. It is important that DefaultValues be defined in a namespace other than that of the instance data. When a complex Parameter has a value, i.e., a default value, which is an Individual from a namespace different from the instance data, and a call is made to the AcuityController to update that value in the PresentationParameterMap, the value is cloned, the clone is substituted for the original in the ontology and the map, and the changes are applied to the clone.

There is a related behavior relative to learned values of complex Parameters. If  the dominant value from the instance data is a value from another namespace, e.g., a default value, then the new subject for which a value is sought will be given this dominant instance. However, if the dominant instance is from the instance data namespace, it is always cloned so that it may be independently edited. 

The figure below summarizes the concepts and relationships used to implement default values.

        Concepts and Relationships Implementing Default Values and Learned Default Values

References

1Eggleston, Robert G. and Randall D. Whitaker (2002). Work Centered Support System Design: Using Frames to Reduce Work Complexity. Proceedings of the 46th Annual meeting of the Human factors and Ergonomics Society Meeting, Baltimore, MD, 30 September- 4 October.

2Eggleston, R.G., Young, M.J., and Whitaker, R.D. (2000) Work-Centered Support System Technology: A New Interface Client Technology for the Battlespace Infosphere. Proceedings of NEACON 2000, Dayton, OH, 10-12 October, 2000, pp. 499-506.