The Use of Capability Descriptions in a Wireless ... - CiteSeerX

The Use of Capability Descriptions in a Wireless Transducer Network

Bernard Horan


Bernard Horan

SMLI TR-2005-131

February 2005

Abstract:

This document presents the requirements for a language to describe the capabilities of a transducer in a wireless transducer network (WTN). It provides a survey of existing technologies in this field and concludes with a framework in which the capabilities of a transducer can be employed to assist users in the configuration of a WTN. The intended audience for this paper comprises members of academic and industrial research groups whose focus is networked devices, such as those used in wireless sensor networks.

Sun Labs 16 Network Circle Menlo Park, CA 94025

email address: [email protected]

© 2004 Sun Microsystems, Inc. All rights reserved. The SML Technical Report Series is published by Sun Microsystems Laboratories, of Sun Microsystems, Inc. Printed in U.S.A. Unlimited copying without fee is permitted provided that the copies are not made nor distributed for direct commercial advantage, and credit to the source is given. Otherwise, no part of this work covered by copyright hereon may be reproduced in any form or by any means graphic, electronic, or mechanical, including photocopying, recording, taping, or storage in an information retrieval system, without the prior written permission of the copyright owner. TRADEMARKS Sun, Sun Microsystems, the Sun logo, Java, Jini, and Solaris are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. in the U.S. and other countries. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc. UNIX is a registered trademark in the United States and other countries, exclusively licensed through X/Open Company, Ltd. For information regarding the SML Technical Report Series, contact Jeanie Treichel, Editor-in-Chief .All technical reports are available online on our website, http://research.sun.com/techrep/.

February 2, 2005

The Use of Capability Descriptions in a Wireless Transducer Network Bernard Horan Sun Microsystems Laboratories

Introduction The work described here is the result of the Anteater project conducted in Sun Microsystems Laboratories, during the period 2003 to 2004. The overall goal of the Anteater project was to undertake research into networks of sensors and actuators (collectively ‘transducers’) from the perspective of identifying the necessary middleware required to compose, program, and deploy a network of nodes.As one of the project’s sub-goals it explored how to simplify the task of configuring, maintaining and altering a network of wireless transducers. The installation of a wireless transducer network (WTN) involves two kinds of configuration: 1.

2.

Infrastructure. This is broadly similar in terms of requirements to the infrastructure required by conventional networked computers—that is, all but layers six and seven of the OSI seven layer model: the presentation and application layers. Physical connectivity is provided in the form of RF, using low level protocols such as TCP and UDP. Task-oriented. How would a real end user would configure a WTN in order to fulfil the needs of a task. It assumes that the devices are already on the network and can communicate with each other. By an end user, we mean the person who has bought a WTN such as a home automation system.

It is the second kind of configuration that this paper addresses.1 We begin with the assumption that the devices are already networked and our only concern is with the need to compose or assemble the functionality of the devices such that their aggregate functionality meets the needs of the task. Furthermore, we assume that all the devices are

1. The first kind of configuration is worthy of research and there are many architectures and standards in this area such as Dynamic Host Configuration Protocol [1] and Rendezvous [2].

1

Why We Need Capability Descriptions

“trustworthy”—they have passed whatever security and privacy tests are necessary to be present in the network. The remainder of this document is structured as follows: the next section is a presentation of the arguments in favour of using rich capability descriptions. This is followed by a survey of existing technologies that provide such descriptions. This is then followed by a proposed framework for describing the capabilities of a transducer in a WTN. The document concludes with a summary.

Why We Need Capability Descriptions Many manufacturers provide data sheets to describe the capabilities of wireless transducers they produce. For example, Magtrol produce transducers used in motor test equipment—it provides a data sheet for each of its products.2 As well as general product information, a data sheet provides information for users to be able to configure and install the product. However, the capabilities described in data sheets are inappropriate for use when configuring devices to meet the needs of an application. For example, a data sheet suffers from the following two problems: it is too low-level and it is separate from the device it describes. LOW-LEVEL

Current data sheets are concerned with the physical or networking aspects of the device, such as its pin-outs. They contain critical information needed by an instrument or a measurement system to identify, characterise, interface and properly use the signal from an analogue sensor [3]. Although this information is necessary to get the device on the network and communicating with other devices, it is at the wrong level of detail to assist with the configuration of devices in order to meet the needs of a task. Even if the data sheet describes the functionality of the device in terms of the data it provides (or requires), this is also at too low a level. For example, if the data sheet for a motion sensor indicates that the presence of motion is indicated by a boolean data value (rather than, say, a float), it usually doesn’t describe the information content encoded by this data value—for example that the sensor has sensed the presence of a human being (rather than, say, a cat).

SEPARATE

The data sheet is separate from the device it describes. When confronted with a network of heterogeneous devices that share a similar physical appearance, it is difficult to identify the data sheet for a particular model of device. This difficulty adds to the complexity of the task of configuring a WTN. 2. http://www.magtrol.com/datasheets.htm

2



The two problems described above already exist in today’s technology. If we look to the future, many commentators describe factors that may have significant influence on the way in which WTNs are installed or configured. These are described below: VOLUME

The Great Duck Island experiment3 is an example of a large scale WTN. In 2002, a 43 node sensor network was deployed on the island. Each node hosts up to five sensors monitoring the island’s habitat. We believe that future WTNs will contain many more transducers and their sheer number will increase the difficulty of configuring a WTN. The nodes in the WTN installed on Great Duck Island all provide the same functionality.With advances in digital technology, it is becoming increasingly practical to provide virtually any sensor with a wired or wireless connection that enables remote access to the devices’ control inputs and data outputs [4]. Thus in the future, we believe that the nodes in a WTN will be a mix of sensors and actuators with heterogeneous functionality. Combined with an increase in volume, this heterogeneity will increase the problem of interoperation, such that shared a priori knowledge in the form is interoperability standards will no longer be adequate [5].

FLEXIBILITY

Future WTNs are expected to include characteristics of flexibility and extensibility—mirroring the ones we expect from our experience of telephony and modern computer networks. The need for flexibility can be broadly categorised as due to the following factors: changing requirements, changing technology, maintenance and smarter devices. Changing Requirements It is currently very difficult to modify a WTN in response to changing requirements. Many installations, such as manufacturing control, are less likely to change; whereas others, such as health monitoring, respond to the changing healthcare needs of the patient by providing extra application functionality. Current WTN applications tend to be inflexible and adopt a centralised or supervisory architecture. Data from sensors is collected by a central server which interprets the data and acts on it. Actions are put into effect by the effectors at the edge of the network. This kind of architecture responds to changing requirements by a change in the supervisory software, not by a change in the devices or their capabilities. Future WTNs will need to be flexible in response to changing requirements; not just in terms of the server software, but more importantly in the ease with which the WTN and its devices can be reconfigured. 3. http://www.greatduckisland.net/


