W3C home > Mailing lists > Public > www-webont-wg@w3.org > January 2002

Face-to-face: Content Interoperability Use Case final draft

From: Leo Obrst <lobrst@mitre.org>
Date: Mon, 07 Jan 2002 16:21:43 -0500
Message-ID: <3C3A1167.64594252@mitre.org>
To: W3C Web Ontology WG <www-webont-wg@w3.org>
All,

Attached is the final pre-face-to-face draft of the Content
Interoperability Use Case by the subgroup. Please read this for the
meeting. We look foward to discussing your comments, suggestions, or any
additional issues you'd like to raise next week at the meeting. 

Best regards,
Leo
-- 
_____________________________________________
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
W3C Web Ontology WG: Content Interoperability Use Case
January, 07, 2002

0. INTRODUCTION

This document addresses the Content Interoperablity Use Case Category of the 
Ontology Web Language (OWL). Specific use cases related to Content 
Interoperability were obtained from many contributors, and from a number of 
distribution lists and organizations. Because of the large number of specific 
use cases (22), we condensed these into more general use case categories (8). 
The general use case categories, although by definition more abstract, enabled 
us to isolate use case themes, and correspondingly, to categorize requirements 
for a web ontology language.

The structure of the document is as follows:
1. PARTICIPANTS IN THE CONTENT INTEROPERABILITY USE CASE CATEGORY
2. SCOPE AND DEFINITION OF CONTENT INTEROPERABILITY
3. GENERAL REQUIREMENTS FOR AN ONTOLOGY WEB LANGUAGE (AS OBTAINED FROM 19THE USE 
CASES)
4. INDEX OF SPECIFIC USE CASES
5. INDEX OF GENERAL USE CASES
6. GENERAL USE CASES
7. SPECIFIC USE CASES

Because of the large size of this document, it is suggested that readers focus 
primarily on Sections 1-6, with Section 7 (the largest section) acting as a 
detailed appendix. All comments and suggestions are welcomed.

1. PARTICIPANTS IN THE CONTENT INTEROPERABILITY USE CASE CATEGORY

Leo Obrst (chair)  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
Ora Lassila        daml@lassila.org

2. SCOPE AND DEFINITION OF CONTENT INTEROPERABILITY

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
- mapping from ontology classes to ontology instances
- 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
- merging 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
- ability to annotate ontologies with meta-knowledge (and possible reification)

3. GENERAL REQUIREMENTS FOR AN ONTOLOGY WEB LANGUAGE (AS OBTAINED FROM THE USE 
CASES)

This section contains the general requirements for OWL as condensed from the 
general and specific use cases. Following each requirement is a list of the 
general use cases which have that requirement.

3.1 Correlation/Mapping/Merging/Translating Of Ontologies Representing Diverse 
Information Sources And Services
1. Ontology namespaces and inter-ontology references: need to express large 
ontologies referring to terms in other ontologies (A, C, E, F, H)
2. Ontology translation: need to translate between ontologies (A, B, C, E, F, H)
3. Ontology mapping rules, features: able to express semantic mapping rules, 
features between ontologies, establish coreference relations among concepts, 
relations, instances/individuals (A, C, E, F, G, H)
4. Ontology composition language: to enable the composition of information from 
different ontologies (A, E, H)
5. Ontology service composition language: a compositional ontology-based process 
and service description language capable of combining existing services (D, E)
6. Ontology mapping versioning: support multiple versions of mapping relations 
between ontologies (G, all)
7. Ontology query language: support for answering about multiple ontologies: 
does the ontology have concept A?, what does A mean in ontology X? (B, C, D, E, 
H)
8. Inter-ontology synonyms/aliases: express that a concept or 
individual/instance in one ontology is a synonym/alias for a concept or 
individual/instance in another ontology (A, C, E, F, G, H)
9. Inconsistency management: inconsistency is inevitable in large, distributed 
systems, so need standard meaning in face of inconsistency (A, C, E, F, H)
10. Ontology trust: ontologies of trust/belief  (B, C, E)
11. Ontology approximation: mappings between ontologies may require conflict 
handling, assumption-based truth maintenance, non-monotonicity, and the 
expression of relations of approximation (A, C, E, F, G, H)
12. Inter-ontology validation: enable validation, consistency checking services 
between ontologies, tagging of mapped portions of ontologies as being 
consistent, date of consistency check, etc. (F, G, H)

3.2 Support For Device/Resource Interoperability
1. Transmission of ontology information: distribution of ontology information to 
different devices, hence issue of condensation to low bandwidth, memory, etc. 
The ontology representation language 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. (A)
2. Distributed ontologies: the device ontology must be linkable with other 
devices' ontology forming a distributed ontology with a logical beginning and 
end / deterministic traversal method. (A, C, F, G, H)
3. Ontology language support for inter-device communication language (A)
4. Composition: Composition of devices will require composition of ontological 
information (A)
5. Ontology partitions: discrete partitions of an ontology must be recognizable 
in terms of the physical boundaries and in terms of logical (composite device) 
boundaries. (A, F, H)
6. Reflection: the device must be aware of its own ontological properties. (A)
7. Distributed device 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. (A)
8. Ownership: Device properties may be owned/controlled/managed by multiple 
entities. The owner/controller/manager may modify property values. (A)
9. Management delegation: management may be delegated. (A)
10. Resource metadata: managed resources have meta attributes describing 
management functions, namely actions, time intervals, audit log, 
owner/controller/delegate and synchronization events. (A)
11. Device property updating and distribution/remote recognition: both property 
type and value can be changed. Type changes can be discovered by other 
services/devices and type semantics can be resolved quickly. (A)

