- From: Leo Obrst <lobrst@mitre.org>
- Date: Thu, 13 Dec 2001 10:59:49 -0500
- To: W3C Web Ontology WG <www-webont-wg@w3.org>
W3C Web Ontology WG: Content Interoperability Use Case
December 13, 2001
The following use case includes descriptions and examples gleaned from
the general mail regarding use cases, but focused purely on the Content
Interoperability Use Case. It also includes points from the rather
limited discussion our use case group has had up to this point. It is
still very sketchy and should not yet be considered a consensus view.
I've used Guus Schreiber's general format for the use case.
Participants:
Leo Obrst lobrst@mitre.org
Pat Hayes phayes@ai.uwf.edu
Dan Connolly connolly@w3.org
Mike Dean mdean@bbn.com
Herman ter Horst herman.ter.horst@philips.com
Deborah McGuinness dlm@ksl.stanford.edu
Raphael Volz volz@fzi.de
---------------------------
SCOPE AND DEFINITION
---------------------------
General Description:
Content Interoperability includes notions such as Semantic
Interoperability and interoperability issues dealing with the
distribution and mapping of content to devices. Semantic
Interoperability is roughly the capability to send and receive content
supported by ontologies across applications with retention of semantics,
the ability to map between different ontologies in a semantics
preserving manner. Other aspects: semantic equivalence, determining the
consistencies between two ontologies, ontology integration and merging.
Included under this use case are:
- semantic mapping from database schemas to ontologies
- semantic mapping from taxonomies and classification systems to
ontologies
- semantic mapping from ontologies to ontologies
- ontology partitioning and decomposition as the flip of ontology
integration and ontology merging
- ontology language extensions to support mapping ontologies
- electronic commerce standards and catalog mappings using ontologies
- dynamic composition of web services supported by independent
ontologies
- construction of an ontology "view" or presentation based on the needs
of a user, application, specific task using an ontology or ontologies,
and a device
- translating between ontologies
Content Interoperability Subtasks:
- conceptual search to support ontology mapping
- versioning issues: once mappings are created, are they saved, are they
updated, what about when the ontologies themselves change over time
- support in the ontology language for user, task, application view and
context descriptions, constructions
---------------------------
USE CASE DESCRIPTIONS (all are excerpted from email messages)
1.
CONTRIBUTOR: Mike Dean
TASK: Automate tasks relating to travel requiring interacting ontologies
and usable by palm pilot device
DESCRIPTION:
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
[1] http://www.daml.org/PalmDAML/
[2] http://www.daml.org/2001/06/expenses/
EXAMPLE DOMAIN: Travel
TYPICAL USER: traveler needing to plan and schedule travel
accommodations possibly from multiple devices
WEB ONTOLOGY REQUIREMENTS:
- correlation/mapping/merging of ontologies representing diverse
information sources and services
- distribution of ontology information to different devices, hence issue
of condensation to low bandwidth, etc.
=====
2.
CONTRIBUTOR: Jonathan Dale
TASK: Ontology representation exchange and translation
DESCRIPTION:
Both FIPA and Agentcities are aiming towards the practical application
of
agents and agent technologies, so they are looking at choosing an
ontology
representation language (ORL) from a pragmatic standardisation
perspective.
- 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.
- 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.
EXAMPLE DOMAIN: Intelligent agent communities
TYPICAL USER: end user needing services, intelligent agent developer
WEB ONTOLOGY REQUIREMENTS:
- need to express large ontologies referring to terms in other
ontologies
- need to translate between ontologies
=====
3.
CONTRIBUTOR: Ned Smith
TASK: Management of control networks and their integration into
corporate LAN or other types of networks using ontologies for different
devices and composite devices
DESCRIPTION:
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.
EXAMPLE DOMAIN: Control network management
TYPICAL USER: Control network management administrators and service
providers
WEB ONTOLOGY 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.
=====
4.
CONTRIBUTOR: Stefan Decker
TASK: Support dynamic aspects of device configuration using ontologies
DESCRIPTION:
within LastMileServices:
----------------------------------
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.
We use on ontology language to define device ontologies
(e.g., router and switches)
For capturing the dynamic aspects of device configuration
we have developed a 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: distributed web services, device configuration
TYPICAL USER: web service or device user, web service developer, device
developer
WEB ONTOLOGY REQUIREMENTS:
A compositional ontology-based process and service description language
capable of combining existing services
=====
5.
CONTRIBUTOR: Mike Sintek
TASK: Design a scalable, agent-based middleware for distributed
Organizational Memories (OM) for knowledge management using ontologies,
especially mapping of ontologies across OMs.
DESCRIPTION:
The following are some passages from [1] which describes
the use of ontologies in the FRODO [2] project (and for
Knowledge Management in general).
In the FRODO project, we design a scalable, agent-based middleware for
distributed Organizational Memories (OM).
In knowledge management (KM), it is widely accepted that
ontologies as explicit specifications of conceptualizations
[Gruber91] provide a useful means to facilitate access
and reuse of knowledge. Typical utilization scenarios
comprise discussion groups, search engines,
information filtering, access to non-textual information objects,
and expert-user communication. In the context
of Organizational Memory (OM), ontologies provide a vocabulary for
specifying information resources as well as information needs
in order to evolve from a keyword-based towards a
concept-based information management, indexing, and
retrieval approach. They also form the basis for
knowledge-enhanced or knowledge-assisted search and retrieval.
In these applications, ontologies serve as formally represented
"specifications of discourse in the form of a shared vocabulary".
Such a shared understanding is particularly
important because KM typically deals with multi-actor scenarios.
The vision of knowledge management assumes the comprehensive use of an
enterprise's knowledge, whoever acquired it, whereever it is stored
and however it is formulated in particular. Technical support for
such a vision is often based on *centralized approaches*
which seem well-suited to guarantee that the *complete*
information available is considered. For
instance, in OM reference architecture (see attached figure) derived
from the KnowMore framework, the problem of several
heterogeneous information sources is tackled by the introduction
of a uniform *knowledge description level*: The various
information items are annotated by knowledge descriptions which
are based on an agreed upon vocabulary, namely the information,
enterprise, and domain ontologies. Hence, a centralized view upon
a distributed information landscape is built.
In the FRODO project we aim at extending
the centralized (KnowMore) framework towards a *distributed OM*
scenario, resulting in a need for *domain ontology services*.
This requires facilities for both adding domain
ontologies to an OM and accessing ontology services from other
OMs.
Therefore we propose two types of ontology services: Domain
Ontology Agents (DOA) and Distributed Domain Ontology Agents
(D2OA). Domain Ontology Agents are responsible for ontologies
*within one OM*, Distributed Domain Ontology Agents are
located *between several OMs* and facilitate cross-OM
communication.
So, the task of D2OAs is quite similar to "standard
information integration ontologies" (e.g. mapping services), but
much easier as the sources are already formal ontologies, not just
"any information provider".
Typical questions to DOAs are "What are the subconcepts of
concept A?" whereas D2OAs answer questions like "Which OM
contains concepts like A and B?" or "What does A mean in
OM_y?".
This structure better embraces the inherently distributed nature
of (ontological) knowledge. Not *all conceptualizations* are
shared between *all actors* of the system, but *ontology
societies* are formed with respect to relevant domains. Additional
infrastructure enables communication between these ontology
societies.
[1] http://citeseer.nj.nec.com/450299.html
[2] http://www.dfki.uni-kl.de/frodo/
EXAMPLE DOMAIN: Knowledge management and in particular, Organizational
Memories
TYPICAL USER: end user looking for information in an organization or
across organizations
WEB ONTOLOGY REQUIREMENTS:
- support for mapping between ontologies
- support for answering about multiple ontologies: does the ontology
have concept A?, what does A mean in ontology X?
=====
6.
CONTRIBUTOR: Jeff Heflin
TASK: Context sensitive and inter-domain search on the Web
DESCRIPTION:
- context sensitive web search
- inter-domain web search
- question answering on the Web
EXAMPLE DOMAIN:
TYPICAL USER: User searching the Web
WEB ONTOLOGY REQUIREMENTS:
These requirements describe the features needed by complete Web Ontology
language. I have developed this list over time as a result of lessons I
learned from my experiences with SHOE and DAML+OIL. Some of these
requirements may be out of scope of the WebOnt Working Group, and
instead should be saved for later "layers" of the Semantic Web.
Nevertheless, identifying them now can help us to ensure that design of
the Ontology
layer does not prohibit the addition of them later.
<excerpted:>
management of ontology evolution [HH00, KF01, Hef01 (Section 3.4)]
version numbers or revises relation
semantic backward-compatibility
deprecation
interoperability of heterogeneous ontologies
features for mapping between ontologies
synonyms
including synonyms for individuals!
subclass / superclass
inverse relationships
conjunction, disjunction, implication
arithmetic functions
grouping
string manipulation
procedural attachments?
Java?
management of inconsistency
inconsistency is inevitable in large, distributed systems
need standard meaning in face of inconsistency
ontologies of trust/belief
prioritized conflict handling [GLC99]
assumption-based truth maintenance systems (ATMSs) [dK86]
non-monotonicity
other methods?
scalability
limit expressivity?
expect incomplete reasoning algorithms?
References
[dK86] J. de Kleer. An Assumption-based TMS. Artificial Intelligence,
28(2), pp. 127-162, 1986.
[GLC99] B. Grosof, Y. Labrou, and H. Chan. A Declarative Approach to
Business Rules in Contracts: Courteous Logic Programs in XML. In Proc.
1st
ACM Conf. on Electronic Commerce (EC-99), 1999. (PDF)
[Hef01] J. Heflin. Towards the Semantic Web: Knowledge Representation in
a Dynamic, Distributed Environment. Ph.D. Thesis, University of
Maryland, College Park. 2001. (PDF)
[HH00] J. Heflin and J. Hendler. Dynamic Ontologies on the Web. In:
Proceedings of the Seventeenth National Conference on Artificial
Intelligence
(AAAI-2000). AAAI/MIT Press, Menlo Park, CA, 2000. pp. 443-449. (PDF)
[KF01] M. Klein and D. Fensel. Ontology Versioning on the Semantic Web.
In First International Semantic Web Working Symposium (SWWS'01),
2001. (PDF)
=====
7.
CONTRIBUTOR: Leo Obrst
TASK: Fusion/composition of information from disparate ontologies
DESCRIPTION:
Enable the fusion/composition of information from disparate
ontology modeled sources to a resolved or reference model (for
defense-related command and control decision-making, for example).
EXAMPLE DOMAIN: Defense command and control
TYPICAL USER: Command and control analyst
WEB ONTOLOGY REQUIREMENTS:
- capability of composing information supported by diverse ontologies
--
_____________________________________________
Dr. Leo Obrst The MITRE Corporation
mailto:lobrst@mitre.org Intelligent Information Management/Exploitation
Voice: 703-883-6770 7515 Colshire Drive, M/S W640
Fax: 703-883-1379 McLean, VA 22102-7508, USA
Received on Thursday, 13 December 2001 11:00:20 UTC