W3C home > Mailing lists > Public > www-webont-wg@w3.org > November 2001

homework - use cases

From: Smith, Ned <ned.smith@intel.com>
Date: Wed, 28 Nov 2001 18:40:18 -0800
Message-ID: <0DCC27458EB5D51181840002A507069E0C312A@orsmsx117.jf.intel.com>
To: www-webont-wg@w3.org
These use cases are derived from scenarios involving management of control
networks  and their integration into corporate LAN or other types of
networks. The use cases are pretty generic in that they could be broadly
applied - ie isomorphic up to naming. Nevertheless, they provide a context
from which to base discussion. I've also asserted some of the requirements,
but anticipate more could be teased out. 

Regards,
Ned

Use Cases:
1) A sensor device manufacturer builds a device that interoperates with
sensor/actuator devices built by other manufacturers. The device properties
are expressed in ontological form. The ontology of device properties or
"device ontology" is embedded in the device. If the device is connected to a
network, it can be recognized by and installed into that network by an agent
that parses the device ontology and determines how best to integrate its
function. Once installed, the device may be bound to other devices forming a
composite device. The composite device, logically a unique device, may
interact with other devices or services on the network. Device manufacturers
are not expected to perform a'priori testing of the possible device
configurations to achieve interoperability. 

2) A legacy control network performs a process that administrators do not
want to disturb. However, they do want to monitor certain functions. They
build an ontology of the control network / process and map monitored
functions into properties of the ontology. Outside services may discover the
control network ontology. Property value changes can trigger notification
events sent to outside services. The monitoring functions may NOT introduce
delays or in any way prevent the control network from performing its task.
The monitoring subsystem may be re-configured by administers periodically
and will not impact the monitored control process.

3) A control network is managed by multiple outsourced management service
providers. Management responsibilities are delegated by the control network
owner to the service providers. Management responsibilities are divided
among the service providers in such a way as to prevent administration
overlap. Management actions are verified to be acceptable prior to their
application. Service providers may re-negotiate how responsibilities are
divided periodically. After which previously granted privileges are lost and
new privileges granted.

Requirements:
1a) The ontology representation language (ORL?) must be simple and concise
enough to represent device properties in a small memory space. Devices range
in complexity - economies of scale suggests the smaller the space required
the better. If the device ontology is unacceptably large, a unique reference
to the ontology must be available.
1b) The device ontology must be linkable with other devices' ontology
forming a distributed ontology with a logical beginning and end /
deterministic traversal method. 
1c) Discrete partitions of an ontology must be recognizable in terms of the
physical boundaries and in terms of logical (composite device) boundaries.
1d) The device is aware of its own ontological properties.
1e) If a composite device has properties in excess of the sum of the
properties of subordinate devices, these properties can be physically
located on multiple nodes.
1f) Device properties may be owned/controlled by multiple entities. The
owner/controller may modify property values.
1g) Both property type and value can be changed. Type changes can be
discovered by other services/devices and type semantics can be resolved -
hopefully quickly! 

2a) Properties in an ontology must be associate-able with a
service/function, that supplies the property value. 
2b) Properties must support access preconditions - namely, the monitoring
network should be prevented from  writing, while allowing write by the
control network.
2c) Property values have meta attributes describing data freshness,
polling/event interval or freshness goal, type, acceptable value range(s),
exception conditions. 
2d) Administrative update are access controlled and versioned allowing only
authorized updates and rollback should an update not work as intended. 

3a) Resources in the control network are described by an ontology.
3b) Resource can be managed by different / multiple entities. 
3c) Management responsibility may be delegated.
3d) Managed resources have meta attributes describing management functions -
namely actions, time intervals, audit log, owner/controller/delegate and
synchronization events.

Ned M. Smith
Intel Architecture Labs          Phone: 503.264.2692
2111 N.E. 25th Ave               Fax: 503.264.6225
Hillsoboro OR. 97124            mailto:ned.smith@intel.com
Received on Wednesday, 28 November 2001 21:40:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:57:46 GMT