3.3 Ontology Creation/Management
1. Property value updating: properties in an ontology must be associatable with 
a service/function, that supplies the property value. (B, C, D, E, F, G)
2. Property access conditions: properties must support access preconditions: for 
example, the monitoring network should be prevented from writing, while allowing 
write by the control network. (A, all)
3. Meta-knowledge and reification: support annotation of ontological constructs 
with metadata, reification, etc. For example, property values should have meta 
attributes describing data freshness, polling/event interval or freshness goal, 
type, acceptable value range(s), exception conditions. (B, C, D, E, F, G)
4. Property typing: ability to type properties (e.g. structural, chemical), 
perhaps using 2nd order constructs or meta-classes, reification (C, E, F, G)
5. Time: ability to make time-specific extensions (All)
6. User/developer access and versioning: administrative updates are access 
controlled and versioned, allowing only authorized updates and rollback should 
an update not work as intended. Versioning should include: major, incremental, 
module, node.(B, C, D, E, F, G)
7. Ontology modularization: need modularization principles (enforcing 
interoperability by reuse), partitioning schemes, hierarchical and modular 
structures are supported
8. Ontology scalability: very large and growable ontologies should be enabled. 
(All)
9. Ontology complexity layers: support different complexity layers concerning 
expressive capabilities. (B, C, D, E, F, G)
10. Intra-ontology validation: enable validation, consistency checking services 
on ontologies, tagging of portions of ontology as being consistent, date of 
consistency check, etc. (C, E, F, G)
11. Ontology services: support ontology services for applications, e.g., 
inference, query support, find all concepts having a certain property. (C, E, F, 
G)

3.4 Ontology Views/Contexts, Language Support
1. Presentation vs. representation: distinguish between presentation of 
underlying ontology and its underlying representation (like database view which 
does not change underlying database). This has a relation to access rights, 
i.e., a certain user role can modify underlying logical relationships, another 
role can only modify presentation relationships, etc. (A, C, D, E, F, G, H)
2. Ontology contexts: enable structures, rules for ontologies to be used 
differently, depending on changed context of use: for example, functional sub-
ontology vs. physical sub-ontology (E, F, G)
3. Composition of views/contexts: enable ontology view/contexts to be composed 
(recursively?) (E, F, G)
4. Intra-ontology synonyms/aliases: express that a concept or 
individual/instance in one ontology is a synonym/alias for another concept or 
individual/instance in the same ontology. (A, C, E, F, G, H)
5. Lexical representation: ability to represent a lexical layer within 
ontologies (also for instances). These would be terms associated with concepts 
(F, H, All)
6. Display names: enable different ontological display names, based on context, 
application, language, etc. (F, G)
7. Multi-lingual, multi-cultural support: enable support of ontologies in 
multiple languages, mapping between ontologies in multiple languages. (All)
8. Ontology granularity: enable levels of granularity, depending on needs of 
some context, application (G)
9. Personalization: enable users to personalize ontology with respect to their 
interests, applications (D, F, G)

4. INDEX OF SPECIFIC USE CASES

This section contains a table of the specific use cases (indexed by number) and 
their descriptions.

Use Case/Task Description
1 Automate tasks relating to travel requiring interacting ontologies and usable 
by palm pilot device
2 Ontology representation exchange and translation for intelligent agents
3 Management of control networks and their integration into corporate LAN or 
other types of networks using ontologies for different devices and composite 
devices
4 Support dynamic aspects of device configuration using ontologies
5 Design a scalable, agent-based middleware for distributed Organizational 
Memories (OM) for knowledge management using ontologies, especially mapping of 
ontologies across OMs.
6 Context sensitive and inter-domain search on the Web
7 Fusion/composition of information from disparate ontologies
8 Disseminate an Air Tasking Order (ATO) from one service to another.
9 Serendipitous Interoperability: two (or more) devices find that they can 
meaningfully interoperate.
10 Support pervasive computing across many computing devices
11 Ensuring cooperation among organizational units using different ontologies.
12 Support the co-evolution of a standard, its model, and a conformance testing 
system.
13 Support CAD engineering developers by filtering ontological information based 
on context or "view"
14 Support intelligent interoperable electronic commerce by mapping product and 
service standards
15 Enable disparate organizations and communities, with heterogeneous 
vocabularies, to communicate and interoperate via the use of ontology mappings.
16 Adapt content (media) presentation to users and the context. automatically
17 DAML Combat Support Agent
18 Multi-media generation
19 Annotation of on-line contents
20 FIPA Semantic Framework Mapping: Upper Ontologies
21 FIPA Semantic Framework Mapping: Domain-Specific Ontologies
22 FIPA Information Agents: Information Integration and Fusion

5. INDEX OF GENERAL USE CASES

This section contains a table of the general use cases (indexed by letter), 
their category names, the respective specific use cases they encompass, and a 
brief description. Note that some specific use cases occur in more than one 
general category. 

General Use Case/Category/Specific Use Cases/Description
A Device Interoperability 1, 3, 4, 9, 10 Device adaptation and interoperablity
B Intelligent Agents 2, 5, 20, 21, 22 Ontology representation exchange and 
translation for intelligent agents
C Knowledge Management 5, 11, 15, 19 Ensuring cooperation among organizational 
units using different ontologies
D Intelligent Search, E-commerce 6, 14 Context sensitive and inter-domain search 
on the Web, electronic commerce
E Knowledge Fusion 7, 20, 21, 22 Fusion/composition of information from 
disparate ontologies
F Coevolution of Model, Standard, Testing 12 Support the co-evolution of a 
standard, its model, and a conformance testing system
G Context/view Mapping 13, 16, 18 Support users, developers, and devices by 
enabling an ontological context or "view"
H Command & Control Message Content Interoperability 8, 17 Transmit semantic 
information from one service to another, or across command and control domains

6. GENERAL USE CASES

The following are the general use cases condensed from the specific use cases. 
Each of these general use cases has the following format (though not all fields 
are used):

GENERAL USE CASE LETTER
CATEGORY DESCRIPTION
DESCRIPTION
WEB ONTOLOGY REQUIREMENTS

