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

use-case area summary: Web Services

From: Stefan Decker <stefan@db.stanford.edu>
Date: Thu, 13 Dec 2001 06:01:44 -0800
Message-Id: <5.1.0.14.2.20011213054511.0408e310@db.stanford.edu>
To: www-webont-wg@w3.org
Dear WG members,

Encl. is a first sketch of the  Web Services Use-Case Area.
This text has not yet circulated among the other
area people yet (my apologies).
The HTML-Version of the text (might be easier to read) is
available at:
http://www-db.stanford.edu/~stefan/webont/121301/

All the best,
         Stefan
--

WebOnt Use-Case Area: Web Services


Status: Draft

Version: December 13 2001


Editor

Stefan Decker, Stanford University, stefan@db.stanford.edu


Members

Mike Dean, BBN, mdean@bbn.com
Stefan Decker, Stanford University, stefan@db.stanford.edu
Tim Finin, University of Maryland MIND Laboratory, finin@cs.umbc.edu
Ora Lassila, Nokia Research, ora.lassila@nokia.com
Lynne Thompson, Unisys Corporation, lynne.thompson@unisys.com
Deborah McGuiness, Stanford University, dlm@ksl.stanford.edu



Mailing List
www-webont-wg@w3.org
(Web Ontology Working Group)

www-ws@w3.org
(Web Services)

SCOPE AND DEFINITION:

Specification of processes. Web Services need language for the 
specification of processes, e.g., for the specification of the combination 
of Web Services. In the past Process Ontologies (like for the Process 
Specification Language (PSL)) have been defined. DAML-S and IBM's Web 
Services Flow Language (WSFL) is going into the same direction.

Searching and identfying Web Services on the Web or in P2P environments 
requires the description of capabilities

The automated configuration of Services and Devices. Devices (and Services) 
should automagically (without human intervention) find that they can 
meaningfully interoperate even though they were not explicitly designed to 
do so (e.g., built for different purposes, by different manufacturers, at a 
different time, etc.).

Wrapping of Legacy Services. Ontologies can provide a mechanism to connect 
legacy services with each other.

Easy Integration of Information provided by different services.



Requirements:

Properties in an ontology must be associate-able with a service/function, 
that supplies the property value
(use case 1).

Properties must support access preconditions - namely, the monitoring 
network should be prevented from writing, while allowing write by the 
control network. (use case 1).

Property values have meta attributes describing data freshness, 
polling/event interval or freshness goal, type, acceptable value range(s), 
exception conditions. (use case 1).

Administrative update are access controlled and versioned allowing only 
authorized updates and rollback should an update not work as intended (use 
case 1).

Properties in an ontology must be associate-able with a service/function, 
that supplies the property value. (use case 2).

Properties must support access preconditions - namely, the monitoring 
network should be prevented from writing, while allowing write by the 
control network. (use case 2).

Property values have meta attributes describing data freshness, 
polling/event interval or freshness goal, type, acceptable value range(s), 
exception conditions. (use case 2).

Administrative update are access controlled and versioned allowing only 
authorized updates and rollback should an update not work as intended (use 
case 2).



Resources in the control network are described by an ontology. (use case 3).



Resource can be managed by different / multiple entities.(use case 3).



Management responsibility may be delegated.(use case 3).



Managed resources have meta attributes describing management functions - 
namely actions, time intervals, audit log, owner/controller/delegate and 
synchronization events.(use case 3).



We expect the modelers to be people not familiar with Knowlege 
Representation. Thus the language needs to be intuitive understandable and 
easy to visualize .(use case 4).

Third Party vendors are expected to write support software. Thus developers 
without a background in Knowledge Representation must be able to use API. 
.(use case 4).

We want to be able to verify, that a modeled device complies with the 
constraints defined in the ontologys .(use case 4).

Complexity; how easy is the ORL to learn, use and implement. (use case 9).

Size; how big is the ORL and can its functionality be divided into useage
layers. (use case 9).

Suitability; what specific problems does the ORL address and what
problems is it best/worst suited to handle. (use case 9).

