In this section we discuss the experiments carried out in order to demonstrate the utility of the Device Ontology and to verify whether it fulfils the purpose it was intended for (as described in the motivating scenarios in Section 3.2). These experiments will also show, how the Device Ontology coupled with description logic reasoning, help to improve the results of service discovery, over and above what is provided by syntactic service discovery approaches.
We consider the examples set out in Section 3.2, where there is a query for a certain service or device, and a number of devices are available. By classifying the requests and the available devices using a DL reasoner, and by checking the subsumption relation between the query and the available devices, we can judge which devices satisfy the query (the devices subsumed by the query). The case study ontologies were developed using the Prot´eg´e ontology editor [94] and classified using the Pellet DL reasoner [104].
Example 1: Seeking a Wide Screen, Flat Panel display unit that has in-built speakers
In this example, the request is for a Widescreen display, that uses Flat Panel technology and has integrated Speakers. The query expressed in DL notation is14:
CS3 : Query≡ dev : Device
(∃dev : hasDisplay. dev : W idescreenDisplay) (∃dev : hasDisplayT echnology. dev : F latP anel) (∃dev : hasSpeakers. true)
In this case we have the axiomatic knowledge that helps to determine if a display is widescreen or not by considering its aspect ratio. Thus although a device is not explicitly specified as a widescreen, this fact could be inferred from the aspect ratio property. This knowledge is specified by using necessary and sufficient conditions (equivalent classes) in OWL.
W idescreenDisplay≡ dev : Display
∃aspectRatio(as15 9 as16 10 as16 9)
The available devices are listed below:
• The display HP VS19X is a TFT display, with 4:3 aspect ratio which does not have integrated speakers.
CS3 : HP V S19X ∃dev : hasDisplayT echnology. dev : T F T
∃dev : aspectRatio. dev : as4 3
∃dev : hasSpeakers. false
• The display LG RU23LZ50C is a LCD display, with 15:9 aspect ratio which has integrated speakers.
CS3 : LG RU 23LZ50C
∃dev : hasDisplayT echnology. dev : LCD
∃dev : aspectRatio. dev : as15 9
∃dev : hasSpeakers. true
14Please note here, that using our Device Ontology the query is expressed as:
Device
∃dev : hasHardwareDescription(dev : HardwareDescription (∃dev : hasDisplay(dev : W idescreenDisplay
(∃dev : hasDisplayT echnology. dev : F latP anel))) (∃dev : hasAudioDescription(dev : AudioDescription (dev : hasSpeakers. true))))
due to the manner in which the classes are organised. But for the sake of readability and brevity of this discussion, we do not show the entire nested form, but only show the relevant property restrictions in the documentation (since the entire query/ advertisement in its original nested form will be too lengthy and confusing to follow). We will be using this simplification through out the discussion in this section.
• The display PackardBell Maestro is a TFT display, with 16:9 aspect ratio which has integrated speakers.
CS3 : P ackardBell M aestro
∃dev : hasDisplayT echnology. dev : T F T
∃dev : aspectRatio. dev : as16 9
∃dev : hasSpeakers. true
• The display Philips 107E66 BlackCRT is a CRT display, with 4:3 aspect ratio which does not have integrated speakers.
CS3 : P hilips 107E66 BlackCRT
∃dev : hasDisplayT echnology. dev : CRT
∃dev : aspectRatio. dev : as4 3
∃dev : hasSpeakers. false
• The display Philips 32PW6520 is a CRT display, with 16:9 aspect ratio which has integrated speakers.
CS3 : P hilips 32P W 6520
∃dev : hasDisplayT echnology. dev : CRT
∃dev : aspectRatio. dev : as16 9
∃dev : hasSpeakers. true
The classification results obtained when this example ontology was classified using Pellet is shown in Figure 3.5.
Figure 3.5: Classification results obtained from Pellet for Example 1.
According to the classification hierarchy produced by Pellet, the displays Packard-Bell Maestro and LG RU23LZ50C are subsumed by and hence satisfy the query. After inspecting the properties of the devices, we could observe that this is intuitively correct.
This use case shows an important advantage of using ontological descriptions coupled with reasoning engines for service discovery. That is, the ability to use inferencing to
reason between different representations of the same concept; (in this example it was inferred that displays with certain aspect ratios are widescreen displays).
It is often the case, that the service providers usually describe devices in terms of lower-level properties, and the service seekers or clients usually prefer to describe service requests using more abstract or higher level concepts. This also agrees with the principle set out by Gonzalez-Castillo et. al in [57], where they state that a requirement of a service description approach, is to allow the flexibility for the description to be more general or more specific. This fact is apparent in the above example, where the service request is expressed as a widescreen display, whereas the devices are described using the (lower-level) property of aspect ratio. The OWL language allows us to express necessary and sufficient conditions in the specifications, and we have exploited this ability of the language in the Device Ontology, and have specified that displays with certain aspect ratios correspond to widescreen displays. This knowledge in turn can be used to infer that a display with such aspect ratios ‘must’ be a widescreen display.
Such benefits cannot be gained from the traditional syntactic service discovery ap-proaches where flat structures or interface based descriptions are used or from object-oriented programming approaches. This example clearly shows the flexibility provided by an ontological approach for device description, and the ability of a reasoning engine (coupled with such an ontological approach) to infer between such different representa-tions of services thus providing effective semantic discovery of services.
Example 2: Seeking a device that is capable of displaying an image stored on a Secure Digital Card
This is a kind of query that can be raised from a scenario where a user has an image stored on a SD Card which he wants to show to his colleague. In this type of request, the service seeker is in need of a certain service or functionality. There are two requirements expressed in this service query, firstly, there should be a device capable of reading from SD Card media, secondly, it should be capable of rendering an image.
Using description logic notation the query can be expressed as follows:
CS1 : Query≡ dev : Device
(dev : Slot Drive (∃dev : hasReadableMedium. dev : SecureDigitalCard)) (∃dev : hasService. CS1 : ImageRendering)
The latter requirement of having a Image Rendering Service can be explicitly stated in the device description (for example as in the case of MP3 players, where the ability or inability to render images are inherent to the device and thus can be explicitly stated) or it can be judged or inferred by the fact that, the device has a display and software that is capable of rendering images.
To explicitly state this knowledge (that the device is capable of rendering an image, if it has a Image Rendering service OR if it has a Display and software capable of rendering images) we use two sets of necessary and sufficient conditions (equivalent classes in OWL) as:
ImageDisplayDevice≡ ∃dev : hasService. CS1 : ImageRendering ImageDisplayDevice≡ (∃dev : hasDisplay. dev : Display) (∃CS1 : hasApplication. CS1 : ImageV iewingApplication)
Now let us consider the available devices; below we provide the listing of the devices and their relevant properties:
• JacksLaptop which has an SD card slot capable of reading a SD card, and Win-dowsPictureandFaxViewer that is capable of rendering images
CS1 : J acksLaptop
∃dev : hasSlot Drive(dev : SDCardSlot ∃dev : hasReadableMedium dev : SecureDigitalCard)
(∃CS1 : hasApplication. CS1 : W indowsP ictureandF axV iewer))
• MarysOfficeLaptop which has an BridgeMedia slot capable of reading a SD card, and GhostViewer that is capable of rendering images
CS1 : M arysOf f iceLaptop
∃dev : hasSlot Drive(dev : BridgeMediaSlot ∃dev : hasReadableMedium dev : SecureDigitalCard)
(∃CS1 : hasApplication. CS1 : GhostV iewer))
• Danny which does not have any slot capable of reading a SD card, but has Win-dowsPictureandFaxViewer that is capable of rendering images
CS1 : Danny
∃CS1 : hasApplication. CS1 : W indowsP ictureandF axV iewer
• The printer PhotoSmart2575 which has a slot capable of reading a SD card, and provides a image rendering service.
CS1 : P hotoSmart2575
∃dev : hasSlot Drive(dev : Slot Drive ∃dev : hasReadableMedium.
dev : SecureDigitalCard)
∃dev : hasService. CS1 : ImageRendering
• The mp3 player I-FriendPES2052 which has a slot capable of reading a SD card, and provides a image rendering service.
CS1 : I− F riendP ES2052
∃dev : hasSlot Drive(dev : Slot Drive ∃dev : hasReadableMedium
dev : SecureDigitalCard)
∃dev : hasService. CS1 : ImageRendering
• The mp3 player ProportaMP3SDPlayer which has a slot capable of reading a SD card, and does not have an image rendering service.
CS1 : P roportaM P 3SDP layer
∃dev : hasSlot Drive(dev : Slot Drive ∃dev : hasReadableMedium dev : SecureDigitalCard)
Figure 3.6 shows the section of classification results obtained, when these concepts (query and the available devices) were classified using Pellet.
Figure 3.6: Classification results obtained from Pellet for Example 2.
The results show that the devices: MarysOfficeLaptop, I-FriendPES2052, JacksLaptop, and PhotoSmart2575 are subsumed by and therefore satisfy the query.
In addition to illustrating how the Device Ontology has helped answer this service dis-covery request, this shows how an ontological approach can infer the functionality of a device although they are not explicitly stated. In this example, although the device does not explicitly state that it provides an Image Rendering Service, it could be inferred from the fact that the device has a display and that it has a software application that is capable of rendering images. This is an important contribution of ontological approaches to service discovery that the conventional syntactic service discovery approaches are not capable of.
Example 3: Seeking a portable Computer, with Unix compatible operating system and FireWire connectivity
In this example, the query can be expressed in DL notation as:
CS4 : Query≡ dev : Device (∃comp : hasOS. comp : Unix)
(∃dev : hasP hysicalInterface. dev : F irewire) (∃dev : portability. true)
In this case we have the taxonomical relations between certain Operating Systems;
Specifically, that SunOS and Linux are subclasses of Unix.
Linux Unix SunOS Unix
The available devices are listed below:
• The Desktop Computer FredsPC has Linux operating system and has FireWire connectivity, and since this is a desktop computer it has the inherited condition that it is not portable.
CS4 : F redsP C
(∃comp : hasOS. comp : Linux)
(∃dev : hasP hysicalInterface. dev : F irewire) (∃dev : portability. false)
• The Laptop Computer JacksLaptop has Linux operating system and has FireWire connectivity, and since this is a laptop computer it has the inherited condition that it is portable.
CS4 : J acksLaptop
(∃comp : hasOS. comp : Linux)
(∃dev : hasP hysicalInterface. dev : F irewire) (∃dev : portability. true)
• The Laptop Computer MarysOfficeLaptop has SunOS operating system and has FireWire connectivity, and since this is a laptop computer it has the inherited condition that it is portable.
CS4 : M arysOf f iceLaptop (∃comp : hasOS. comp : SunOS)
(∃dev : hasP hysicalInterface. dev : F irewire) (∃dev : portability. true)
• The Laptop Computer Danny has WindowsXP operating system and has no FireWire connectivity, since this is a laptop computer it has the inherited con-dition that it is portable.
CS4 : Danny
(∃comp : hasOS. comp : W indowsXP ) (∃dev : portability. true)
• The Handheld Computer JohnsHandheld has PalmOS operating system and has no FireWire connectivity, and since this is a handheld computer it has the inherited condition that it is portable.
CS4 : J ohnsHandheld
(∃comp : hasOS. comp : palmOS) (∃dev : portability. true)
The classification results obtained when this example ontology was classified using Pellet is shown in Figure 3.7. According to the classification hierarchy produced, the computers MarysOfficeLaptop and JacksLaptop are subsumed by the query (as would be expected) and hence satisfy the request.
Here the request seeks for a computer with Unix and the devices returned have specified their OS as Linux and SunOS respectively. The point to be noted here is that the Ontology exploits the ability to specify taxonomic relations within the ontology language and by using reasoners this knowledge can be used for effective discovery of devices and services.
This again shows the flexibility provided by ontological approaches; the service descrip-tion can be made more general (as to specify that the required OS is Unix) or specific (so as to say that the OS should be Linux or SunOS) as appropriate for the circumstances;
and since inferencing engines are used in finding the matches to satisfy a given request (as opposed to syntactic comparison) the relevant matches can be found, even though they are represented differently. This flexibility in the description language or effective-ness in service matching is not present in traditional service discovery approaches as already discussed in previous sections and pointed out by Chakraborty et. al. in [25]
and Tangmunarunkit et. al in [128].
3.7 Discussion
This chapter presented the Device Ontology which provides a general framework that describes devices and their services in a flexible and expressive way, to aid the description of a variety of devices and to facilitate effective semantic discovery of services. The ontology was developed by following a systematic design process, going through the activities and tasks applicable to each design stage, as suggested in the Methontology [46, 85] ontology design methodology. The ontology has been formally evaluated by using the current best practice approaches for ontology evaluation [55], specifically the OntoClean method [63] and ODEval[54]. The validation case studies provide an assessment of the usefulness and usability of the ontology, and have shown how the Device Ontology coupled with a DL reasoner can help to improve the results of service discovery and matching, over and above of what could be achieved with the syntactic approaches;
Figure 3.7: Classification results obtained from Pellet for Example 3.
i.e. they have demonstrated the benefits of semantic matching as opposed to syntactic matching.
Although an ontological description of services coupled with DL reasoning can provide semantic matching of service descriptions and thus improves on syntactic matching, there are several desirable properties of a semantic matching solution that cannot be provided through the use of an ontological description alone. These properties are:
• Approximate matching: In most practical scenarios, the resource seekers (in the absence of an exact match) will be willing to consider advertisements that deviate from the request in certain respects. Therefore, such advertisements that can
‘approximately’ match a request must also be considered during the matching process, and returned as potential matches as appropriate.
• Ranking of matches: If there are approximate matches identified during the match-ing process, these matches must ideally be ranked or ordered to reflect the suit-ability of the advertisements to satisfy the request.
• Consideration of priorities on individual requirements: A resource request can have a number of requirements or constraints specified in the request that must be met by a potential advertisement. In practical situations, the resource seeker will consider certain requirements to be more important than others, and thus will
have different priorities or weights placed on them. These priorities must be taken into account during the service discovery, for the match results to be suitable for the context.
As demonstrated in the validation case studies in Section 3.6, an ontological description of resources coupled with DL reasoning alone, will only identify resources (by seman-tically matching the conceptual content of the advertisements and requests) that can completely satisfy the request concerned; it does not provide any approximate matching or ranking. Also, it does not facilitate priority consideration in the matching process.
In order to satisfy these requirements, a matching mechanism is needed, which will ex-tend the semantic matching (provided by ontological descriptions and DL reasoning), to facilitate approximate matching, match ranking and priority consideration during the matching process.
Chapter 4 discusses these desirable properties and requirements of a semantic match-ing solution in more detail along with motivatmatch-ing scenarios, and presents the semantic matching mechanism that has been developed to address these requirements. The Device Ontology is used to facilitate the description of resource advertisements and requests, in the implementation of this proposed semantic matching solution (discussed in Chap-ter 5).
As with any ontology, the Device Ontology needs to be refined and evolved through use and application [55]. Also, a potential area for further development in this ontology, is to investigate how the connectivity of devices can be modelled in the ontology. That is when two devices are connected, how can this ‘connectedness’ be indicated in the ontology and how are their capabilities affected? For instance when a mp3 player is connected with a media card reader, the additional functionality obtained through this combination (such as the ability to read from the additional media types) will have to be modelled for the effective use of the Device Ontology in such situations.