-----
GENERAL USE CASE: A (1, 3, 4, 9, 10) 

CATEGORY DESCRIPTION: Device Interoperability - Device adaptation and 
interoperability

DESCRIPTION: 
Computing devices must be able to interoperate at the semantic level. These 
devices include PCs, laptops, personal digital assistants (PDA), printers, other 
network devices. These devices can be used for many of the same purposes, for 
example: planning travel arrangements. These devices should be able to use the 
same set of ontologies, as appropriate to the domain, but mapped and customized 
to their particular requirements, which may include limited bandwidth, memory, 
etc. 

In addition, devices should be able to adapt semantically to a dynamically 
changing environment, as for example, when a new printer is added to an existing 
network of devices, or when a PDA is brought into a new location having 
different computing, access, and security requirements. 

Finally, devices may be controllable by web services, which can represent task 
decomposition and control flow using ontologies.

EXAMPLE DOMAIN:  Travel planning, device and network configuration and 
management, distributed web services

TYPICAL USER:  Travel planner, device/network manager, device user

WEB ONTOLOGY REQUIREMENTS:

-----
GENERAL USE CASE: B (2, 5, 20, 21, 22)

CATEGORY DESCRIPTION: Intelligent Agents - Ontology representation exchange and 
translation for intelligent agents

DESCRIPTION: 
Intelligent agents are an emerging software paradigm on the Web. Various agent-
based standards require the use of an ontology language (FIPA, Agentcities, 
etc.). This language must support ontology representation exchange (from 
multiple ontologies) and ontology translation (from one ontology to another). In 
addition, the ontologies which are to be exchanged or translated may be use by 
different agent platforms/infrastructures/domains (e.g., a FIPA agent exchanging 
with an Agentcities agent). Also, the ontologies which are to be 
exchanged/translated may be expressed in different ontology languages 
(Ontolingua/KIF vs. DAML+OIL or CycL). The ontologies may also be at different 
levels, e.g., upper ontologies and lower domain ontologies. Multiple upper 
ontologies or portions of uppers may have to be exchanged/translated and 
reasoned over. The same individuals/instances/data may have to be mapped to 
distinct ontologies. There may need to be mappings between query languages (SQL, 
RQL, etc.)

EXAMPLE DOMAIN:  distributed Organizational Memories, FIPA to Agentcities agent 
communication, 

TYPICAL USER:  Intelligent agent, agent developer.

WEB ONTOLOGY REQUIREMENTS:

-----
GENERAL USE CASE: C (5, 11, 15, 19)

CATEGORY DESCRIPTION: Knowledge Management - Ensuring cooperation among 
organizational units using different ontologies

DESCRIPTION: 
Multiple organizational units have to communicate with each other on the Web. 
These organizational units may have distinct Organizational Memories (OM), 
knowledge repositories, or support multiple databases and document sets, all of 
which may be represented by distinct, different ontologies. There may be various 
levels to the organization and hence to the levels of information model and 
their corresponding vocabularies, ranging from data/information specific to 
domain to enterprise level. Furthermore, the organizations and their supporting 
ontologies may change dynamically. Some organizations may be virtual and 
compositions or partitions of other existing organizations (e.g., Communities of 
Interest).

Nonetheless, all of these organizations and organizational units must be able to 
interoperate semantically, with heterogeneous vocabularies and models, through 
the use of ontology mappings. These mappings may be discovered when needed, may 
be persistent and updatable, may be discardable. 

EXAMPLE DOMAIN:  business organizations, Web Communities of Interest

TYPICAL USER:  members of organizations requiring information from other 
organizations

WEB ONTOLOGY REQUIREMENTS:

---
GENERAL USE CASE: D (6, 14) 

CATEGORY DESCRIPTION: Intelligent Search, E-commerce - Context sensitive and 
inter-domain search on the Web, electronic commerce

DESCRIPTION: 
Business-to-business (B2B) and Business-to-Customer/Consumer (B2C) electronic 
commerce on the Web requires that buyers be able to search for and find 
prospective products and services from a diverse range of applications, 
databases, catalogs, and established or emerging B2B or B2C engines and 
infrastructures. All of these resources may be modeled by a classification 
system, a taxonomy, an ontology. Eventually they may all be modeled using an 
ontology language. The problem therefore becomes one of enabling users to search 
for products and services (and objects in other domains) which are 
heterogeneously modeled or categorized explicitly or implicitly on the Web, and 
mapping conceptually between these models, categorization systems, or 
ontologies. Prospective buyers want to find products and services using 
vocabularies (and meanings) which are diversely represented in individual 
company catalogs and documents. Prospective sellers want their products and 
services to be categorized and appropriately modeled in order to be found by 
prospective buyers. Such conceptual searching/navigation (categorization) will 
require ontologies to be mapped semantically. These must be context sensitive 
insofar as the origin of the search (or other contextual aspects) may 
(partially) indicate the appropriate concepts to map (a potentially ambiguous 
search for "drill" may differ when submitted in a dental or metal-working 
context).

EXAMPLE DOMAIN: B2B electronic commerce

TYPICAL USER:  Prospective buyer searching for products, prospective 
supplier/seller searching for the appropriate categories and features to 
characterize his/her products and services. 

WEB ONTOLOGY REQUIREMENTS:

-----
GENERAL USE CASE: E (7, 20, 21, 22)

CATEGORY DESCRIPTION: Knowledge Fusion - Fusion/composition of information from 
disparate ontologies

