- From: Stefan Decker <stefan@db.stanford.edu>
- Date: Thu, 13 Dec 2001 06:01:44 -0800
- 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 UTC