Ontologies (Quick)

Ontologies

Knowledge is shared in universAAL in the form of Ontologies. It is its information model. Ontologies are a way to represent real-life information so it can be understood by computers. You can think of Ontologies as a network of concepts linked by properties. One tricky thing is that while we usually think in tree-view, Ontologies are meshes.

Ontologies can be represented in some standard format such as serialized RDF, but in universAAL Ontologies have a code representation so they can be handled by the Middleware. There are tools to convert from one to another. Ontologies are usually grouped in domains representing a single field of knowledge, such as Devices, Health or Furniture.

How to build an ontology

In the Middleware representation Ontologies are composed by an Ontology class that defines the whole Ontology, a Factory for serialization, and a collection of classes representing the concepts.

Resources are how the concepts are represented. They are the nodes in the mesh. They are identified by a URI. They can inherit from other resources, and have properties that link to other resources or datatypes. In the Middleware representation a Resource is like a class. In addition to being defined in the Ontology class, there is a class representing it that can be instantiated to be used from the code, and contains constants that identify its URI and properties URI, and helper methods to handle it. All concept Resources that can be instantiated and handled from code extend from universAAL´s ManagedIndividual (or another super-class which will eventually extend ManagedIndividual), which extends from Resource. If the concept is not supposed to be instantiated it can be defined as abstract, despite this is not a feature of Ontologies.

Please note, that the actual ontology may differ from this short example.

 //Resource code that represents a light source concept//
 public class LightSource extends Device {
   // Resource URI start upper case, properties & instances lower
   public static final String MY_URI = DeviceOntology.NAMESPACE + "LightSource";
   public static final String PROP_HAS_TYPE = DeviceOntology.NAMESPACE + "hasType";
   public static final String PROP_SOURCE_BRIGHTNESS = DeviceOntology.NAMESPACE + "srcBrightness";
   public LightSource() {super();}
   public LightSource(String uri) {super(uri);}
   // A concept resource class must comply with certain methods:
   public String getClassURI() {return MY_URI;}
   // This is for reducing serialization depending on property
   public int getPropSerializationType(String propURI) { ... }
   // This is to determine when an instance is properly built
   public boolean isWellFormed() { ... }
   // There can be as many helper methods as desired, or none
   public void setBrightness(int b) {
      setProperty(PROP_SOURCE_BRIGHTNESS, new Integer(b));
   }
   ...
 }

 //Factory code for serialization purposes//
 public class DeviceFactory implements ResourceFactory {
   public Resource createInstance(String classURI, String instanceURI, int factoryIndex) {
      switch (factoryIndex) {
      case 0: return new LightSource(instanceURI);
      // ...new instances for each index used in Ontology class
 }  }  }

Properties are links between the concepts. They are also identified by URIs and can also inherit from other properties. They can have restrictions upon them, like cardinality. For each property there usually are helper methods in its Resource class to get, set and possibly add a value, although it is always possible to use the generic method setProperty. It always checks that the value set satisfies the restrictions. When cardinality is greater than 1, multiple values can be set as a List.

Datatypes are the native data formats, like Boolean, Integer and so on. They are always present by default and don´t have properties. These types are available through TypeMapper to obtain their URI.

Enumerations are sets of instances of Resources, representing different specific values that a property can point to. They cannot be instantiated and therefore are created as abstract Ontological Resources, with convenient methods to initialize them in the Ontology class. They have a class representing them too, but it´s different from those representing normal Resources.

 // Ontology code that defines all concepts and their properties//
 public final class DeviceOntology extends Ontology {
   private static DeviceFactory fact = new DeviceFactory();
   public static final String NAMESPACE = "http://ontology.universaal.org/Device.owl#";
   public DeviceOntology() {super(NAMESPACE);}
   public void create() {
      Resource r = getInfo();
      r	.setResourceComment("Descriptive comment...");
      r.setResourceLabel("Device");
      addImport(DataRepOntology.NAMESPACE);
      // ... add imports for every other used ontology
      // Create Light Source concept resource
      OntClassInfoSetup oci = createNewOntClassInfo(LightSource.MY_URI, fact, 0);
      oci.setResourceComment("Descriptive comment...");
      oci.setResourceLabel("Light Source");
      oci.addSuperClass(Device.MY_URI);
      oci.addObjectProperty(LightSource.PROP_HAS_TYPE).setFunctional(); // When cardinality 1:1
      oci.addDatatypeProperty(LightSource.PROP_SOURCE_BRIGHTNESS).setFunctional(); // When cardinality 1:1
      oci.addRestriction(MergedRestriction.getAllValuesRestrictionWithCardinality(LightSource.PROP_HAS_TYPE, LightType.MY_URI, 1, 1));
      oci.addRestriction(MergedRestriction.getAllValuesRestrictionWithCardinality(LightSource.PROP_SOURCE_BRIGHTNESS, new IntRestriction(
         new Integer(0), true, new Integer(100), true), 1, 1));
      ''// ... create the rest of concepts''
 } }

 //Application code to register the ontology at startup
 OntologyManagement.getInstance().register(moduleContext, new DeviceOntology());