DESCRIPTION: 
Information represented on the Web or in applications accessible to the Web (or 
locally on LANs) may be represented semantically in diverse ways, depending upon 
the domain, on the problems attempting to be solved by the application, on the 
degree of sophistication of the model. Both the ontological concepts and the 
individual/instances/data the concepts characterize may require semantic 
composition/fusion (and decomposition) and corresponding syntactic/format 
conversions. There may be many levels of aggregation and fusion required. In 
defense-related command and control and intelligence gathering situations, the 
fusion may be over sensors utilizing distinct semantic models (signals of 
various kinds, map or geopolitical locations in different representations, 
imagery at different interpretation levels) or over documents and data in 
different media represented semantically in very different ways for intelligence 
evidence gathering and analysis. The concepts and data must be mapped, 
rectified, fused, but with each step of mapping/rectification/fusion kept 
indefinitely (persistent), decomposable, and correctible. This use case is 
related to the Intelligent Agent use case. 

EXAMPLE DOMAIN:  Defense related command and control fusion of sensor data, 
intelligence gathering and analysis.

TYPICAL USER:  Commander, intelligence analyst. 

WEB ONTOLOGY REQUIREMENTS:

-----
GENERAL USE CASE: F (12)

CATEGORY DESCRIPTION: Coevolution of Model, Standard, Testing - Support the co-
evolution of a standard, its model, and a conformance testing system.

DESCRIPTION: 
In many cases, the Department of Defense has trouble correlating the semantic 
model (ontology) of a particular standard with the standard and with its 
conformance testing realization. All of these three essential components too 
often vary dynamically and without correlation to each other. In principle, 
standards should be model driven, and applications which purport to comply with 
the standard should be testable with respect to that compliance by a 
(potentially generatable) conformance test suite. This requires a semantic 
mapping between the model and the standard and the standard's test suite. One 
additional complexity is that the standard may have different versions, hence 
the model and the conformance test suite will have different versions. 

EXAMPLE DOMAIN: Department of Defense weapons, network, and command and control 
systems

TYPICAL USER: Command and control system user, developer

WEB ONTOLOGY REQUIREMENTS:

-----
GENERAL USE CASE: G (13, 16, 18)

CATEGORY DESCRIPTION: Context/view Mapping - Support users, developers, and 
devices by enabling an ontological context or "view"

DESCRIPTION: 
Applications will have to adapt content presentation to users by filtering or 
representing ontological information based on context or "view". Sensor 
detection and CAD engineering are two domains where ontology content should be 
adapted to contextual information to present a particular view the user is 
interested in. These "views" will need to suppress/filter information based on 
application presentation requirements (e.g., for personalization or 
localization) or simply the desire to focus on particular aspects of an ontology 
at a given time, perhaps in response to a query (for example, to display only 
"functional" aspects, not "physical" properties of concepts). These views or 
contexts may need to be composed or manipulated, hence persistent, leading in 
the extreme to being "reified" as application theories in the ontology.

EXAMPLE DOMAIN:  Sensor detection, CAD engineering, multimedia generation 

TYPICAL USER:  CAD design engineer, device user, ontology application developer

WEB ONTOLOGY REQUIREMENTS:

-----
GENERAL USE CASE: H (8, 17)

CATEGORY DESCRIPTION: Command & Control Message Content Interoperability - 
Transmit semantic information from one service to another, or across command and 
control domains

DESCRIPTION: 
Defense related applications for command and control, military mission planning, 
logistics, etc., require the use and dissemination of multi-domain information 
across services and other organizational units. In many cases, the ontologies 
are distinct, employing different terminology/meaning for ultimately 
semantically similar notions. The different ontologies need to be mapped in 
order to preserve the semantics as much as possible when orders or information 
flows across the various armed forces services and organizations, and when the 
same information is used to support different goals.

EXAMPLE DOMAIN:  Defense command and control, military mission planning

TYPICAL USER:  Commander, defense planners 

WEB ONTOLOGY REQUIREMENTS:


7. SPECIFIC USE CASES

The specific use cases in this section were obtained from many contributors, 
from a number of distribution lists and organizations. Each of these specific 
use cases have the following format:

USE CASE NUMBER
CONTRIBUTOR
DESCRIPTION
EXAMPLE DOMAIN
TYPICAL USER
WEB ONTOLOGY REQUIREMENTS


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 for intelligent agents

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

A possible day-in-the-life example of an interoperability use-case is as
follows:
Background:
        Givens: UPnP network, ANSI 709 network (that interconnect via
protocol gateway)
        Givens: UPnP Devices - Television/Display, printer; 709 devices -
electric light, washing machine

Scenario:
        1) A parent reading a book in a room of the house wants to be
notified when children in another room watching television select
channels/programs that require parental guidance (chX). 
        2) When chX is selected a notification is sent through the gateway.
The message describes chX expressed in UPnP native form, is translated to an
intermediate form. A UPnP to WOL translator maps the expression of chX
(including encompasing device description - eg tv name, location, etc) to an
ontological representation. 
        3) In WOL syntax a rule for chX describes an action to be taken. The
action is to notify a parent. The rule engine determins the parent to notify
and how to perform the notification. In this scenario the lamp will blink 3
times in the room where the parent is reading. (It may be a research problem
determining how to notify the parent - or it could be a straight forward
configuration problem).
        4) The WOL message, which is comprised of elements of a device
description logic and a services description logic (eg. the TV being in
state chX, at time T, at location L reporting via event E requires a
services ontology to capture all the elements). The message (as an argument
to an inference rule) is evaluated and produces another message (also in WOL
form) that is sent to a WOL-->709 translator.
        5) The 709 translator recasts the message in 709 syntax and performs
the operation in native 709. ie. the lamp in room X flashes 3 times.

The scenario could be altered to perform translation on other nodes besides
the gateway. As such the message (expressed as a subset of an ontology) must
be merged with the ontology on the gateway which is a proof/inference
ontology. 

This scenario could be expanded to include a third party management service
that authors the rules/policies and applies them to the gateway.
<--

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

-----
8. 

CONTRIBUTOR: Eric Hughes, MITRE, Leo Obrst (with information provided by others)

TASK: Disseminate an Air Tasking Order (ATO) from one service to another.