Adoption; what is the target audience of the ORL and who is likely to
adopt its useage. (use case 9).





Published Use Cases

No 1.
CONTRIBUTOR: "Smith, Ned" <ned.smith@intel.com>
URL: http://lists.w3.org/Archives/Public/www-webont-wg/2001Nov/0122.html

CONTRIBUTOR: Ora Lassila daml@lassila.org
URL: http://lists.w3.org/Archives/Public/www-webont-wg/2001Dec/0022.html

TASK: Device/Service Interoperability/Automated Configuration

Use Cases:
A device (sensors, cell phones, printers) 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..

EXAMPLE DOMAIN:
Service and Device Interoperability.


TYPICAL USER:
Device Developers and Standardization Consortia

ONTOLOGY SAMPLES:



WEBONT REQUIREMENTS:

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.

The device ontology must be linkable with other devices' ontology forming a 
distributed ontology with a logical beginning and end / deterministic 
traversal method.

Discrete partitions of an ontology must be recognizable in terms of the 
physical boundaries and in terms of logical (composite device) boundaries.

The device is aware of its own ontological properties.

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. Device properties may be owned/controlled by multiple 
entities. The owner/controller may modify property values.

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!



No 2
CONTRIBUTOR: "Smith, Ned" <ned.smith@intel.com>
URL: http://lists.w3.org/Archives/Public/www-webont-wg/2001Nov/0122.html

TASK: Ontology-based Wrapping of legacy services

Use Cases:

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.

EXAMPLE DOMAIN:
Network Monitoring

TYPICAL USER:


Network Adminstrators ONTOLOGY SAMPLES:



WEBONT REQUIREMENTS:

Properties in an ontology must be associate-able with a service/function, 
that supplies the property value.

Properties must support access preconditions - namely, the monitoring 
network should be prevented from writing, while allowing write by the 
control network.

Property values have meta attributes describing data freshness, 
polling/event interval or freshness goal, type, acceptable value range(s), 
exception conditions.

Administrative update are access controlled and versioned allowing only 
authorized updates and rollback should an update not work as intended





No 3
CONTRIBUTOR: "Smith, Ned" <ned.smith@intel.com>
URL: http://lists.w3.org/Archives/Public/www-webont-wg/2001Nov/0122.html

TASK: Distributed Network Management

Use Cases:

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.

EXAMPLE DOMAIN:
Distributed Network Management

TYPICAL USER:
Network Adminstrators

ONTOLOGY SAMPLES:



WEBONT REQUIREMENTS:

Resources in the control network are described by an ontology.

Resource can be managed by different / multiple entities.

Management responsibility may be delegated.

Managed resources have meta attributes describing management functions - 
namely actions, time intervals, audit log, owner/controller/delegate and 
synchronization events.






4.
CONTRIBUTOR: Stefan Decker <stefan@db.stanford.edu>
URL: http://lists.w3.org/Archives/Public/www-webont-wg/2001Nov/0122.html

TASK: Process Description and Device Modeling


LastMileServices is a startup aiming to describe static and dynamic aspects 
of telecommunication devices, with the goal of simplifying service 
construction and configuration of large networks.

The ontology language is used to define device ontologies (e.g., router and 
switches) and to definea service description ontology, which defines 
primitives to declare task decomposition, control flow (using the 
vocabulary of a UML statechart), and data flow of services.
Other primitives enable to create new services by combining and configuring 
existing services.
This results in a compositional ontology-based process and service 
description language capable to combine existing services (given by, e.g., 
distributed Web Services or Java Objects) with the goal to create new 
services.A service description can be compiled to Java code and be executed.


EXAMPLE DOMAIN:
Telecommunication

TYPICAL USER:
Service Designer and Developer

ONTOLOGY SAMPLES:



WEBONT REQUIREMENTS:

We expect the modelers to be people not familiar with Knowlege 
Representation. Thus the language needs to be intuitive understandable and 
easy to visualize

Third Party vendors are expected to write support software. Thus developers 
without a background in Knowledge Representation must be able to use API.

We want to be able to verify, that a modeled device complies with the 
constraints defined in the ontology.s.




5.

