- From: Leo Obrst <lobrst@mitre.org>
- Date: Sun, 06 Jan 2002 13:29:01 -0500
- To: Pat Hayes <phayes@ai.uwf.edu>, Dan Connolly <connolly@w3.org>, Herman ter Horst <herman.ter.horst@philips.com>, Mike Dean <mdean@bbn.com>, Deborah McGuinness <dlm@ksl.stanford.edu>, Raphael Volz <volz@fzi.de>, Ora Lassila <daml@lassila.org>, W3C ARCHIVE <www-archive@w3.org>
- Message-ID: <3C38976D.11EDCF76@mitre.org>
All, Sorry for the delay on this, I had hoped to have it distributed earlier. Please comment/suggest. I will be sending the revised version out sometime tomorrow to the entire group. I am enclosing two formats: txt and rdf (I suggest the latter, if you have MS Word). Best, 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 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 THE 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.
3.1 Correlation/Mapping/Merging/Translating Of Ontologies Representing Diverse Information Sources And Services
- Ontology namespaces and inter-ontology references: need to express large ontologies referring to terms in other ontologies
- Ontology translation: need to translate between ontologies
- Ontology mapping rules, features: able to express semantic mapping rules, features between ontologies, establish coreference relations among concepts, relations, instances/individuals
- Ontology composition language: to enable the composition of information from different ontologies
- Ontology service composition language: a compositional ontology-based process and service description language capable of combining existing services
- Ontology mapping versioning: support multiple versions of mapping relations between ontologies
- Ontology query language: support for answering about multiple ontologies: does the ontology have concept A?, what does A mean in ontology X?
- 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
- Inconsistency management: inconsistency is inevitable in large, distributed systems, so need standard meaning in face of inconsistency
- Ontology trust: ontologies of trust/belief
- Ontology approximation: mappings between ontologies may require conflict handling, assumption-based truth maintenance, non-monotonicity, and the expression of relations of approximation
- Inter-ontology validation: enable validation, consistency checking services between ontologies, tagging of mapped portions of ontologies as being consistent, date of consistency check, etc.
3.2 Support For Device/Resource Interoperability
- 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.
- Distibuted ontologies: the device ontology must be linkable with other devices' ontology forming a distributed ontology with a logical beginning and end / deterministic traversal method.
- Ontology language support for inter-device communication language
- Composition: Composition of devices will require composition of ontological information
- Ontology partitions: discrete partitions of an ontology must be recognizable in terms of the physical boundaries and in terms of logical (composite device) boundaries.
- Reflection: the device must be aware of its own ontological properties.
- 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.
- Ownership: Device properties may be owned/controlled/managed by multiple entities. The owner/controller/manager may modify property values.
- Management delegation: management may be delegated.
- Resource metadata: managed resources have meta attributes describing management functions, namely actions, time intervals, audit log, owner/controller/delegate and synchronization events.
- 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.
3.3 Ontology Creation/Management
- Property value updating: properties in an ontology must be associatable with a service/function, that supplies the property value.
- 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.
- 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.
- Property typing: ability to type properties (e.g. structural, chemical), perhaps using 2nd order constructs or meta-classes, reification
- Time: ability to make time-specific extensions
- 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.
- Ontology modularization: need modularization principles (enforcing interoperability by reuse), partitioning schemes, hierarchical and modular structures are supported
- Ontology scalability: very large and growable ontologies should be enabled.
- Ontology complexity layers: support different complexity layers concerning expressive capabilities
- Intra-ontology validation: enable validation, consistency checking services on ontologies, tagging of portions of ontology as being consistent, date of consistency check, etc.
- Ontology services: support ontology services for applications, e.g., inference, query support, find all concepts having a certain property.
3.4 Ontology Views/Contexts, Language Support
- 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.
- 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
- Composition of views/contexts: enable ontology view/contexts to be composed (recursively?)
- 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
- Lexical representation: ability to represent a lexical layer within ontologies (also for instances). These would be terms associated with concepts
- Display names: enable different ontological display names, based on context, application, language, etc.
- Multi-lingual, multi-cultural support: enable support of ontologies in multiple languages, mapping between ontologies in multiple languages.
- Ontology granularity: enable levels of granularity, depending on needs of some context, application
- Personalization: enable users to personalize ontology with respect to their interests, applications
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:
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:
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:
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:
TYPICAL USER:
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:
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:
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 automatically
and 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:
Attachments
- application/rtf attachment: ContentInteroperabilityUseCase010702.rtf
Received on Sunday, 6 January 2002 13:29:49 UTC