DESCRIPTION: Each military service (Air Force, Army, Navy, etc.) is slowly 
deploying dissemination capabilities that use XML markup of content messages. 
DTDs and soon Schemas for these are registered in the Defense Information 
Systems Agency (DISA) XML Registry. However, there is little to no current 
capability to integrate across schemas, which may be provided by different 
services, nor to express semantics. ATOs need to be used by a wide variety of 
military organizations for a wide variety of purposes.

EXAMPLE DOMAIN: Military mission planning and airspace management.

TYPICAL USER: All the following are typical: mission planner, logistics
planner, commander, military climatologist, air traffic controller.

WEB ONTOLOGY REQUIREMENTS:

-----
9. 
CONTRIBUTOR: Ora Lassila

TASK: Serendipitous Interoperability: two (or more) devices find that they can 
meaningfully interoperate.

DESCRIPTION: Here is what I am hoping to achieve with WebOnt, eventually: I am 
interested in describing characteristics and functionality of various 
devices (such as cell phones, printers, sensors, etc.). I'd like to 
be able to draw from both CC/PP (in describing device and software 
capabilities) and DAML-S (in describing semantics of Web Services for 
the purpose of discovery, composition, etc.). The ultimate goal would 
be what I call "serendipitous interoperability" where two (typically 
many more) devices will 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.).

All this without a human "in the loop", that is, I'd like to see 
devices configure themselves to engage in a meaningful dialogue with 
others.

I see a powerful language for representing the semantics of device 
functionality as a critical component of this dream. In addition to a 
language, we need proper vocabularies and ontologies to make all this 
happen.

Naturally I have to apologize for choosing a research-oriented 
problem. I acknolwedge that not everyone here represents a research 
organization and may have more practical, short-term goals. Some of 
us, however, are in this working group because it has become the 
frontier in trying to realize the vision of the Semantic Web (those 
not interested in this can stop reading this message now :-).

The Semantic Web is a *hard* problem. Why? Because many of our 
simpler examples can be solved using other means - no RDF, DAML+OIL, 
reasoning etc. is required (this is anyway the response I get when 
trying to explain what the Semantic Web is about, and I have been 
trying for the past 5 years or so). Any reasonable number of 
information systems can be made to interoperate and exchange 
information by employing a group of clever XSLT and Perl programmers, 
it seems. And people will do this, and will extend this approach to 
Web Services as well.

What we are trying to do is qualitatively harder. The problem is that 
it cannot be demonstrated or illustrated using simple scenarios. I 
believe we want to make a solid case that the Semantic Web makes 
sense; otherwise we will always be faced with the folks who would 
rather believe in the "XSLT magic". As for the "uncoreographed" 
interoperability of some systems (virtual or physical), a reasonably 
powerful *standardized* representation language would be a big win, 
allowing us to expose (some of) the semantics of the systems in 
question and making it more likely a reasonable response can be 
generated in unanticipated situations.

[1] http://lists.w3.org/Archives/Public/www-webont-wg/2001Dec/0022.html
-- 
Ora Lassila  mailto:daml@lassila.org  http://www.lassila.org/
Research Fellow, Nokia Research Center

EXAMPLE DOMAIN: Multiple computing devices.

TYPICAL USER: Devices.

WEB ONTOLOGY REQUIREMENTS:

-----
10.

CONTRIBUTOR: Tim Finin

TASK: Support pervasive computing across many computing devices

DESCRIPTION: We are interested in suing semantic web languages
to support service description, discovery, matching and negotiation
for devices in a mobile computing or pervasive computing environment.
We are particularly interested in allowing devices to be aware of the
"context" they are in so that they can better perform their tasks.
We've done some preliminary work that has included developing a version
of JINI which uses DAML+OIL to describe services offered and sought.
We've also developed a system that uses RDF for service description
and matching in the Bluetooth Service Discovery Protocol.

  Chaitanya Pullela, Liang Xu, Dipanjan Chakraborty, Anupam Joshi,
  "Component based Architecture for Mobile Information Access",
  proceedings of 2000 International Conference on Parallel Processing
  (ICPP 2000), August 2000.

  Sasikanth Avancha, Anupam Joshi, and Tim Finin, Enhancing the
  Bluetooth Service Discovery Protocol, submitted IEEE Wireless
  Computing and Networking Conference, Orlando, March 17-21, 2002.


EXAMPLE DOMAIN: Multiple computing devices

TYPICAL USER: Devices

WEB ONTOLOGY REQUIREMENTS:

-----
11.

CONTRIBUTOR: Alexander Maedche

TASK: Ensuring cooperation among organizational units using different 
ontologies.

DESCRIPTION:
We are exploring Semantic Web technologies in different application areas:
Knowledge management (e.g. human resource competence ontologies, virtual
organizations, cooperation between different departments [1] using multiple
ontologies), E-Learning [2], and knowledge and community portals [3].

Footnotes:
[1] http://www.ontologging.com
[2] http://edutella.jxta.org
[3] http://www.ontoweb.org

EXAMPLE DOMAIN: Knowledge management

TYPICAL USER: Users in separate organizational units or communities.

WEB ONTOLOGY REQUIREMENTS: 
 - representation of a lexical layer within ontologies (also
   for instances)

 - modularization principles (enforcing interoperability by reuse)

 - scalability

 - representation of mapping rules between different ontologies

 - support different complexity layers concerning
   expressive capabilities

-----
12.

CONTRIBUTOR: John Stanton

TASK: Support the co-evolution of a standard, its model, and a conformance 
testing system.

DESCRIPTION: 
What the Department of Defense always seems to need falls into
two areas, in my judgment - security & formal
methods that produce interoperable 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: Department of Defense weapons, network, and command and control 
systems

TYPICAL USER: Command and control system user, developer

WEB ONTOLOGY REQUIREMENTS:

-----
13.

CONTRIBUTOR: Ruediger Klein

TASK: Support CAD engineering developers by filtering ontological information 
based on context or "view"