CONTRIBUTOR: John Stanton StantonJ@ncr.disa.mil
URL: http://lists.w3.org/Archives/Public/www-webont-wg/2001Dec/0000.html

TASK: "Interoperability between Different Software Products"


Formal methods is not so much meant to focus on formal methods of 
expression as in -
context-free or context-dependent requirements expressed by narrative 
rules; or doing our
own variant of Backus-Naur Form. What I mean is a connected; iterative 
standards development
process that connects the standard under definition; the model; and a 
conformance testing system as they evolve TOGETHER. If all three of these 
elements evolve together in a clearly defined,
intentional process, DOD can save money, and many other wondrous events can 
also occur.

We purchase as much software as a Fortune 50 company. When we encounter a 
product that is 99%
interoperable, the other 1% costs us millions of dollars to transport 
across platforms; or
engineer expensive, weird work arounds that then require expensive 
life-cycle maintenance.

When encountering this 1% non-interoperability, it can often be traced back 
to both the lack of
formal methods of expression within the standard; but most often to the 
absence of an intentional
overall standards development process, exploiting intentional software 
engineering, using iteration
between the three major elements to produce quality; modeled; tested and 
evolved products. So... we
suffer with these products having no way to test conformance; not 
understanding exactly what we have purchased, costing millions of dollars.

EXAMPLE DOMAIN:
Military

TYPICAL USER:
Militery

ONTOLOGY SAMPLES:



WEBONT REQUIREMENTS:

6.

CONTRIBUTOR: Deborah McGuinness (dlm@KSL.Stanford.EDU)
URL: http://lists.w3.org/Archives/Public/www-webont-wg/2001Dec/0032.html

TASK: intelligent interoperable e-commerce and Web services

- intelligent interoperable e-commerce. Use ontologies for all levels of 
support including simple things like integrity checks, more complicated 
support such as ontology merging and mapping to "standard" upper level 
ontologies such as UNSPSC, etc. Simple early versions of this include 
electronic yellow pages such as Directory Westfield. More complicated 
versions of this include real configuration and solutions across 
complicated domains. Early examples of ontology-enhanced configuration 
includes work on PROSE/QUESTAR [5].


- Web services. One of the focuses of KSL, Stanford's research over the 
last 1.5 years has been the confluence of the Semantic Web and Web Services 
-- self-contained Web-accessible programs, and devices, together with 
distributed computing architectures. As with DAML+OIL (in the guise of 
DAML-S), we would like to use WOL to create ontologies of Web Service 
properties and capabilities. Such annotations would be used to automate Web 
service discovery, Web service invocation and Web service composition and 
interoperation. [6]

EXAMPLE DOMAIN:


TYPICAL USER:

ONTOLOGY SAMPLES:



WEBONT REQUIREMENTS:

7.
CONTRIBUTOR: H.J. ter Horst herman.ter.horst@philips.com
URL: http://lists.w3.org/Archives/Public/www-webont-wg/2001Dec/0006.html

TASK: automated adaptation of content (media) presentation to users and the 
context.


Use case:

We assume sensors to exist that conclude which objects (which people, for 
example) are in a certain room/space (a 'simple' way could involve tagging 
the objects). The objects are described in an ontology. Also metadata for 
content is described in an ontology. It is relevant to include information 
involving people's likes and dislikes, concerning media content, for example.
Sensor detection and such descriptions form the basis for drawing 
conclusions about the context (living room, office, mobile situation) and 
to adapt the presentation of content to this context. This may also include 
the specification of actions, for example used to personalize certain 
equipment, possibly in a context-dependent way. A natural connection can be 
made to the subject of collaborative
filtering. Ultimately, it is desirable to allow individual modes of 
expression of user profiles, while being able to make comparisons between 
different user profiles.


EXAMPLE DOMAIN:


TYPICAL USER:


ONTOLOGY SAMPLES:



WEBONT REQUIREMENTS:



8.
CONTRIBUTOR: Nick Gibbins (nmg@ecs.soton.ac.uk)
URL: http://lists.w3.org/Archives/Public/www-webont-wg/2001Nov/0128.html

