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