DESCRIPTION:
We would like to provide support for engineering developers. In our use case, 
an engineering developer sits in front of her CAD system, executing some 
engineering task. She has at the same time access to engineering best practices 
documented in a semantic web context. Using the underlying ontology, we can 
filter the information, to provide just those aspects relevant to her. Typical 
questions that arise, are to filter information based on context, to provide a 
view on the ontology adapted to a certain task (e.g. classification may provide 
a different view than catalog browsing), and finally constraints between the 
elements can be used to compute values for certain properties.

More precisely, we are modeling a very complex world, with many objects, 
properties and relations. These models should be built by many different 
people, more or less concurrently. I.e. a team of people is developing the 
model of our world, not a single person. As many people are modeling the same 
world independently, we would like to provide a guiding structure to the 
modeling people involved. A central task is to ensure the consistency between 
the various modifications/edits executed by the people involved. For example, 
in a group meeting, we may agree that in our world we should model engineering 
parts, production process steps and materials in a certain way. These are 
somehow related, in some agreed fashion. This commonly agreed framework then 
serves to guide the actual modeling. The people that execute the modeling can 
now specialize engineering parts, production process steps and materials, 
define properties of the specializations, and place them in one of the agreed 
upon relations.

To summarize:
(a) ensure consistent modeling of the ontology by several people;
(b) varying views on the ontology based on user context (taxonomy versus 
classification when selecting screws);
(c) constraints to express relations between elements.

Some of the aspects important in this context can be generalized in the 
following way:

1.Engineering information

Engineering information is mainly characterized by the following points:

- large bodies of knowledge: catalogs of materials, parts and components; bills 
of material; supplier information; geometric, simulation and other models...
- a great variety of interrelationships between different parts of engineering 
information: requirements, functional descriptions, behaviours, structures, 
geometry, ...
- arithmetics and especially geometric models are integrated parts of 
engineering information.

A whole universe of engineering IT tools exists today each especially dedicated 
to a certain aspect of engineering problem solving: from large database 
systems, PDM (product data management)  tools, CAD, numerical simulation 
systems, work flow, etc.

Today, greater parts of this complex information are not at all represented in 
the IT systems, or they are left implicit inside procedural code.

Engineering is essentially a collaborative effort: many people interact in 
engineering problem solving - contributing their special views on the task to 
be solved.

As a consequence, the many different IT systems used today in typical 
engineering environments are 
- restricted in their interoperation capabilities (using standards like STEP), 
- need special "hand made" interfaces for interoperation, or 
- can only exchange data where the semantics is hidden.

2.  Semantic Web in Engineering

From a Semantic Web point of view, we have three main aspects of dealing with 
engineering information:

2.1.)
large, semantically rich engineering ontologies dealing with requirements, 
functional descriptions, behaviours, structures, geometry, arithmetics, etc.;
2.2.)
different views on engineering information - reflecting the views of the 
various people involved in collaboration (or similarly, integrating different 
ontologies in a consistent way);
2.3.)
changing (but related) content: versions, (parallel) variants, succeeding 
stages of models, work flow, etc.

3. Semantic Web Requirements

We do not expect that the Semantic Web as currently under discussion will 
really solve these problems. They are too deep and too widespread. But in order 
to be usable as a platform for an improved treatment of engineering problems 
the Semantic Web should provide some basic capabilities:

3.1.) structuring large ontolgies/bodies of information:
- hierarchical and modular structures of ontolgies are supported
- meta knowledge about ontological knowledge (including tagging and reification)

3.2.) different views
- user specific views can be defined as part or on top of ontologies
- different ontologies can be merged (partially)

3.3.) arithmetics and geometry
Beyond typical description logics engineering ontologies need rich 
arithmetics/geometrical modeling capabilities.

4. Practical Requirements

In order to make that work three pre-conditions should be fulfilled:

4.1.)
general purpose and application-independent but domain-specific "standard" 
ontologies (about functions, structures, behavious, geometry, etc.) should be 
provided as a "starting point" for application specific information models;
4.2.) 
sophisticated tools are needed in order to deal with complex enginerring 
ontologies: for retrieval and for consistent knowledge modeling (also be 
experienced end users - esp. for the "lower" and more frequently changing parts 
of the ontologies).
4.3.)
sophisticated techniques are need for database and tool integration: the huge 
amounts of engineering information available today in "non-SemanticWeb form" 
must be usable.

EXAMPLE DOMAIN:  CAD/CAM-based automobile design systems

TYPICAL USER: Engineering designers using CAD/CAM systems

WEB ONTOLOGY REQUIREMENTS:

-----
14.

CONTRIBUTOR: Deborah McGuinness and Leo Obrst

TASK: Support intelligent interoperable electronic commerce by mapping product 
and service standards

DESCRIPTION:
- 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, eClass, etc. In fact, the OntoWeb Content 
Standards group is offering a challenge problem to map between the UNSPSC, 
eClass, etc., for example, to support a B2B electronic commerce interlingua 
(http://www.ladseb.pd.cnr.it/infor/ontology/OntoWeb/SIGContentStandards.html).  
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].

[5] http://www.research.att.com/~dlm/papers/ieee-expert.html

EXAMPLE DOMAIN: Business-to-business (B2B) electronic commerce

TYPICAL USER: Prospective buyers searching for products across heterogeneous 
catalogs, sellers having heterogeneous catalogs needing to map to a common 
trading language

WEB ONTOLOGY REQUIREMENTS:

-----
15.

CONTRIBUTOR: Raphael Voltz

TASK: Enable disparate organizations and communities, with heterogeneous 
vocabularies, to communicate and interoperate via the use of ontology mappings.