TASK: Expert Finding

A community of practice is a group of people which are self-selecting by 
virtue of their involvement in some common activity, such as habitual 
co-publication or attendance at similar events. We have been developing 
heuristic techniques for identifying such groups using the structures in an 
ontology. The expert finding task is related to COPs because experts are 
often key participants in the COP related to their
field of expertise. While it is not necessarily the case that there is 
mutual awareness between all members of a COP, we believe that the social 
network which underlies a COP can be used to 'justify' introductions to 
experts within that COP. In both cases, the knowledge which we use to 
identify COPs and experts is defined in terms of an ontology.

Footnotes:
[1] http://www.aktors.org
[2] http://www.w3.org/TR/xlink/


EXAMPLE DOMAIN:

Work Environment/community of practice


TYPICAL USER:


ONTOLOGY SAMPLES:



WEBONT REQUIREMENTS:

9
CONTRIBUTOR: Jonathan Dale (jdale@fla.fujitsu.com)
URL: http://lists.w3.org/Archives/Public/www-webont-wg/2001Nov/0116.html

TASK: Support for agents and agent technologies Use Cases:
Both FIPA and Agentcities are aiming towards the pratical application of 
agents and agent technologies, so they are looking at choosing an ontology 
representation language (ORL) from a pragmatic standardisation perspective:

1. To assist in the ontology modelling exercise. Both FIPA and Agentcities
are closely related to standardisation and one of the key points that
coollaborative ontology modelling promotes is a standarisation of
vocabularies across an application domain or domains.

2. To assist in ontology representation exchange. Initially, we expect that
FIPA and Agentcities will develop ontologies in a human-centric,
collaborative manner since most application domains that they are trying to
define are reasonably small and finite (i.e., bottom up rather than
top-down). However, in the future, it will be important that an ORL can also
express large ontologies and can reference terms in other ontologies,
possibly in other ORLs.

3. To assist in ontology translation. As the nodes in the network of
FIPA-compliant agent platforms increases, so the heterogeneity in the
network increases. FIPA is based on a model of uinting heterogeneity through
interoperability, and a key feature of a suitable ORL should be
like-compatibility with other ORLs. If the functionality is too diverse,
then translation between ORLs will be more difficult.

One of the goals of FIPA will be to probably pick up where the WebONT group
leaves off. That is, FIPA will leave the standardisation of the design
aspects of a suitable ORL to groups like WebONT, but will look at the more
pragmatic aspects of ontologies, such as ontology description definitions,
ontology discovery, ontology translation, etc.

There are other aspects that FIPA is interested in when choosing an ORL,
such as:



EXAMPLE DOMAIN:
Agentcities

TYPICAL USER:
Service Designer



ONTOLOGY SAMPLES:



WEBONT REQUIREMENTS:

Complexity; how easy is the ORL to learn, use and implement.

Size; how big is the ORL and can its functionality be divided into useage
layers.

Suitability; what specific problems does the ORL address and what
problems is it best/worst suited to handle.

Adoption; what is the target audience of the ORL and who is likely to
adopt its useage.



10


CONTRIBUTOR: Mike Dean <mdean@bbn.com>
URL: http://lists.w3.org/Archives/Public/www-webont-wg/2001Nov/0116.html

TASK: Communities of Practice / Expert Findin

Use Cases:
I hope that WebOnt will be used to provide information that's currently 
available on the WWW (and not currently available on the WWW) in such a way 
that I can write and/or use programs to automate tasks such as those 
related to business travel. I'll use that domain as a focus for this
use case.

I generally plan my travel before calling my human corporate travel agent. 
For flights, I use a copy of the United Airlines Electronic Timetable, 
which gets monthly (weekly since 9/11) updates in a some sort of compressed 
binary format (I've made several unsuccessful attempts to extract the 
underlying data). I like the fact that I can work with this offline (e.g. 
on an airplane). I'd much prefer to get it in WebOnt format so that I can 
apply my own preferences, link to other information about airports, etc.