3


Changing Technology As WTNs become more widespread the market for transducers will become larger and the variety of transducer models will increase [6]. The functionality of these devices will evolve to include support for new applications, such as mission-critical ones providing real-time data collection and analysis. The combination of new models of transducer and new kinds of applications leads to two configuration problems: 1.

2.

The standards and protocols that have been developed to describe existing devices may no longer be appropriate. Even if it were possible to use existing mechanisms to describe the capabilities of these new devices, the characteristics of the application will mean that it is no longer possible or acceptable to halt or suspend the application in order to reconfigure it or add new devices. This additional constraint may mean that existing configuration strategies are no longer applicable.

Maintenance One consequence of small wirelessly-networked devices is that their introduction into physical environments will be evolutionary and piecemeal since they remove the cost of cabling and significant planning [7]. This very physical flexibility will lead to similar requirements for flexibility in their configuration. Flexibility will reduce the cost of maintenance due to the ease with which new devices can be added to an existing network; existing devices can be upgraded or replaced without having an impact on the other devices in the network. It will also lead to a reduction in the risk of getting the installation wrong—current wireline installations such as heating, ventilation and air conditioning (HVAC) are terribly brittle. One side effect may be that there is increased opportunity for less skilled people to take responsibility for the installation and maintenance of WTNs. Open Standards The current model of WTNs is that of a “closed world”. For most current applications, such as home automation, composition of devices is fairly straightforward. For example, the Shell HomeGenie4 system is designed so that the home owner is able to install and configure most devices (such as contact sensors or power switches). An installation engineer is only required to install a home gateway (connected to the internet) and the wireless thermostat that controls the home heating system (for insurance and liability reasons).

4. http://www.homegenie.com

4



However, the reason the home owner is able to perform this configuration is because the HomeGenie system is essentially “closed”—the devices are preconfigured to work together. The devices in the HomeGenie system will not interoperate with any other system, and likewise it is not possible to purchase off-the-shelf components to extend the HomeGenie system. Shell HomeGenie is not alone in promoting a closed world. Current X10 systems5 are similar in their design: the world provided by X10 is more open due to the existence of multiple vendors; however, the X10 system relies on a proprietary infrastructure preconfigured with a set of device types. In a closed world we know ahead of time what the devices are, what functionality each provide and also how they will be configured. Other features of a closed world include situations in which there is a single vendor or a one-time installation procedure. We envision a future in which it’s possible to mix and match devices from multiple vendors, in much the same way that we can purchase today’s electrical appliances safe in the knowledge that they will plug into a domestic electrical system. It will no longer be possible to rely on proprietary standards, so the future development of WTNs will need to address open systems. SMARTER DEVICES

As devices become “smarter” with more memory and more processing power, we can envisage a time when it becomes possible to modify the functionality of existing devices by downloading code to them. For example, this ability is already possible on Java™-based Personal Digital Assistants (PDAs) and smart-phones, and we expect that this ability will reach smaller devices within two years. When the functionality of a device changes in a network, future WTNs must be able to describe that new functionality so that applications may take advantage of it. In a similar vein, as devices become more powerful we believe it is likely that a device itself will perform some computation. For example, a smart camera could undertake image processing to observe the presence of an intruder. Instead of the raw data being fed back to a centralised server, the data analysis is performed on the device. In this kind of example, it’s important to know what the capabilities of the device are. What kind of analysis does the device perform? Is it possible to adjust the parameters in the analysis, etc.

5. http://www.smarthome.com/aboutx10.html


5


SUMMARY OF REQUIREMENTS

In the sections above, we have presented the particular characteristics of a WTN. In this section we identify the requirements for capability descriptions that result from these characteristics. • The functionality of a device should be described in terms of its

syntax and its semantics. • The device and its description should be closely linked. • The description should be machine-interpretable. • An a priori agreement on standards is insufficient. These points are expanded below. We need to describe the functionality of a device on two levels, syntax and semantics. The syntax should include an indication of the type of data the sensor returns, such as one bit of data (instead of, say, a scalar between zero and one). The type could be represented using existing schemata such as XMLSchema6 or those provided by Multipurpose Internet Mail Extensions [8]. The semantics should provide a description of the information content of that one bit, for example, that the device has sensed the presence of a human being. Additionally, when describing the capabilities of an actuator, the description should include the behaviour of the device and its effect on its immediate environment. This should also be expressed in terms of semantics (what kind of functionality it provides) and syntax (how it works). The description needs to be easily accessible from the device, giving the appearance of the device’s ability to introspect and inform requesters with information about its capabilities. Due to the foreseeable increase in scale, it will be necessary for the description to be machine-interpretable, not just human-readable. We need devices to interoperate seamlessly, without prior agreement on the form that the interoperation will take. Other commentators, such as Lassila [9], have used the term “serendipitous interoperability” to describe this requirement, but this misses the point—systems need to be designed to be serendipitous. This point is recognised by Newman et al. [10], who argue that many network configurations will be ad hoc and need to support opportunistic use of discovered network resources such as devices.

6. http://www.w3.org/XML/Schema.

6


Existing Technologies for Describing Capabilities

Existing Technologies for Describing Capabilities The Anteater project undertook a survey of existing work in this area to consider existing approaches to the description of a device’s capabilities. Our goal was to find a suitable technology that we could adopt, or adapt, to meet the requirements identified above. It is interesting to note that there are a large number of technologies under investigation in research projects all over the world (such as the Intentional Naming System [11] and eGadgets7), far too many to cover in this document. We have picked the most common and promising approaches and described them here. Furthermore, this abundance of technologies seems to emphasise the need for a “better” description of a device's functionality (even though there's little concrete evidence available in the form of requirements). Existing technologies that can be used to describe the capabilities of a device can be divided into two groups: • Languages that provide a syntax (and occasionally semantics) to

describe the functional characteristics of a device or service • Architectures expressed via protocols or frameworks which can be used to advertise and discover the capabilities of a device or service. In this second group, the capability description is often embedded in the architecture. LANGUAGES

In this section we consider the existing languages that are available to describe the capabilities of a device. The languages are presented in loose alphabetical order, and are grouped according to similarity of intent or implementation. Composite Capability/Preference Profiles (CC/PP) [12], the Foundation for Intelligent Physical Agents (FIPA) [13] and J2EE Client Provisioning (JSR124) [14] standards are focused on describing the physical capabilities of a device such as its memory, CPU, etc. These standards are aimed at larger devices such as mobile phones and PDAs. CC/PP and FIPA present the capabilities of a device using an extensible language (in the case of CC/PP, using the Resource Description Framework (RDF) [15]), whereas JSR124 uses labels from a set of Java interfaces in the javax.provisioning package combined with an XML device configuration file that references those interfaces. This last approach relies on an out-of-band agreement on the labels to be used and also precludes modification once installed. SensorML [16] and Transducer Electronic Data Sheets (TEDS) [17] provide similar descriptions of transducers. SensorML does not provide