DESCRIPTION:
In the first scenario ontologies provide a single, common vocabulary
that acts as a communication basis between humans and machines, viz. as a 
semantic data model for integration of heterogeneous data and as a common 
business terminology that is used. In the FZI research project "Ontologging" 
goes beyond this single common vocabulary within a department. A challenging 
problem is the global knowledge access through different departments
supporting different vocabularies, e.g.  establishing communication between the 
finance and the human resource department, on the human and on the machine 
level. The idea behind this approach is that people use their own ontololgy, but 
mappings between different ontologies (in our case to other departments) are 
discovered automaticallyand proposed to the users within the use of the system.
The user may than decide if the mapping should be explicitly represented or 
neglected. The ontology language must then be able to express (or atleast 
facilitate) such mappings (i.e. DAML+OIL equivalent can be used to express 
equivalence of classes / properties).


EXAMPLE DOMAIN: Inter-departmental communication between the finance and human 
resource departments.

TYPICAL USER: Finance department employee, human resource department employee.

WEB ONTOLOGY REQUIREMENTS:

-----
16. 
CONTRIBUTOR: Herman ter Horst

TASK: Adapt content (media) presentation to users and the context. automatically

DESCRIPTION:
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: Sensor detection

ONTOLOGY SAMPLES: 

TYPICAL USER: 

WEB ONTOLOGY REQUIREMENTS:

-----
17. 
CONTRIBUTOR: Mary Pulvermacher, MITRE

TASK:  DAML Combat Support Agent

DESCRIPTION: 
We want to apply the DARPA Agent Markup Language (DAML) and associated tools to 
the Combat Support and Air Tasking domains.  We plan to build upon the data and 
knowledge developed in a FY01 ngJBI (next generation Joint Battlespace 
Infosphere) pilot.  This pilot was to build a synchronized Combat Support Order 
(CSO) that aligned Expeditionary Aerospace Force (AEF) combat support activities 
with theater Air Tasking Order (ATO) missions.  We will extend this pilot to 
incorporate a DAML approach by replacing applications where human knowledge is 
hardwired into procedural code with ontologies and an agent to exploit these 
ontologies.

EXAMPLE DOMAIN: 
There are 3 relevant domains: 
Mission Planning
Combat Support
Transportation

TYPICAL USER: 
Typical users include:

Mission Planning: Decision-maker in the Mission Planning Cell
* Members of the mission planning cell in the Air Operations Center develop the 
Air Tasking Order for combat operations. They must take into account the 
availability of aircraft, appropriate munitions for the particular target, and 
support equipment (RADAR, Inertial Navigation Systems, Electronic 
Countermeasures) required to successfully achieve the combat objectives. 

Combat Support: Decision-maker on the AFFOR staff.
* The A-4/AFFOR Staff tracks the status of aircraft, availability of munitions, 
support equipment, personnel with required skills and certifications, fuels, 
etc. They calculate projected usage of materials and coordinate replenishment. 
They must also monitor and optimize utilization of critical assets such as 
manpower and aerospace ground equipment.

Transportation: Planner/coordinator in Air Mobility Command's Tanker
Airlift Control Center (TACC).
* The TACC allocates airlift assets based on cargo's priority code; monitors 
movement of cargo until it reaches its destination.

WEB ONTOLOGY REQUIREMENTS:

-----
18.
CONTRIBUTOR: Jacco van Ossenbruggen of CWI Amsterdam at OntoWeb Special Interest 
Group on Ontology Language Standards during the OntoWeb meeting in Amsterdam 
early December, 2001.

TASK: Multi-media generation

DESCRIPTON: 
Jacco van Ossenbruggen of CWI Amsterdam presented the groups work on
multi-media presentation generation: their intended scenario is as
follows: in response to a query to a database, a user gets back a set of
media-items; the challenge is then to combine these items in a coherent
multi-media presentation that answers the query. For this, one need lots
of information about these multi-media-items and their relations. Some
of the expressivity requirements are:

     - the need for different ontologies at different levels, eg:
       media-specific, domain/content-specific, presentation-specific;

     - the need to reason about all these ontologies combined. The
       reasoning they need combines reasoning at class and instance
       level. No subsumption style reasoning seems required.

     - the need to use large existing ontologies, but typically the only
       need parts of these large ontologies. Thus, there is a
       requirement for some information-hiding/modularity concept;
       these different existing ontologies are also likely to come from
       different communities, so there is a need syntactic
       translations.

     - Finally, the group also wants to re-use the "input
       metadata" from the databases and include them into the output
       presentations. Again, this requires mapping and import
       mechanisms.

Currently all the work of the group is encoded into home-grown ad hoc
technical solutions. However, they are keen to move to a more clean
declarative representation.

EXAMPLE DOMAIN: Multimedia presentation supported by databases.

ONTOLOGY SAMPLES: 

TYPICAL USER: user who queries multimedia database

WEB ONTOLOGY REQUIREMENTS:

-----
19.
CONTRIBUTOR: Enrico Motta from KMI/OU-UK at OntoWeb Special Interest Group on 
Ontology Language Standards during the OntoWeb meeting in Amsterdam early 
December, 2001.

TASK: Annotation of on-line contents

DESCRIPTION:
Enrico Motta from KMI/OU-UK described their work on annotation of
on-line contents. He argued strongly for reification features as a
necessary feature of ontology-languages for such applications. Remarks
from the audience suggested that such features are also needed in
agent-based applications. Rudiger Klein from Daimler-Chrysler argued
that he would need 2nd order constructions (similar to but not the same
as reification).

Examples where he would need this are:

     - to qualify properties as being of a certain type
       (e.g. structural, chemical),

     - to select different views on same ontology;

     - for extensibility (e.g to add time-specific constructs to an
       ontology language if the language itself does not provide them);

     - to store meta-data in the ontology (e.g source, author,
       reliability);

     - even in simple application like annotating abstracts such
       features would be needed (e.g. to model argumentative
       structure).

An extensive discussion followed how much of this could be done with the
subproperty hierarchy, and how much of this could be done with
meta-classes (such as the mechanism provided by Protege). Various people
also pointed out that many of these reification and 2nd order
constructions are in fact rather simple varieties, and that they need
not be cause for computational problems.