I have a hotel chain that I prefer. For destinations that I frequent often, 
I know their hotels in the area but often forget some of the details (e.g. 
which ones serve good hamburgers, and which room locations to avoid). For 
others, I look up information on their web sites. I'd like to get this 
information in WebOnt format, and to add my own properties for items of 
personal interest.

I normally try to get a hotel room that has high-speed wired or wireless 
Internet access. Hotel web sites are very inconsistent in reporting this 
service. For an unfamiliar property, I generally look at the directories 
maintained by the major ISPs serving hotels (CAIS, STSN, Wayport, and 
MobileStar), none of which currently provide the information in an 
agent-friendly format (most use maps, page hierarchies, and/or PDF). I'd 
prefer to get it in WebOnt and merge it myself with my itinerary and other 
geographic
information.

When I make a reservation, my corporate travel agent emails my itinerary in 
a format that I consider a canonical example of the "un-Semantic Web": a 
PDF image of a traditional FAXed itinerary. This prints well, but is 
virtually impossible for a program to process. I'd prefer to get this 
content using WebOnt, and to have it automatically routed to a personal 
travel agent program. I'd like to automatically share some of my itinerary 
information (e.g. travel dates and arrival times) with my co-workers, but 
keep some of it (e.g. credit card numbers) private.

After my airline ticket is booked, I generally have to call
the airline directly to get an upgrade and/or better seat
assignment. I prefer non-bulkhead (so I can keep my laptop
under the seat in front of me) window seats. United is
unable to track this preference, so I often have to make
several calls. An agent would be better (and more
reliable!) at this task.

I now subscribe to United's Flight Paging Service, which
automatically sends an email message to my pager 2 hours
before my flight or whenever a delay or cancellation occurs.
I'd prefer for my agent to get this information in WebOnt
format so that it could automatically begin identifying
alternative flights and routings when a problem arises.

I also subscribe to a free service from fly.faa.gov, which
sends me email messages on ground stops and delays at
specified airports. Unfortunately, it's not linked to my
itineraries, so I get lots of such messages while I'm not
travelling. If the information was in WebOnt format, my
agent could easily cross-reference it with my itineraries
and identify relevant problems.

While I travel, I'd like to have fast access to my itinerary
using a utility like PalmDAML [1] on my PDA.

When I have a substantial wait at an airport, I like to look
for high-speed Internet access. I've generally had better
luck searching concourses than web pages to find such
services; I'd like to get such information (translated to)
my preferred WebOnt ontology. I sometimes go to the
American Airlines Admirals Clubs to use their high-speed
MobileStar wireless Internet access points. This is usually
in a different terminal, so I'd like to also get WebOnt
information on gate locations and walking times.

When I go to an unfamiliar city, I often try to rent a Hertz
car with a NeverLost GPS. Rather than painstakingly
toggling in the street names and numbers for my hotel and
other destinations, I'd like to just beam the information in
WebOnt format from my PDA using IR or Bluetooth.

I'd also like to get additional information that's not
generally now on the web: service hours for restaurants
(and room service) along my travel route. For flights that
get in late, for example, my agent could tell me if I need
to grab a bite before leaving the airport.

When I return from a trip, I have to fill-out an Excel
spreadsheet for my expense report. Most of this information
could come directly from my itinerary, hotel bills, and
credit card receipts if they were provided in WebOnt format.

I already have a DAML application [2] for reconciling my
expense reports with my credit card statements and checking
account.

A few observations:

1) most of this information (flight schedules, travel
itineraries, hotel addresses, expense reports, etc.) is
not ontologically sophisticated

2) much of the information is already available in
human-readable form

3) automation currently exists only in specific stovepipes
such as United's new Flight Paging Service

4) even a highly-motivated geek finds it impractical to
merge the existing information

5) with widespread use of WebOnt, we should be able to do
most of these things pretty easily

Mike

[1] http://www.daml.org/PalmDAML/

[2] http://www.daml.org/2001/06/expenses/





EXAMPLE DOMAIN:
Travel

TYPICAL USER:
Traveller

ONTOLOGY SAMPLES:



WEBONT REQUIREMENTS:
Received on Thursday, 13 December 2001 09:09:01 GMT

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