7. http://www.extrovert-gadgets.net


7


a detailed description of the hardware design of a sensor but instead acts as a general schema for describing a functional model of the sensor. SensorML has little to say about the services offered by a sensor other than what it measures as well as the range and threshold of those measurements. SensorML requires that a sensor be identified as being of a certain type, as identified by a Uniform Resource Identifier (URI) [18]. For example, of type http://www.opengis.net/sensor#anerometer. The TEDS specification provides a hardware/electrical description of the physical device, rather than its functionality. A TEDS contains the information needed by an instrument or measurement system to identify, characterise, interface and properly use the signal from an analogue sensor. The standard also includes references to an electrical interface, read and write logic functions to access the TEDS. (However, the main feature of TEDS is the fact that it is electronic and directly associated with the device that it describes. TEDS provides a classic example of a technology being used to support a device being able to describe its own capabilities.) The National Marine Electronics Association Standard (NMEA) 0183 [19] has become a standard protocol for interfacing navigational devices, for example Global Positioning System receivers. Based on the RS232 interface, it describes a protocol by which a talker device can communicate with multiple listener devices using parameterised sentences with a maximum length of 80 characters. The interesting feature of the specification is the way in which the sentences are constructed—the approach of using a two-letter mnemonic to identify a type of device is attractive. It seems particularly appropriate for use in a closed network in which all the devices, and their functionality, is known before installation. TinySchema [20] is a schema for describing the attributes, commands and events in TinyOS.8 the operating system used by Berkeley motes. The schema provides two ways of describing a transducer: via attributes and commands. There are three classes of attribute: • sensor attributes, such as the raw readings from a sensor. • introspective attributes, such as values from internal software or

hardware states.(For example, software version stamp, parent node in routing tree, battery voltage.) • constant attributes, such as the constant values applied to a device and programming time or run time. (For example, a node’s identifier, its name or location.) There are two kinds of commands: • an Actuation Command. These are commands that cause some

physical actions on a mote, for example, rebooting a mote, flash

8. http://www.tinyos.net/

8



LEDs, sound buzzer, raise a blind (when connected to an appropriate actuator), etc. • a Tuning Command. These are commands that adjust internal parameters, for example, routing policy, number of retransmissions, sample rate, etc. Currently all attributes and all commands must be statically built into each installation of TinyOS (that is, each mote) and thus need to be agreed before deployment or installation. DISCOVERY PROTOCOLS

This second group includes technologies which address one of the requirements identified in the introduction: given a task, what functionality is available to meet the needs of the task? This requirement can be considered to be analogous to one of discovery: to find a device (or service) that fulfils certain criteria. However, few of these technologies address the need to describe the functionality of a device for its own sake, that is, given a device, what can it do? Some protocols that are concerned with the discovery of a device do so by modelling its functionality in terms of the services it provides. Since this characterisation of a service is so prevalent, we have also included several protocols that are not, per se, concerned with the description and discovery of a device but instead the description and discovery of a service. Protocols implicitly associated with the discovery of a device, appliance or item of equipment include Bluetooth, HAVi, Jini, JXTA, Salutation, Service Location Protocol, Universal Plug and Play and USB. Other authors provide a good summary of the more common of these protocols [21] [22]. Here, they are described from a different viewpoint: their suitability as an approach to describing the functional capabilities (or services) of a transducer. The Bluetooth Service Discovery Protocol [23] provides a means for applications to discover which services are available and to determine the characteristics of those services. The Bluetooth specification identifies a service as any entity that can perform an action or control a resource on behalf of another entity. The information that describes a service is contained in a service record which consists entirely of a list of service attributes. An attribute comprises two components: an attribute identifier (ID) and attribute value. A service class definition specifies each of the attribute IDs for a service class and assigns a meaning to the attribute value associated with the attribute ID. (A service class corresponds to a “kind” of service, such as providing a printing service.) The Home Audio Video Interoperability (HAVi) Architecture [24] allows consumer electronics manufacturers and third parties to develop applications for the home network.The primary goal of the HAVi Architecture is to assure that products from different vendors can


9


interoperate—that is, the products can cooperate to perform application tasks. Each HAVi-compliant device may contain persistent deviceresident information describing its device control capabilities. The minimum set of capabilities and their descriptions is fixed by the members of the HAVi consortium. At present, these are restricted to the following devices: Tuner, VCR, Clock, camera, AV disc, amplifier, display, AV display, modem, and Web Proxy. A JiniSM [25] service is specified in terms of its type (a Java interface) and also several descriptive attributes. There is no limit to the attributes that can be used, though there are some suggestions made in [26]. An attribute is expected to be human readable and must be an instance of a Java class. A JXTA™ [27] peer advertises its services using advertisements—an advertisement is an XML document that describes a service. The XML document consists of attributes and their corresponding values. However, it is not expected to conform to an XML DTD or Schema, and thus can be extended to describe any attributes [28], although at a minimum it must include its unique identifier and an identifier for the group of which it is a member. The Salutation [29] architecture is very similar to most of the other mechanisms described here: it identifies a type of service (whose name is agreed a priori and currently seems restricted to printing, faxing and a few other services) as well as attributes for each type of service. The attributes themselves are typed, indicating that these are also agreed a priori. The Service Location Protocol (SLP) [30] identifies a service using a text string. Characteristics of services are described by values given to named attributes [31]. For instance, a network access point would be described by the name of the protocol it supports (for example, IEEE 802.11), its speed (for example, 11 Mbps), and encryption algorithm (for example, WEP). A service type is a collection of services having a common nature (such as, all the access points) and sharing the same kinds of attributes (such as, protocol, speed, and encryption algorithm). Names of SLP services are subject to standardization in order to achieve uniformity from one system to another. An organization that standardizes service types and names is called a naming authority. The authority from which a service name is drawn can be explicitly specified. However, when it is unspecified, the default naming authority is Internet Assigned Numbers Authority9 (IANA). It that case, the specified service type must have been standardized by IANA, for example, http, ftp, and telnet. A naming authority can have the scope of an enterprise [32].

9. http://www.iana.org/

10



