The Core Layer

The core level of the stack (Figure 8.3) contains the main descriptive elements of the framework. In this layer, domain vocabularies concerning the base concepts stated earlier are giving meaning. In the scope of this work, to give a concept meaning is to provide descriptive attributes which can logically distinguish the concept from others. The core layer contains a number of ontologies, one for each of the concepts contained within the base layer. In this manner, each ontology can be developed independently of others within the layer. This characteristic is important for the vocabulary to be extensive and robust, and shall be highlighted later in this section. Each ontology within this layer has been developed to provide descriptive at-

Figure 8.3: The Core Level of the Stack

tributes and new classes relative to the domain of the base concept. For example, the Device ontology contains descriptive attributes which can be applied to the de- vice concept, such as offersService, hasLocation and hasDeviceCategory. The Device ontology also contains a parent concept, DeviceCategory. A DeviceCat- egory represents the purpose of the device. For example, Speaker, hasDevice- Category, Audio denotes that a Speaker concept can be classified as a device is categorised as an Audio device. The Device ontology therefore defines many classes of DeviceCategory which can be used to represent the classification of a device. More Than A Taxonomy

A taxonomy is a classification of particular domain. Within a taxonomy, classes share relationships between each other, such as parent-child relationships. For ex- ample, a taxonomy can contain the fact that a Car is a subtype of Vehicle. At first, it would seem that the core layer of the stack is merely a taxonomy for the particular domain, but this is not so. As stated earlier, the core layer can be used to give meaning to classes. For example, when a member of the Speaker class is encountered, it contains attributes which denote it as being a Speaker. There is meta-data available to denote why it is a member of the Speaker class, rather than it simply just being a member of the class. If a device is a member of the Speaker class, this means it also hasDeviceCategory: Audio

Having Separate Ontologies

One of the main assumptions of this work is that there can be no complete ontology or set of ontologies which accurately capture every relevant aspect of the home net- work domain. To this end, taking an isolationist view toward ontology development

protects the stack approach against situations where disagreements arise to the con- tents of a domain ontology. Section 5.5.3 discusses issues associated with developing large ontologies to cover a number of domains. Separating ontologies into specific domains provides a structured approach to ontology development. If a developer or user disagrees with assumptions or definitions made within one ontology, there is no need to disregard all other ontologies within the core layer.

Suppose a developer already has an ontology which describes locations within the home. Rather than program their search agent to work with a new definitions of location related concepts, they can simply substitute the location ontology within the stack with their own. When the developer now begins to create component de- scriptions, they can use a mix of terminology from both the stack inbuilt vocabulary and their own location ontology.

As all information concerned within the core ontologies is either self contained, or references concepts within the base ontology, there is no conflict or invalidation of the other ontologies within the core level. The developer merely requires to provide a relationship between their own base location concept and that within the base ontology. The logical properties of OWL allow for search mechanisms to bridge this combination of ontologies.

For example, suppose the developer’s base location concept has the URI ext:Room, this can be declared equivalent to the Location concept within the Base ontology through the owl property (ext:Room, owl:equivalentTo, lsd:Location). The Device ontology contains the property hasLocation, which is defined in the ontology by (hasLocation, rdfs:range, lsd:Location). Through the equivalence property, hasLocation has an implied definition (hasLocation, rdfs:range, ext:Room) which can be inferred through parsing the OWL description. Suppose ext:Room contains a subclass ext:LivingRoom. Through the replacement of the Location on- tology, but the use of the other ontologies in the core layer, the following description would be valid: (Speaker, hasLocation, ext:LivingRoom).

This example highlights the advantages gained by separating domain ontologies. This approach increases the usability of the stack vocabulary, reducing the chance

of a developer requiring to create their own home network ontology. This layer of the stack is not intended to be complete. New classes of devices and services may emerge, along with new representations of the other base concepts. For example, it is unfeasible to believe every class of Context Variable can be captured within a single ontology, as this concept can be largely thought of as context dependent. Abstracting from the Ontology

This core level is like a collection of dictionaries. Each dictionary is concerned with one term from the base level. A dictionary defines how the concept can be used. Concepts are given definition from the attributes stated in the dictionary. The reason the layers within the ontology stack are separated is this: Someone may disagree with one of the dictionaries, but this does not exclude them from using the other dictionaries. If everything was in a single ontology, disagreeing with one dictionary would invalidate the whole ontology. In this approach, they can define their own dictionary for a concept, but reuse the rest of the dictionaries within the layer.