This document is also available in non-normative PDF version.
Copyright © 2004 DERI®, All Rights
Reserved. DERI liability, trademark,
document use, and software licensing rules apply.
This document specifies a concrete use case for modeling Semantic Web Services with the Web Service Modeling Ontology WSMO in the domain of e-tourism. A Virtual Travel Agency sells tickets for international train tickets, and a customer defines a Goal for purchasing such a ticket. This use case has been the initial WSMO Use Case defined in previous versions of the WSMO D3.2 Deliverable - WSMO Use Case and Testing. The main focus of this document is the concrete modeling of the top WSMO components, resulting in the specification of WSML, and to test and elaborate the approach and technologies for Web Service Discovery in WSMO.
For use case modeling, we stick to the final working draft of Web Service Modeling Ontology WSMO, Version 1.0, 20 September 2004 [Roman et al., 2004].
WSMO Standard: D2 v1.0 Web Service Modeling Ontology (WSMO), last version at: http://www.wsmo.org/2004/d2/
WSMO Primer: D3.1 v0.1 WSMO Primer
Web Service Modeling Language WSML: D16 v0.2 WSMO The WSML Family of Representation Languages
WSMO Discovery: D5.1 v0.1 WSMO Discovery
This use case is defined in the domain of e-tourism: a Virtual Travel Agency sells tickets for international train tickets, and a customer defines a Goal for purchasing such a ticket. Using the conceptual framework of WSMO we specify the top-level notions of Ontologies, Goals, Web Services and Mediators for this use case.
A Web Service of a Virtual Travel Agency, short: VTA, offers end-user services for searching and buying train tickets for itineraries in Austria and in Germany. This Web Service is composed out of other Web Services, namely one for searching existing train connections, and one for purchasing train tickets online. As a user request we assume that the user wants to purchase an international train ticket. The course of the use case shall be the following:
This document is structured as follows: Section 2 gives and overview of the use case, describing the overall setting for of the use case and identifying the technical challenges arising for Semantic Web Service technologies; Section 3 defines the needed WSMO components and provides the WSML models for the distinct WSMO components of the use case along with explanations of the design and modeling decisions; Section 4 explains the WSMO Discovery as realized within this use case; finally, Section 5 concludes the use case. Appendix A provides a change tracking to previous version of the document; Appendix B provides related resources for this use case.
According to the general framework for defining use cases for WSMO defined in WSMO Use Case Overview document, section 2, this section provides a description of the setting of this use case. In [He et al., 2004], the travel agency use case is separated into two use cases - one with static discovery and one with automated discovery. With Semantic Web Services we clearly want to support automated discovery.
Imagine a “Virtual Traveling Agency”, called VTA for short, which is an end user service providing eTourism services to customers. These services can cover all kinds of information services concerned with tourism information - from information about events and sights in an area to services that support booking of flights, hotels, rental cars, etc. online. Such VTAs are already existent, currently those portals are accessible via html sites. The partners of the VTA are integrated via conventional B2B integration. By applying Semantic Web Services, a VTA will be more easily be able to configure an invoke Web Services provided by several eTourism suppliers and aggregate them into new customer services. Such VTAs providing automated eTourism services to end users via different interfaces and can be more easily reconfigured according to the actual needs..
Our VTA use case that aggregates Web Services of different tourism service providers. In a nutshell shall it provides the following functionality: A customer uses the VTA service as the entry point for his requests. These end-user services are aggregated by the VTA by invoking and combining Web Services offered by several tourism service providers. To facilitate this, there can be a so called "umbrella" contract between the service providers and the VTA for regulating usage and allowance of the Web Services. Figure 2 gives an overview (modified and extended from W3C Travel Agent Use Case overview, as defined in [He et al., 2004]).
![]() |
Figure 2. Use Case Overview: Virtual Travel Agency based on Semantic Web Services |
The scenario outlines a general structure for VTAs that can be extended to more complex scenarios wherein the customer can be a Web Service itself, thus creating a network of composed services that offer complex tourism services. For example, one VTA can provide flight booking services for an airline union, another VTA aggregates booking service for a worldwide hotel chain, and a third VTA provides booking services for rental cars by combining the services of several worldwide operating car rental agencies. Then, another VTA uses these services for providing an end-user service for booking complete holiday trips worldwide.
In the general use case there are 3 actors. The following defines why they participate in this use case (goal) and the particular interactions they are involved in (roles).
We identify the following usage scenarios
In this use case, the VTA is the central point of interaction between the Customer and other Web Services. Regarding the technological requirements, it is obvious from the usage scenario descriptions that (1) the Web Services offered by the Service Providers have to carry sufficient descriptive information to support automated Web Service usage, and (2) that the VTA has to provide all mechanisms to handle Semantic Web Services. The basic architecture of such a VTA as a central entity for Semantic Web Services handling is shown in Figure 3. The essential functionalities of Semantic Web Service enabled VTAs – with special regard to the requirements for Semantic Web Service technologies – are:
![]() |
Figure 3. General Architecture of a SWS-enabled VTA |
Summarizing, the VTA is a SWS-enabled B2C application that provides an end-user service following a client/server model. In order to support coherent functionality of the VTA and to ensure that the descriptions of Web Services are compatible to this, an overall framework for SWS technologies is needed. This is provided by WSMO.
Semantic Web Service technology can be applied to ease the described use case (a) for the customer (to find the VTA and resolve his goal) and (b) for the VTA that benefits from semantic description of its business partners. These ease the combination and rearrangement of existing services for the VTA and allows him to flexibly offer new services. In case composition and discovery have reached a higher level of maturity it can even be thought that the technologies (in this case discovery and composition) can be used directly by the end user. So that he himself combines the travel services offered, thus not using the extra intermediate party (the VTA).
This section exemplifies the specification of this use case within the Web Service Modeling Ontology WSMO. The provided listings use the conceptual model and syntax presented in WSMO, final version 1.0 [Roman et al., 2004]. The listings provide have been validated with the WSML Online Validation Service.
The subsequent sections provide the modeling of the resources along with detailed explanations on modeling decisions and related issues. The following tables provide an overview of the resources specified in this use case.
WSMO component type | ontology |
name | International Train Ticket Ontology |
description | defines ontology constructs for the domain of international train connections |
imported ontologies / used mediators |
- Date and Time Ontology - Location Ontology - OWL Person Mediator - OWL Fact Book Mediator |
main constructs | main concepts: station, itinerary, ticket, trip, traintrip axioms: stationCountry, departureBeforeArrival, startNotEqualEnd |
WSML model | Listing 1 |
WSMO component type | ontology |
name | Date and Time Ontology |
description | defines notions of date and time, and general interdependencies between them |
imported ontologies / used mediators |
none |
main constructs | main concepts: instant, interval, date, time, dateandtime functions: julianDayNumber, daysBetween, secondsBetween, secondsFromMidnight relations: contains (for intervals) axioms: equality / before / after / between for date and time notions, integrity contraints |
WSML model | Listing 2 |
WSMO component type | ontology |
name | Purchase Ontology |
description | defines notions of purchasing, incl. buyer, seller, purchase oder, purchase partners, payment notions, etc.; based on RosettaNet , but adopted for B2C setting |
imported ontologies / used mediators |
- Date an Time Ontology - OWL Currency Mediator |
main constructs | main concepts: purchase, buyer, seller, contactInformation, purchaseOrder, product, paymentMethod, paymentTerms, delivery |
WSML model | Listing 3 |
WSMO component type | ontology |
name | Location Ontology |
description | defines geographical notions and postal address; extends / combines existing domain ontologies |
imported ontologies / used mediators |
- OWL Fact Book Mediator - OWL Address Mediator - OWL Geo Mediator |
main constructs | main concepts: country, address, city, state, border, distance; incl. concepts / attributes imported via mediators functions: distanceInKilometers, distanceInMiles, relations: equalDistance, lessThanDistance, moreThanDistance axioms: integrity contraints |
WSML model | Listing 4 |
WSMO component type | ontology |
name | VTA Use Case Knowledge Base |
description | holds all pre-defined instance data needed within the use case |
imported ontologies / used mediators |
- Train Connection Ontology - Purchase Ontology - Date and Time Ontology - Location Ontology |
main constructs | instances for : stations, currentDate, credit card types, locations (continents, countries, states, cities), drop ship carriers, transportations means |
WSML model | Listing 45 |
WSMO component type | goal |
name | Buying a train ticket online |
description | defines the general ontological structure of goal notions for buying tickets online according to the ontologies; this goal serves as a template for concrete goals (see table 6). |
imported ontologies / used mediators |
- Train Connection Ontology - Purchase Ontology - Location Ontology |
main constructs | postcondition: purchase a ticket for an itinerary (a trip and a passenger) effect: get the purchased ticket delivered to the buyer |
WSML model | Listing 6 |
WSMO component type | goal |
name | Buying a train ticket from Innsbruck to Frankfurt |
description | Buying a train ticket online for an itinerary from Innsbruck to
Frankfurt for a specific passenger with payment by credit card This goal is derived by specializing og the general goal (table 5) via an GG Mediator (table 12) |
imported ontologies / used mediators |
- Date and Time - GG Mediator 1 |
main constructs | postcondition: purchase a ticket for an itinerary for a trip from Innsbruck to Frankfurt on 17th July 2004 for Tim Berners Lee, departure between 6 and 7 p.m. effect: get the purchased ticket delivered to the buyer |
WSML model | Listing 7 |
WSMO component type | web service |
name | OEBB Online Ticket Booking Web Service |
description | web service for booking online train tickets for Austria and Germany, offered by the ÖBB (Austrian national train operator) |
imported ontologies / used mediators |
- Train Connection Ontology - Purchase Ontology - Date and Time Ontology - Location Ontology |
main constructs | precondition: a buyer, and information on the trip that a ticket is searched and sold for and the passenger for whom the ticket shall be valid assumption: if the payment method is credit card, then the credit card has to be valid (i.e. not expired) postcondition: a purchase for a ticket by ÖBB as provider, for itineraries valid for a train trip with start- and endloction in Austria or Germany and for a passenger, incl. price, and payment only via credit card effect: delivery of sold ticket by drop ship carrier or by online delivery |
WSML model | Listing 8 |
WSMO component type | oo mediator |
name | importing the OWL Factbook ontology to WSML |
description | Mediator to import an OWL address ontology into a WSML locations ontology |
imported ontologies / used mediators |
|
main constructs | source component: an Address Ontology in OWL target component: Location Ontology (Table 4) mediation service: not specified |
WSML model | Listing 9 |
WSMO component type | oo mediator |
name | importing the OWL Currency ontology to WSML |
description | Mediator to import an OWL currency ontology into a WSML purchase order ontology |
imported ontologies / used mediators |
|
main constructs | source component: an Currency Ontology in OWL target component: Purchase Ontology (Table 3) mediation service: not specified |
WSML model | Listing 10 |
WSMO component type | oo mediator |
name | importing the OWL Factbook ontology to WSML |
description | Mediator to import an OWL factbook ontology into a WSML ontology |
imported ontologies / used mediators |
|
main constructs | source component: the OWL Factbook (in OWL) target component: Location Ontology (Table 4) mediation service: not specified |
WSML model | Listing 11 |
WSMO component type | oo mediator |
name | importing the OWL Person ontology to WSML |
description | Mediator to import an OWL person ontology into a WSML ontology |
imported ontologies / used mediators |
|
main contructs | source component: a Person ontology (in OWL) target component: Internaction Train Connection Ontology (Table 1) mediation service: not specified |
WSML model | Listing 12 |
WSMO component type | gg mediator |
name | GG Mediator that that links the general Goal for buying tickets with the concrete Goal for buying a train ticket from Innsbruck to Frankfurt |
description | Restricts the trip to train trips within Austria and Germany |
imported ontologies / used mediators |
all ontologies and mediators are inherited from the source component; no additional ontologies or OO Mediators are needed |
main constructs | source component: general goal for buying tickets (Table 5)
target component: concrete Goal for buying a train ticket (Table 6) mediation service: not specified |
WSML model | Listing 13 |
With regard to modularized ontologies as a basic design principle of WSMO, we define four separate domain ontologies as the the terminology definitions for the use case:
The ontologies specified in the following are intended to be "real ontologies" in the sense that they describe the specific domain as a shared conceptualization in a sufficient manner. This allows to reuse this ontologies in different settings and use cases - for example, notions or date and time or a general purchase ontology are needed in a lot of other possible scenarios. However, we do not claim the defined below to be such generic ontologies, but they will be enhanced and completed within cooperations with other use cases, projects, and initiatives. Appendix B provides the original ontologies that are used within the domain ontologies specified in this section.
At this point in time, WSMO does not provide a technique to link to large set of instances. Therefore, in this version of the ontology we only include some example instances, which holds for the other ontologies defined in this use case as well. For reader's convenience, the relevant instances for this use case are gathererd in the VTA Use Case Knowlege Base, a separate ontology. The inclusion of links to large set of instances will be considered in future versions of WSMO.
The "International Train Ticket" Ontology defines a train trip and the surrounding concepts as defined the WSML definition of the ontology shown in Listing 1.
The definition of the ontology is based on the travel itinerary ontology from the DAML ontology library, which is also available in Appendix B6 in OWL abstract syntax. The ontology defines travel itineraries for trips by plane. Our ontology reuses the itinerary and flight concepts and adapt them to define train trips, also introducing new concepts such as train station. The international train ticket ontology also makes use of the person ontology defined at http://daml.umbc.edu/ontologies/ittalks/person (Appendix B1), which defines a subset of vCard. The person concept is used to define the passenger information for an itinerary. We did not find any other available ontologies that model the domain of train tickets or itineraries. The first version of the harmonize ontology for the tourism domain focuses on the events and accommodations subdomains. We will take into account future versions of the harmonise ontology, as they are likely to include the travelling subdomain.
|
The "Date and Time Ontology" in Listing 2 defines models for dates (i.e. certain days) and time (i.e. definition of certain points in time). Further, it defines axioms that represent conventional aspects of date and time, like ´before´ and ´after´, etc. In the use case, this is needed to determine validity of train connections, e.g for ensuring that a ticket is not for an itinerary that is in the past. It also can be used generally for expressing dates and time and relationships between them.
The main ontology taken into consideration for developing this conceptual model of Date and Time is an entry sub-ontology of time, available at http://www.isi.edu/~pan/damltime/time-entry.owl. This ontology uses abstract temporal concepts like instant, interval and event and uses the Gregorian calendar as representation (partly using own encoding and partly using XSD encoding). Axioms are defined in first order logic in the accompanying paper [Pan and Hobbs]; there also is a LISP version of these axioms available at http://www.cs.rochester.edu/~ferguson/daml/daml-time-20030728.lisp. Other ontologies like COBRA calenderclock ontology (http://daml.umbc.edu/ontologies/cobra/0.4/calendarclock) are only a straight forward representation of the Gregorian calendar, without any abstraction of concepts and description of axioms. Widely used concrete representations for date and time are defined in ISO 8601 (Numeric representation of Dates and Time) and in the XML Schema Definition (http://www.w3.org/TR/xmlschema-2/), which is based on ISO 8601. In a later stage when it is clear which build in predicates can be used we will add a syntactical mapping to xsd:dateTime.
|
The Purchase Ontology describes the domain of purchasing within a B2C scenario. In order to base this ontology on existing, commonly accepted conceptual models for purchasing, RosettaNet's PIP3A4 "PurchaseOrderRequest" [RosettaNet] has been transformed into a WSMO ontology. However, RosettaNet as well as the other existing conceptual models for purchasing like ebXML [ebXML] and EDIFACT [EDIFACT] are designed for B2B purchase scenarios and thus not applicable for B2C settings as the one of this use case. Because of this, the Purchase Ontology defined in the folloing listing describes ontological notions relevant for purchasing within a B2C setting. We refer to the WSML representation of RosettaNet's PIP3A4 "PurchaseOrderRequest" which is provided in listing B5, Appendix B, denoting the realted concepts within the realtion attribute of the non functional properties.
The main constructs of the Purchase Ontology are :
|
The "Location Ontology" defines concepts for locations, including cities and states, as well as postal addresses. This ontology is based on the DAML ontology for geographical locations (Appendix B5), an ontology describing a wide variety of locations and geographical areas. The concept country is extended using the OWL-Factbook ontology (Appendix B2). The concept address reuses the DAML address ontology (Appendix B3).
|
The VTA Use Case Knowledge Base holds all instance data that are needed within the use case descriptions. The knowledge base is defined as an WSMO ontology that holds instances of all four domain ontologies defined above. Within this knowlegde base, only a selection of instances is defined that is used within the subsequent WSMO component models.
|
Goals denote what a user wants as the result of the Web Service. For modeling the goal, WSMO describes the information elements that the user wants to get from the service (the postcondition) together with the state of the world desired after the service execution (the effect).
In WSMO, Goals can be defined a different levels of granularity. By so-called GG Mediators, new, more specific Goals can be created out of generic existing Goals. You can also think of generic Goals as being pre-defined in a specific application context, wherefrom concrete Goals can be generated from. In order to showcase this, we define a generic Goal for buying a ticket for any kind of trip (Listing 6), a concrete Goal wherein a user wants to buy a train itinerary from Innsbruck to Frankfurt on a certain date (Listing 7), and a GG Mediator that connects the generic Goal to tickets for traintrips within Austria and Germany (see Section 3.4.3. for the GG Mediator that connects this two Goals).
Listing 6 shows the generic Goal with the following description elements:
|
The concrete Goal expresses the desire to buy a train ticket by refining the notions of the general Goal. Listing 7 shows this Goal with the following elements:
|
We define one (imaginary) Web Service in this use case: an end-user service (means that the user interacts with this service) for purchasing international train tickets offered by the Austrian national train operator ÖBB; this Web Service can be composed of other Web Services, each for the search and buying facility of international train tickets. This setting allows modeling all notions of a WSMO Web Service description: a Capability of the end-user service and its Choreography for user-service interaction, as well as the orchestration which incorporates the aggregated Web Services. The current version of WSMO Standard does only provide a stable specification for describing Capabilities, the model below is restricted to the overall Web Service description and the Capability definition. The modeling for the WSMO Web Service Interface will be added in a later version.
A Web Service Capability in WSMO is described by pre- and postconditions, assumptions and effects, as defined in [Roman et al., 2004]. Listing 8 shows the ÖBB Web Service description, currently the Capability only. More detailed discussion of the Discovery mechanism of WSMO Goals and Capabilities is provided in section 3.1.3. The Capability description elements are defined as follows:
|
OO Mediators import other ontologies or OO Mediators into WSMO entities and resolve possible terminology mismatches. If no mistach has to be resolved the syntactical simplification "importOntologies" can be used. In the following we specify the mediators used:
|
|
|
|
Notice that the mediation service is not implemented yet. Furthermore we do not specify the capability of the mediator, since it is outside of the scope of this deliverable to define the required terminology such as an ontology about ontology languages and mediation patterns.
A WG Mediator links a Web Service to a Goal, resolves terminological mismatches, and may state the functional difference (if any) between both. WG Mediators can be used to pre-link Services to existing Goals. For resolving terminological mismatches, OO Mediators are applied, similar to the ones specified above.
In our use case, we do not need an WG Mediator, because the Goal and the Web Service Description use the same domain ontologies (i.e. there are not terminology mismatches).
A GG Mediator connects Goals and possible specifying the functional reduction. For example, a GG Mediator can connect a Goal "buy a ticket" with another Goal "buy a train ticket". Assuming 'train ticket' is a subclass of 'ticket', the GG Mediator would specify that the set described by the goal "buy a train ticket" is more specific then "buy a ticket".
In our use case, we have defined a generic Goal for buying a ticket for any kind of trip (Listing 6), a concrete Goal wherein a user wants to buy a train ticket from Innsbruck to Frankfurt on a certain date (Listing 7). The GG Mediator is used within the concrete Goal, so defining a connection between the general Goal as a 'template' which is 'instantiated' in the concrete Goal.
|
A WW Mediator allows establishing interoperability of Web Services that are not interoperable a priori by used by connecting Web Services and resolving mismtaches. The mediation facility needed for WW Mediators is to mediate between the Choreographies of Web Services that are ought to interact. This requires mediation on the data, protocol, and process level, i.e. all levels of mediation relevant for Semantic Web Services [Fensel & Bussler, 2002], in order to establish valid global interaction models of Web Services.
There is no WW Mediator in this use case as the corresponding notions of Choreography and Orchestration are still under development at this point in time. Future versions might include the definition of the composition of the search and buying service, wherein a WW Mediator might be applied.
Web Service Discovery is a core technology for Semantic Web Services: the aim is to detect web services that can resolve a given Goal, working on the descriptions of the goal and of web services. WSMO supports Web Service discovery by defining Goals and Web Services as top level components. Web Service discovery is a complex topic of its own, and is addressed within related documents in WSMO. Thus, we do not specify and explain realization of Web Service discovery here, but link to the related documents.
This use case has been serving as a test bed for developing the WSMO Discovery Framework that is elaborated in WSMO Deliverable 5.1 (see: http://www.wsmo.org/2004/d5/d5.1/); and it serves as the testing environment for the implementation of a WSMO discovery engine that is presented in WSMO Deliverable 5.2 (see: http://www.wsmo.org/2004/d5/d5.2/). Please refer to these documents for a complete overview of discovery within WSMO.
This document provides a real-world setting of using Semantic Web Services for a Virtual Travel Agency (VTA) that provides an end-user service for booking international train tickets, thereby aggregating Web Services of different e-Tourism Service Providers. We have modeled ontologies, goals, a Web Service, and OO Mediators according to their current specification status in WSMO [Roman et al., 2004].
This use case is the first, initial use case defined for testing and recursively developing WSMO. The major outcomes of this use case are:
Other use cases address different aspects of Semantic Web Services around the Web Service Modeling Ontology WSMO; WSMO Use Case are gathered in the WSMO Use Case Overview document.
[de Bruijn, 2004]de Bruijn, J. (ed): D16.0 v0.2 WSMO The WSML Family of Representation Languages ebXML, WMSL Working Draft 26 September 2004, avaliable at: http://www.wsmo.org/2004/d16/v0.2/20040926/.
[ebXML] ebXML, avaliable at: http://www.ebxml.org.
[EDIFACT] UN/EDIFACT, avaliable at: http://www.unece.org/trade/untdid/welcome.htm.
[Fensel & Bussler, 2002] D. Fensel and C. Bussler: The Web Service Modeling Framework WSMF, Electronic Commerce Research and Applications, 1(2), 2002.
[Keller et al., 2004] Keller, U.; Lara;, R.; Polleres, A. (eds.): WSMO Discovery, D5.1 v0.1, WSML Working Draft 13 September 2004. available at http://www.wsmo.org/2004/d5/d5.1/v0.1/20040913/
[Pan and Hobbs] F. Pan and R. Hobbs: Time in OWL-S, avaliable at: http://www.isi.edu/~pan/damltime/AAAIsymp2004.pdf.
[Roman et al., 2004] D. Roman, U. Keller, H. Lausen (eds.): Web Service Modeling Ontology (WSMO), WSMO Working Draft D2, final version 1.0, 20 September 2004, available at http://www.wsmo.org/2004/d2/v1.0/20040920/.
[RosettaNet] RosettaNet, avaliable at: http://www.rosettanet.org.
The work is funded by the European Commission under the projects DIP, Knowledge Web, InfraWebs, SEKT, SWWS, ASG and Esperonto; by Science Foundation Ireland under the DERI-Lion project; by the Vienna city government under the CoOperate programme and by the FIT-IT (Forschung, Innovation, Technologie - Informationstechnologie) under the projects RW˛ and TSC.
The editors would like to thank to all the members of the WSMO working group for their advice and input into this document.
To facilitate retracing of changes between different version of this deliverable, the following lists the essentail changes done in comparison to the preceding version.
The change tracking starts with the version of 28 June 2004.
Version: 19 November 2004 http://www.wsmo.org/2004/d3/d3.3/v0.1/20041119/
To ease understanding of the resources modeled within this use case, the section gathers all ontologies (re)used within this use case as well as other related resources.
The ontologies specified in Section 3.1 use existing ontologies. Most of these ontologies are modelled in OWL. To use them within WSML, the syntax has to be converted to WSML (using an OO Mediator). A mediation Service has not yet been implemented, however a partial mapping is defined in [de Bruijn, 2004].
The following listings provide the ontologies in OWL abstract syntax, since this syntax is more human readable then the RDF/XML syntax. The conversion was done using the OWL API developed by the University of Manchestor. Specific Notes to the conversion can be found below each ontology (if applicable). The Listings are given to illustrate the expressive power used in this OWL ontologies and to allow the reader the comparison of between the wsml and owl ontologies.
|
The original ontology in OWL/RDF format is available at: http://daml.umbc.edu/ontologies/ittalks/person
|
The original ontology in OWL/RDF format is available at: http://www.daml.org/2003/09/factbook/factbook-ont
Note that the original ontology contains several Individual assertions which
seemed to be mend as annotation for range fillers, e.g.:
<owl:Restriction> <owl:onProperty rdf:resource="#totalArea" /> <owl:allValuesFrom rdf:resource="http://www.w3.org/2001/XMLSchema#decimal" /> <factbook:units>sq km</factbook:units> </owl:Restriction>
However those individuals have semantically no connection to the properties they occur next to within the XML representation. As shown in the abstract syntax they are just individual assertions.
|
The original ontology in OWL/RDF format is available at: http://daml.umbc.edu/ontologies/ittalks/address
|
|
The original ontology in OWL/RDF format is available at: http://www.daml.org/2001/02/geofile/geofile-ont
Note that this ontology is in OWL Full, in order to show it in the more
concise abstract syntax and to be able to reason with it using Description
Logic Reasoners we converted it to OWL DL by applying the following fixes:
The rdf/xml version of the ontology with those fixes is available at: http://www.wsmo.org/2004/d3/d3.3/v0.1/20041119/resources/owl-ontologies/geofile.owl
|
The original ontology in OWL/RDF format is available at: http://www.daml.org/2001/06/itinerary/itinerary-ont
Within the elaboration of the use case, the RosettaNet's PIP3A4 "PurchaseOrderRequest" has been transformed into a WSMO ontology. As the RosettaNet model is designed for B2B purchase orders, it is not applicable for the B2C setting of the use case demonstrated in this document. However, the Purchase Ontology of this use case as defined in Listing 3, Section 3.1, is based and heavily related to the RosettaNet Purchase Model. The listing below therefore provides the RosettaNet Purchase Model modeled in WSML.
The ontology is an WSML representation of the RosettaNet's PIP3A4 "PurchaseOrderRequest" [RosettaNet]. RosettaNet is a consortium of major Information Technology, Electronic Components, Semiconductor Manufacturing, Telecommunications and Logistics companies working to create and implement industry-wide, open e-business process standards. These standards form a common e-business language, aligning processes between supply chain partners on a global basis.
Every standard business transaction within the RosettaNet trading network is defined in a so called PIP (Partner Interface Process) which defines the XML code, activities, decisions and Partner Role interactions between two partners in the supply chain. Each partner participating in the "Partner Interface Process" must fulfill the obligations specified in a PIP. These PIPs are organized into seven clusters, or groups of core business processes, that represent the backbone of the trading network. Each cluster is broken down into segments which are cross-enterprise processes involving more than one type of trading partner. Within each segment are individual PIPs, whereas the above mentioned PIP3A4 is part of Segment 3A "Quote and Order Entry". This segment allows partners to exchange price and availability information, quotes, purchase orders and order status, and enables partners to send requested orders, or shopping carts, to other partners.
At the current state this domain ontology is preliminary and will be further enhanced in future versions. As far as RosettaNet's PIPs are only intended for the use in the above mentioned industry sectors we also consider and partly work on the ontologizing of other conceptualizations, inter alia ebXML [ebXML] and EDIFACT [EDIFACT].
|