Universal Plug and Play (UPnP) [33] is very similar to SLP. However, a service can also describe itself using a Uniform Resource Locator (URL); this resolves to an XML file which is an instance of a UPnP Service Description Template. One of the descriptors of a service is a set of one or more actions—an action can take one of two forms: a standard action (as described by a UPnP working committee); or a vendorspecific action. However, how to create a suitable naming mechanism in UPnP is still an open question [6]. The goal of the USB specification [34] is threefold: self-identifying peripherals; automatic mapping of function to driver; and configuration. The information required to completely describe a USB device includes a subset whose definition is common to all USB devices and adds items such as vendor identification, device class, and power management capability. Device, configuration, interface, and endpoint descriptions carry configuration-related information about the device. A USB device descriptor provides general information about the device. It includes information that applies globally to the device and all of the device’s configurations. Example information includes: • Device Class (assigned by the USB Implementers Forum (USB-IF)) • Device SubClass (assigned by the USB-IF). These codes are

qualified by the value of the Device Class datum. • Device Protocol (assigned by the USB-IF). These codes are qualified by the value of the Device Class and the Device SubClass data. The information in the USB descriptors has to be agreed by the USB-IF, although vendor-specific data may be added if required. Several architectures are more generally concerned with the description of services. These include CORBA, Java RMI, OWL-S and Web Services; they are described in turn below. The Common Object Request Broker Architecture (CORBA) includes a specification [35] that describes how to bind a name to an object. A name comprises a sequence of namecomponents. A namecomponent comprises an id and a kind. There are no semantics associated with either id or kind, as this is left up to “higher level application software”. Java Remote Method Invocation (RMI) [36] is very similar in intent to CORBA. Remote “Server” objects have to be registered with an RMI Registry (or another naming service such as one that uses the Java Naming Directory Interface [37]). The registry allows you to bind a URL-formatted name of the form //host/objectname to the remote object, where objectname is a simple string name. Both CORBA and RMI suffer from the same problem: the way in which the objects (services) are named. The names must be agreed before installation because they represent the functionality provided by an object. Because of the nature of the programming languages that depend


11


on CORBA (and RMI), the use of static types means that it is impossible to add new services dynamically. The Web Services architecture [38] provides a language, known as the Web Services Description Language [39] (WSDL) to describe the characteristics of a web service. A service description contains the details of a Web Service interface and its implementation. The description includes the service’s data types, operations, binding information, and network location. The semantics of a service is the contract between the service provider and the service requester that expresses the effect of invoking the service. A service semantics may take three forms: be formally described in a computer interpretable form; be identified but not formally defined; or be informally defined via an “out of band” agreement between the provider and the requester.10 The Universal Description, Discovery, and Integration specification [41] supports web service discovery by using a service classification such as UNSPSC [42] or RosettaNet [43]. Other authors have commented on the similarity between the problem of composing the services provided by a device and the problem of web service composition [5] [44] [45]. OWL-S11 [46] is a Web service ontology based on the Web Ontology Language [47] (OWL12), intended to supply Web service providers with a core set of mark-up language constructs for describing the properties and capabilities of their Web services in unambiguous, computerinterpretable form. The OWL-S mark-up of Web services is intended to facilitate the automation of Web service tasks, including automated Web service discovery, composition and inter-operation. The structure of the OWL-S ontology of services provides three essential types of knowledge about a service: • What does the service require of the user(s), or other agents, and

provide for them? The answer to this question is given in the profile. • How does it work? • How is it used? An OWL-S profile describes a service as a function of three basic types of information: what organization provides the service, what function the service computes, and a host of features that specify characteristics of the service. The functional description of the service is expressed in terms of the transformation produced by the service: it specifies the inputs required by the service and the outputs generated. The profile

10.In recent months there has been a proposal to bridge the gap between devices and web services. The Device Profile for Web Services [40] describes how devices should use web service protocols. 11.Formerly known as DAML-S. 12.OWL is the somewhat confusing acronym for the Web Ontology Language.

12



also describes the preconditions required by the service and the expected effects that result from the execution of the service. SUMMARY

The “languages” described above can be divided into two categories: those that describe the physical or technological characteristics of the device (CC/PP, FIPA, JSR124, SensorML and TEDS); and those that describe a protocol or control mechanism (NMEA and TinySchema). The discovery protocols are less easy to categorise. Table 1 on page 14 provides a comparison of the features of those technologies that are designed primarily to describe the capabilities of a device, whereas Table 2 below provides a similar comparison for those technologies that describe the capabilities of a service. The list of features represents the characteristics of the technologies that are important when considering the requirements identified on page 6. A good service description must have a clear syntax (such as, how to call the function that represents the service) and well defined semantics (such as, what the service does) [22]. Using a label to describe the capability of a service or device is insufficient. It relies on a common shared context (such as a common understanding of terms) to interpret the description. This may be adequate for a human readable description of capabilities (where it is assumed the readers share a common understanding of terms) but is insufficient when it comes to using a machine to interpret the terms, unless the machine has access to that shared understanding. Of the technologies described above, all meet the first requirement: the syntax for calling the service (or operating the device) is well defined. However, most fail to provide well-defined semantics. Most of the technologies described above share a common feature: the terms that are used in the description of the device or service have to be agreed out-of-band, that is, the agreement has to be reached before runtime and in some cases before design-time. In the languages group, it is only CC/PP and FIPA that provide a means of specifying the semantics of the language and extending it. In the protocols group, the mechanisms tend to be based on ad hoc representation schemes which rely heavily on standardisation (by identifying all those things you would want to communicate or discuss [9]). It is only JXTA and OWLS in this second group that do not rely on an out-of-band agreement.13 Finally, it is important to note that the protocols (and their languages for description) that are associated primarily with device discovery all share a common feature: optimisation for a WTN. They recognise that they

13.It could be argued that UPnP should be added to this small list, due to its provision of an XML document to describe the device. However, according to the current UPnP standard, it is not possible to use this XML document when attempting to discover a device based on capability criteria.


13

14


Yes

Yes

No

Yes

Yes

No

No

No

Yes

Yes

No

Extensible attributes

Unambiguous attributes

Restricted set of devices supported

Attributes require agreement by consortia

Description based on class or type

Requires a priori, out of band agreement

Assumes network connectivity

TABLE 1. Device-Oriented

Independent

Independent

Programming Language

Yes

Yes, but can be agreed at design-time.

Yes

No

No

Yes

Yes, via Java interfaces/ classes

Java

Independent

Service Discovery Protocols

No

No

No

IEEE1394

Independent

Network Transport

Sun Microsystems

The HAVi Organization

Bluetooth Consortium (originated by Motorola)

Developer

Jini

HAVi

Bluetooth

Feature

Yes

No, can be agreed at runtime.

No

No

No

No

Yes, via Advertisements

Independent

Independent

Sun Microsystems

JXTA

?

Yes

Yes

Yes

Yes

?

?

Independent

Independent