EXAMPLE DOMAIN: 

ONTOLOGY SAMPLES: 

TYPICAL USER: 

WEB ONTOLOGY REQUIREMENTS:
-Reification
- 2nd order constructs or meta-classes to type properties (e.g. structural, 
chemical)
- ontology views
- time-specific extensions
- ontology metadata

-----
20.

CONTRIBUTOR: Jonathan Dale, for FIPA Ontology Technical Committee, from meeting 
October, 2001, Pasadena, CA. From: FIPA Ontology TC: Use Cases for Ontologies, 
ontology@fipa.org,19th December, 2001

DESCRIPTION: Semantic Framework Mapping: Upper Ontologies
There exist several types of upper ontologies that may be of use in these areas. 
Higher-level
ontologies may be used for: 

Policies such as security policies, conversation policies, etc.
??Conventions such as legal, societal, or ethical conventions.
??Contracts that can be formed between agents.
These ontologies provide knowledge about the structure and content of policies, 
contracts, conventions; also the meaning of each of the components, at a general 
level. This includes:
??The terms and basic building blocks used within the policies and contracts. 
For instance, an upper ontology for policies may contain structural terms, legal 
terms, societal terms, and other generic terms germane to policies as a whole.
??Axioms defining how these basic building blocks can be composed within a given 
convention, policy or contract.
??The semantics to handle these terms and reason over them.
??Interrelationships among different upper ontologies, the nature and direction 
of those relationships, and the relationships of the upper ontologies to the 
domain-specific ontologies. For instance, policies exist in the context of some 
conventions and legal system. Note that one property of these upper ontologies 
is that a given, say, policy, will not be fully instantiated from the upper 
ontologies, but rather be instantiated generally as the policy is defined
and its use unfolds.

EXAMPLE DOMAIN: 

ONTOLOGY SAMPLES: 

TYPICAL USER: 

WEB ONTOLOGY REQUIREMENTS:

-----
21. 

CONTRIBUTOR: Jonathan Dale, for FIPA Ontology Technical Committee, from meeting 
October, 2001, Pasadena, CA. From: FIPA Ontology TC: Use Cases for Ontologies, 
ontology@fipa.org,19th December, 2001

2.2 Domain-Specific Ontologies
These lower-level ontologies are more domain-specific, for example, defining 
policies in a specific area. A given domain-specific ontology exists in 
relationship to some specific upper-level ontologies, and those relationships 
must be represented. Also, a policy represented using some set of upper 
ontologies may be instantiated differently in different domains and different 
uses. These lower levels can have multiple models and representations. The 
ontologies themselves must allow the ability to reason over terms from a set of 
ontologies, which is the collection of ontologies that the given instance 
happened to use. Note that the definition of the domain ontologies should not 
directly represent the upper ontology terms and axioms, as this hinders 
reusability and adaptability. Also, instantiation of policies, conventions and 
contracts may occur over a period of time. As with the issue of multiple 
ontologies, reasoning over such policies, etc, must be able to adapt to the fact 
that they may not yet be fully instantiated.
Use Case
1. Agents A, B and C know about ontologies O1 and O2.
2. Data set D1 provides information about the topography of a given region, R. 
It has information about the slope and aspect of the region by location. The 
ontology for D1 is O1, and it associates location with x,y points that refer to 
coordinate system C1.
3. Data set D2 provides information about the soil types by location in region 
R. The ontology for D2 is O2, which associates location with x,y points that 
refer to coordinate system C2.

A wants to know about areas in Region R that are good for wine cultivation. A 
asks B for all the places in R that have a particular aspect and soil type that 
are known to be suitable for growing grapes of the suitable type.
5. B can satisfy this query by accessing data sets D1 and D2, but must match 
locations that are described according to two different ontologies, O1 and O2.
6. B repeatedly asks C to translate locations in the O1 ontology into 
corresponding locations in the O2 ontology in order to match locations that have 
the appropriate soil type and aspect.

EXAMPLE DOMAIN: 

ONTOLOGY SAMPLES: 

TYPICAL USER: 

WEB ONTOLOGY REQUIREMENTS:

-----
22. 
CONTRIBUTOR: Jonathan Dale, for FIPA Ontology Technical Committee, from meeting 
October, 2001, Pasadena, CA. From: FIPA Ontology TC: Use Cases for Ontologies, 
ontology@fipa.org,19th December, 2001

5. Information Agents
5.1 Information Integration and Fusion
In an information agent system, one of the ways that ontologies are used is to 
represent knowledge about the data that is being brought in from the various 
information sources. Information agents may use the ontology like a schema to 
manipulate the information in a database-like manner, for example, via SQL. This 
in turn puts some conditions on what might be in an ontology, for instance:
??The ontology must cover the elements of each information source schema that 
the agent system needs to take advantage of, though it does not imply that all 
concepts from all information sources be represented in the ontology.
??The portion of the ontology that concerns the data directly needs to have a 
specification that is amenable to manipulation via relational operations, to 
wit, that the concepts be represented as entities, relationships and their 
attributes.
??When related information from different sources needs to be joined using a 
relational join operation, then the attributes specified in the join must be 
represented in the same manner. (Note that this is not a requirement in any 
other situation; there is nothing a priori in information manipulation that 
forces other attributes to have the same representation.) Typically these are 
attributes that are viewed from a query processing perspective in a manner 
similar to keys. In this situation, it may be desirable to have the ontology 
include knowledge of a canonical representation for those attributes and/or 
knowledge in the form of axioms as to how alternative representations relate to 
the canonical representation.

EXAMPLE DOMAIN: 

ONTOLOGY SAMPLES: 

TYPICAL USER: 

WEB ONTOLOGY REQUIREMENTS:
Received on Monday, 7 January 2002 16:21:43 GMT

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