Salutation Consortium

Salutation

No

Yes, but can be agreed at design-time.

Yes

Yes

No

No

Only for local installations, otherwise has to be agreed with IANA.

Independent

TCP/IP

IETF

SLP

No

Yes

Yes

Yes

Yes

No

Yes

No.

Yes

No

No

No

Not easily, requires registration with UPnP Forum No

Independent

USB

USB Implementers Forum, Inc.

USB

Independent

TCP/IP

UPnP forum (lead by Microsoft)

UPnP


Proposed Framework for Capabilities Description

are operating in a constrained environment and are heavily optimised to reduce bandwidth and the computation load on the device. Thus the protocols tend to be very terse and reflect the trade-off that has been made between space and extensibility or flexibility. Web Services Architecture

Feature

CORBA

OWL-S

RMI

Developer

Object Management Group

DARPA

Java (lead by Sun Microsystems)

W3C/OASIS

Network Transport

TCP/IP

Independent

IP

TCP/IP

Programming Language

Independent

Independent

Java

Independent

Extensible attributes

No

Yes

No

Yes, via WSDL

Unambiguous attributes

No

Yes

No

No

Restricted set of devices supported

NA

NA

NA

NA

Attributes require agreement by consortia

No

No

No

No

Description based on class or type

No

No

No

No

Requires a priori, out of band agreement

Yes

No, can be modified at runtime

Yes

Yes, at design time.

Assumes network connectivitya

No

Yes

No

Yes

TABLE 2. Service

Discovery Protocols

a. Network connectivity is required for configuration.

Proposed Framework for Capabilities Description None of the approaches described in the previous section meet our needs completely, as they all have disadvantages. However, OWL-S seems to be the most promising due to its view of services. The disadvantage of OWL-S is that it does not provide a means of specifying the syntax of a service—it leaves that to a “grounding” whose role is to provide details about transport protocols, how to interoperate with a service via messages and generally how to access the service. Other researchers have published experiences of combining OWL-S with


15


UPnP or WSDL groundings to describe the syntactic functionality of a device or service, respectively [44] [45]. Hence, when combined with a suitable grounding, it seems that OWL-S meets the requirements identified on page 6.14 In addition, by modelling a service, rather than a device, OWL-S provides a uniform abstraction that can be used to model both—this in turn opens up the possibility of using OWL-S to describe the capabilities of a virtual device which is itself a combination of several physical devices. By using OWL-S, the capabilities of a device can be described using terms from an ontology, thus providing extensibility and a transparent vocabulary whose terms are clearly defined. In practical terms, there needs to be a way of associating a physical device with its description. We believe that, following the philosophy of the TEDS and UPnP approaches, this association can take two forms: • The device contains an embedded identifier. The identifier (such as

an Electronic Product Code15) is translated in a similar fashion to the mechanism provided by the Auto-ID Object Name Service [49] to produce a URI. The URI, in turn, resolves to an OWL document that provides a complete description of the capabilities and services offered by the device. • The device has its own description on board (for example in EEPROM).16 The device may also have an embedded identifier, which can be used as described above to ensure that the description of the device is current. This form is useful if the WTN is disconnected from the wider network. However, depending on the size of the description, this form may not be appropriate for small devices. We believe that the OWL-S approach can be combined with our complementary efforts that are investigating the use of a visual workspace (called EpsilonWorld) as the means of configuring a WTN. Each physical device is represented on the workspace by a Java object acting as its proxy. A proxy provides a visual representation of the state of its counterpart device: sensed value for sensors, on/off/level state for actuators, and other properties of the device and/or service. In addition, a proxy manifests the functional capabilities of the real device to the user and provides access methods to allow other objects to interact with the device. If it is not possible to determine the capabilities of a device automatically via an ID or via an on-board description, then it may be

14.There is ongoing research activity to explore the applicability of OWL-S to other domains, such as bioinformatic grids. For more information see [48]. 15.http://www.epcglobalinc.org/ 16.There is a belief in much of the Semantic Web community that ontologies will be embedded into IT products by 2007-2010 [50].

16



possible to provide the user with the option of manually specifying the device’s capabilities to the proxy. We envisage that the capabilities of a device will be based on the class of the device, that is, the device model rather than the individual device itself. However, with the introduction of smarter devices, this constraint may disappear because a device may be able to have its functionality customised. One goal of EpsilonWorld is to provide developers with a means of browsing the set of currently-available devices according to the capabilities they offer. We envisage a scenario in which the devices’ capabilities, expressed in OWL, are classified in a hierarchy and presented as a directed graph from which the user can select a particular device that offers a service. The hierarchy is produced by using a reasoning engine to classify the OWL descriptions. Thus the use of OWL-S transforms the discovery/browsing process to an ontology reasoning process. FRAMEWORK

The use of OWL-S enables the construction of a framework for the exploitation of capability descriptions to fulfil the needs of the scenario outlined above. Much of this framework has been prototyped and is described in more detail in the Appendix. Here, we present a plan of requirements for the framework: 1.

2.

3.

A description of services. The description should be provided by the manufacturer of the device(s) and will be used by the installer of the devices to assist with their configuration. The document forming the description should be identified by a URI and be made accessible from the internet, for example at http://www.transducers-r-us.com/ transducer-terminology.owl. The Appendix contains an example of such a description appropriate for the UbiComp Door Bell demonstration [51]. A manufacturer’s view of the services provided by a device may not align with the view required by an installer. In this case the installer may wish to provide an alternative description. The document that forms this description should also be identified by a URI, for example http://research.sun.com/anteater/services.owl. The Appendix contains an example of such a description on page 21. If necessary, a description of the bridging axioms may be required to map between the documents identified in steps #1 and 2 above. The bridging axioms may also be required if devices from more than one manufacturer are used in the WTN. The purpose of these axioms is to integrate the descriptions into one unified model. The document forming this description should also be made available as a URI, such as http://research.sun.com/anteater/honeywell-bridging.owl. The axioms may represent simple synonymy, or more complex relationships between the services. (It may be possible to use the WordNet17 lexicon to suggest mappings for simple cases.)


17


4.

A description of the services provided by a class of device. This description should also be produced by the manufacturer of the device to be used by the installer. The description should use the vocabulary identified in point 1 above. (It is likely that the services provided by a device would be described in a single document; however, on page 22 of the Appendix we have provided a single example document that describes the services of all the device classes). This document should also be made available as a URI, for example, http://www.transducers-r-us.com/light-switch-modelxyz.owl. Alternatively, if a device has sufficient storage, this description could be embedded within the device.

5.

6.

A description of the device, provided by the device itself. This description would be used by the installer to identify the type of the device. An example of such a description is provided in the Appendix on page 23. A document that provides a syntactic description of the services provided by the device (known as a “grounding” in OWL-S). This description identifies how to interact with the device.

There are two steps required to enable this scenario and exploit the power of using OWL-S: 1.

2.

Start-up: create an ontology that imports the documents identified 13 above. Device discovery: retrieve the OWL documents that identify the device and the services it provides (corresponding to documents #4 and #5 above). This is achieved as described earlier: discover the ID of the device, and retrieve its description from the internet (or retrieve the description from the device itself). Import that document into the ontology created in step 1. Repeat for each device discovered.

The resulting ontology can then be used in two ways: • To answer the question “Given a device, what can I do with it?” This

relies on classifying the device’s capabilities in the ontology and indicating to the user what “kind” of thing it is. (For example, indicating its capabilities in a graph as shown in the Appendix in Figure 3 on page 28.) Answering this question may also require some lower-level description of the device in terms of its I/O types, commands, etc. (In a web service world this description would correspond to WSDL.) • To answer the question “Given a application requirement, how can I fulfil it?” This appears to be the more interesting research question which suggests two possible answers: 1.The current solution as shown in the Appendix in Figure 2 on page 27 is to present the user with a tree/graph of the 17.http://taurus.unine.ch/GroupHome/knowler/wordnet.html

18



capabilities of the devices and get him/her to determine how to meet the application requirements. Within EpsilonWorld, the user then “wires” the devices’ proxies together to compose the services offered by the devices. 2.A more intriguing idea is to express an application’s requirements in the form of a “plan” or “workflow” and use software to automatically fulfil the needs of the plan given the existing capabilities of the devices available. If there are no devices capable of fulfilling the plan, then the software might recommend that the user purchases a device with appropriate capabilities. For example, assume that it is possible to represent a home heating system as a plan. Such a plan would include the requirements of the system, in terms of the rules and constraints that describe the temperature settings required for each room in the home, in addition to the times at which each temperature is required. Given such a plan, it might be possible to determine if the capabilities of the devices currently in the home are sufficient to meet the requirements of the plan. For example, a temperature sensor may be required to report its value within an accuracy of plus or minus two degrees celsius to meet the needs of the plan. If the home does not contain a device with that capability, then the needs of the plan cannot be met.18

As shown in the Appendix, we already have the ability to create much of this framework. In particular, through the use of tools such as Protégé.19 we are able to create all of the necessary OWL-S descriptions. We have already created example documents that describe the devices and services in the UbiComp scenario (richer examples of documents #4 and #5 are available from the University of Maryland’s MindSwap research group20). In addition, as a result of our collaboration with the WonderWeb Project.21 we also have software to create an ontology by importing all the descriptions of the devices and their services, However, we do not yet have a mechanism for retrieving an ID from a device, and thus cannot associate a device with its description. In the Appendix we provide an example in which this obstacle is ignored and import the description of a device into the ontology. We then classify that ontology using the publicly-available reasoning engine known as Racer.22 Due to a change in focus in the Anteater project, the remainder of this framework (such as a mechanism to exploit plans) is no longer being actively pursued. However, we believe that as a proof of concept

18.See [44] for examples of planning to assist with web service composition. 19.http://protege.stanford.edu/ 20.http://www.mindswap.org/2004/owl-s/index.shtml 21.http://wonderweb.semanticweb.org 22.http://www.cs.concordia.ca/~haarslev/racer/


19

Conclusion

implementation of the framework we have demonstrated that the OWLS approach is useful and worthwhile. We anticipate that it will provide a useful research platform from which to explore the issues of end users employing capability descriptions to assist them in installing and maintaining a WTN.

Conclusion A key ingredient to the success of future WTNs is their simple configuration and installation. We believe that one way to significantly simplify configuration is to provide a rich description of a transducer’s capabilities. In this paper we have presented the requirements for a language that can express those capabilities. The most important of those requirements are that the language be: • semantically well-defined • unambiguous • extensible • negotiable at run-time • machine processable

Our survey of existing languages in this field leads us to believe that the Web Ontology Language OWL best meets these requirements when used within the OWL-S architecture. We have also presented a framework to exploit the capability descriptions expressed in OWL.We believe that a framework based on OWL-S, combined with the EpsilonWorld environment, will result in a tool that enables a user to easily configure the functionality of a WTN.

Appendix We undertook an experiment whose goal was to demonstrate the ability to browse the capabilities of a set of transducers from two perspectives: • What services are available, and which transducers provide those

services? • What transducers are available, and what services do they provide? To perform the experiment we created several documents to describe the services in the UbiComp Door Bell scenario [51]. In addition, two visual browsers were developed—these employed the functionality provided by the Java API and implementation for OWL.23

20


Appendix

The experiment was a success—the sections below describe the artefacts we created and the results we achieved. THE ONTOLOGIES

The experiment relies on several documents that describe: • a set of services • a set of service-providers • a set of transducer classes • a set of transducers

Each of these is expressed as an ontology, using the RDF presentation syntax24 of the web ontology language OWL. Each ontology is identified by a URL. This section describes each of the ontologies in turn. Services Services are described in the Service ontology. Five classes are introduced, in the following hierarchy: Service NotifyingService BuzzingService FlashingService MessageSendingService

In a real world example in which the ontology would be provided by the manufacturer or vendor of devices, the set of services is likely to be much larger, their descriptions richer and the relationships between services would be more complex, using OWL properties to represent constraints, etc. However, for the purposes of this experiment, the hierarchy above is sufficient. A snippet of the service ontology is presented in Listing 1 below. (The ontology contains two annotation properties: rdfs:label and rdfs:comment to describe each class using natural language—these are omitted for brevity.) Service Providers The classes described in this ontology represent the functionality offered by a transducer, and the constraints that need to be fulfilled for a transducer to be said to offer that functionality. For example, we can say that if and only if a transducer provides a FlashingService then it shall be classified as a Flasher. The classes are not arranged in a hierarchy, but instead each transducer class uses the property provides (from the OWL-S ontology) to identify the service it provides. We then rely on a reasoning engine to classify the service providers into the correct

23.http://sourceforge.net/projects/owlapi 24.http://www.w3.org/TR/2003/NOTE-owl-xmlsyntax-20030611/


21

Appendix

Listing 1.

Ontology of Service Providers

hierarchy. The service providers and the services each provides is as follows: Notifier—provides—NotifyingService Buzzer—provides—BuzzingService Flasher—provides—FlashingService MessageSender—provides—MessageSendingService

In a real world example in which the ontology would be produced by someone wishing to use devices from multiple vendors, these relationships are likely to be significantly more complex. Here we are concentrating on the significant relationships that are necessary to produce a working example. (This ontology imports the Service ontology described above.) A snippet of this ontology is providedin Listing 2below. Listing 2.

Description of MessageSender

Transducer Classes The Transducer ontology is also likely to be produced by a vendor or manufacturer of devices. It contains descriptions of several different kinds of transducer. Each transducer is described as providing zero or more of the services described in the services ontology—for this example, only the actuators are described as providing services. The transducer ontology makes no reference to the Service Providers ontology (such as describing a transducer as a flasher), as we can use a reasoning engine to classify the transducers using the constraints

22


Appendix

provided in the Service Providers ontology. However, the transducer ontology arranges the subclasses of Transducer in a simple hierarchy. The transducer hierarchy (and the services each provides) is as follows: Transducer Actuator Mobile/Cell Phone (MessageSendingService, FlashingService, Buzzing Service) Lamp (Flashing Service) Spot Lamp Ambient Lamp Window Control Curtain Closer Sounder (BuzzingService) Garden Water Fountain Furnace Digital Radio (MessageSendingService) Television Intercom (MessageSendingService) Sensor Mobile/Cell Phone Thermostat Door Push Motion Sensor

Other than annotation properties describing each transducer in natural language terms, no other descriptions of the transducers are provided. In a real world example, we would expect to see a transducer described using properties such as location, mechanism and possibly elements from the SensorML schema. (This ontology imports the service providers ontology.) A snippet of the transducer ontology is provided in Listing 3. Devices For ease of experimentation each device (transducer) is described in its own ontology, which in turn imports the transducer classes ontology. Each ontology consists of a snippet of RDF identifying the device, giving it a label and a comment. For example, one of the ambient lamps is described thus: Study lamp With diffuser

This identifies AmbientLamp1 as being an individual of the AmbientLamp class, and provides the individual with a label and a comment. The contents of these latter two elements are used in the user interface shown later.


23

Appendix

Intercom Actuator Transducer Listing 3.

24

Snippet of the Transducer ontology


Appendix

CLASSIFYING

Given the above ontologies, the reasoning engine Racer is able to classify the Transducer classes thus: Notifier Flasher Lamp Spot Lamp Ambient Lamp Mobile/Cell Phone Buzzer Sounder Mobile/Cell Phone Message Sender Digital Radio Mobile/Cell Phone Intercom

From this tree we can see that the reasoner has correctly classified the Transducer classes according to the services they provide. (Note that not all the transducer classes are displayed here, only the ones that were described as providing one or more services.) BROWSING

In Figure 1 we present a schematic that represents the relationships between the ontologies and the software that was used. As illustrated in the top of the figure there is a transitive imports relationship between the three ontologies that describe the device classes and their services. Furthermore, each device description imports the transducers ontology. The software we developed, based on the Java OWL API, creates an inmemory representation of an ontology that describes all of the devices (rendered in grey in Figure 1) including the ontologies they import. This in-memory representation communicates with the Racer reasoning engine via an HTTP connection. Racer provides a means of classifying the ontology and responding to requests about its structure. Example requests include: a request for all the individuals in the ontology (corresponding to the devices); a request to identify the class of an individual; a request to identify the individuals that are a member of a given class. To meet the needs of the goals of our experiment we built two user interfaces (UIs). Figure 2 illustrates the UI that presents a tree of services to the user along with the transducers that provide each service. The tree of services is organised similar to the tree above. The righthand pane of the UI contains the set of individual devices that are instances of the class selected by the user in the left-hand pane. Figure 3 provides the alternative approach: browsing the devices to discover the services they provide. The set of devices is displayed in a list in the left-hand pane, and the right hand pane contains the services provided by the individual device selected in the left-hand pane.


25

Acknowledgements

A schematic of the relationships between the ontologies and the reasoning engine FIGURE 1.

Acknowledgements I thank my colleagues in the Anteater team for their contributions to the ideas represented in this document, in particular Bill Bush, Bo Begole, John Nolan and Roger Meike.

References 1.

2.

3.

4.

26

Droms, R, Dynamic Host Configuration Protocol (RFC2131). (http:/ /www.ietf.org/rfc/rfc2131.txt?number=2131, 199) Apple Computer Technology Brief—Mac OS X: Rendezvous (http:// www.apple.com/macosx/pdf/ Panther_Rendezvous_TB_10232003.pdf) An Overview of the IEEE 1451.4 Transducer Electronic Data Sheet (TEDS) (http://zone.ni.com/devzone/conceptd.nsf/webmain/ 2B71D966B0E41FB586256D9B0068BCBC) Botts, M and McKee L. A Sensor Model Language: Moving Sensor Data onto the Internet, Sensors Magazine, April 2003.


References

FIGURE 2.

Browsing the Services offered by a set of Transducers O'Sullivan, D. and Lewis, D. Semantically driven Service interoperability for pervasive Computing. International Workshop on Data Engineering for Wireless and Mobile Access, Proceedings of the 3rd ACM international workshop on Data engineering for wireless and mobile access San Diego, CA, USA, 2003, 17-24. 6. Lukkien, J.J. et al. Service Discovery Mechanisms: Two Case Studies, In: proceedings of the 2002 International Conference on Parallel and Distributed Processing Techniques and Applications, June 24-27, 2002, Las Vegas, USA, 1187-1192. 7. Humble, J et al. “Playing with the Bits”: User-configuration of Ubiquitous Domestic Environments, UbiComp 2003, 2003. 8. MIME Types (Multipurpose Internet Mail Extensions), Part Two: Media Types, November 1996. (http://www.ietf.org/rfc/rfc2046.txt) 9. Lassila, O. Serendipitous Interoperability, in Eero Hyvönen (ed.), The Semantic Web Kick-Off in Finland—Vision, Technologies, Research, and Applications, HIIT Publications 2002-001, University of Helsinki, 2002. 10. Newman, M.W., et al. Designing for Serendipity: Supporting EndUser Configuration of Ubiquitous Computing Environments. Proceedings of Designing Interactive Systems (DIS), 2002, 147-156. 5.


27

References

FIGURE 3.

Browsing the transducers (and viewing the services they provide) Balazinska, M., Balakrishnan, H.and Karger, D. INS/Twine: A Scalable Peer-to-Peer Architecture for Intentional Resource Discovery. In Proceedings of Pervasive 2002. 12. Composite Capability/Preference Profiles, W3C Working Draft 28th July 2003 (http://www.w3.org/TR/CCPP-struct-vocab). 13. Foundation for Intelligent Physical Agents (FIPA), FIPA Device Ontology Specification (http://www.fipa.org/specs/fipa00091/ SI00091E.html). 14. J2EE Client Provisioning (JSR 124), An Overview of JSR 124: J2EE Client Provisioning (http://wireless.java.sun.com/midp/articles/ provisioning/). 15. http://www.w3.org/RDF/ 16. Sensor Model Language (SensorML) for In-situ and Remote Sensors, Open GIS Consortium Inc., 2002-12-20, Reference number: OGC 02-026r4; Version: 0.7. (http://www.opengis.org/docs/ 02-026r4.pdf) 17. IEEE Standard for a Smart Transducer Interface for Sensors and Actuators—Transducer to Microprocessor Communications 11.

28


References

Protocols and Transducer Electronic Data Sheet (TEDS) Formats. [IEEE1451.1], Approved 16 September 1997. 18. Berners-Lee, T, Fielding, R and Masinter, L, Uniform Resource Identifiers (URI): Generic Syntax (RFC2396). (http://www.ietf.org/ rfc/rfc2396.txt) 19. National Marine Electronics Association (USA) Standard 0183, Standard for Interfacing Marine Electronic Devices, Version 3.01, 1st January 2002. 20. TinySchema; Managing Attributes, Commands and Events in TinyOS, Version 1.1, September 2003. (http:// telegraph.cs.berkeley.edu/tinydb/tinyschema_doc/index.html) 21. Bettstetter, C. and Renner, C. A Comparison Of Service Discovery Protocols and Implementation of the Service Location Protocol, in Proceedings of 6th EUNICE Open European Summer School: Innovative Internet Applications, 2000. 22. Sen, R., et al. Service Oriented Computing Imperatives in Ad Hoc Wireless Settings. Technical Report, Washington University, Department of Computer Science, St. Louis, Missouri, 2004. 23. Bluetooth version 1.2 Core Specifications, Volume 3, part B, Version 1.2, adopted 5 November 2003. (http://qualweb.bluetooth.org/ Content/ DownloadExecute.cfm?RevisionHistoryID=670&FileName=Bt_Cor e_Spec_v1_2.zip) 24. Specification of the Home Audio/Video Interoperability (HAVi) Architecture. Version 1.0 January 18, 2000. (http://www.havi.org) 25. Jini Architectural Overview, 1999 (http://wwws.sun.com/software/ jini/whitepapers/architecture.pdf). 26. Jini Lookup Attribute Schema Specification (http://wwws.sun.com/ software/jini/specs/jini1.2html/schema-spec.html) 27. Project JXTA v2.0: Java™ Programmer's Guide, May 2003. (http:// www.jxta.org/docs/JxtaProgGuide_v2.pdf). 28. JXTA v2.0 Protocols Specification, Rev 2.0, February 27, 2003. (http://spec.jxta.org/nonav/v1.0/docbook/JXTAProtocols.html). 29. Salutation Architecture Specification (Part-1), Version 2.0c, June 01, 1999. (http://www.salutation.org/spec/Sa20e1a21.pdf). 30. Service Location Protocol, http://www.ietf.org/rfc/rfc2608.txt (version 2). June 1999. 31. Service Templates and service: Schemes (ftp://ftp.rfc-editor.org/innotes/rfc2609.txt). 32. Barbeau, M. Mobile, Distributed, and Pervasive Computing, in: Stojmenovic I. (ed), Chapter 27 - Handbook of Wireless Networks and Mobile Computing, John Wiley and Sons, Inc., February 2002, pp. 581-600. 33. Universal Plug and Play Device Architecture (UPnP™), (Version 1.0). 08 Jun 2000. (http://www.upnp.org/download/ UPnPDA10_20000613.htm)


29

References

Universal Serial Bus Specification, Revision 2.0 April 27, 2000. (http://www.usb.org) 35. OMG Naming Service Specification, September 2002, version 2.02. (http://www.omg.org/cgi-bin/doc?formal/02-09-02) 36. Java Remote Method Invocation (RMI) JDK1.4. (http:// java.sun.com/rmi) 37. Java Naming and Directory Interface™. (http://java.sun.com/jndi) 38. Web Services Architecture, W3C Working Draft, 8 August 2003. (http://www.w3.org/TR/2003/WD-ws-arch-20030808/). 39. Web Services Description Language Version 2.0 Part 1: Core Language, W3C Working Draft 10 November 2003. (http:// www.w3.org/TR/2003/WD-wsdl20-20031110/) 40. Devices Profile for Web Services. A Proposal for UPnP 2.0 Device Architecture. (http://msdn.microsoft.com/library/en-us/dnglobspec/ html/devprof.asp) 41. UDDI Technical White Paper, September 2000. (http:// www.uddi.org) 42. UNSPSC, Universal Products and Services Classification Implementation Guide. Electronic Commerce Code Management Association Technical Secretariat, June 2001. (http://eccma.org/ unspsc) 43. Kak, R. and Sotero, D. Implementing RosettaNet E-Business Standards for Greater Supply Chain Collaboration and Efficiency. RosettaNet White Paper, 2002. (http://www.rosettanet.org) 44. Hendler, J., Parsia, B. and Sirin, E. Lucy and Pete deal with Mom— implementing the Scientific American Scenario. Demonstration at 2nd International Semantic Web Conference (ISWC2003). (http:// www.mindswap.org/users/hendler/SciAmDemo.shtml) 45. Jiang, G., Chung, W. and Cybenko, G. Semantic Agent Technologies for Tactical Sensor Networks, 2003 SPIE Conference on AeroSense, Apr. 21- 25, 2003,Orlando, Florida. 46. OWL-S 1.0 Release (http://www.daml.org/services/owl-s/1.0/) 47. McGuinness, D. & van Harmelen, F. OWL Web Ontology Language Overview, W3C Recommendation 10 February 2004. (http:// www.w3.org/TR/2004/REC-owl-features-20040210/) 48. Wroe, C. et al. A suite of DAML+OIL ontologies to describe bioinformatics web services and data, International Journal of Cooperative Information Systems special issue on Bioinformatics, March 2003. 49. Auto-ID Object Name Service (ONS) 1.0. Auto-ID Center Working Draft 12 August 2003. (http://develop.autoidcenter.org/TR/2003/ WD-ons-1.0-20030930.pdf) 50. Ohlms, C. A Perspective on the Market Adoption of Semantic Web Technologies, In Proceedings of AIK-Symposium, 2002, p.17. 51. Horan, B. et al. Ringing the Doorbell—Configuring Sensor Networks, Ubicomp 2004. (http://ubicomp.org/ubicomp2004/ prg.php?show=demos#demo_20) 34.

30


About the Author

About the Author Bernard Horan is a senior staff engineer at Sun Microsystems Laboratories, where he has worked on interactive collaborative environments and Java introspection tools. He is currently working on projects that explore the use of small wireless transducers. Bernard represented Sun in the W3C Web Ontology Working Group. http://research.sun.com/people/mybio.php?uid=37721.


31