aci acris semantic model for service oriented architecture v1.0

The Airport Council International ACRIS Semantic Model for Service Oriented Architecture Modeling Concepts & Development Process

Date: 14/04/2014 Prepared by: Segun Alayande Status: Unclassified

ACI ACRIS Semantic Model for Services Oriented Architecture v1.0

Contents Purpose .................................................................................................................................. 3 The Airport Ecosystem and the ACI-ACRIS Semantic Model .................................................. 3 ACI-ACRIS Services Orientation Strategy ............................................................................... 5

Benefits of the Middle – Out Approach to SOA .................................................................... 6 The ACI-ACRIS Semantic Model ............................................................................................ 6

Purpose of the ACI-ACRIS Semantic Model ........................................................................ 7 Structural Composition of ACI-ACRIS Semantic Model ....................................................... 7 Model Abstraction Levels (Figure 2) .................................................................................... 9

The ACI-ACRIS Semantic Model Development Process ....................................................... 12 Uses of the ACI-ACRIS Semantic Model .............................................................................. 15

Semantic Business Process Improvement ........................................................................ 15 Reusable Service Definition .............................................................................................. 16 Information Standards Definition ....................................................................................... 16 Reusable Library of XML Components .............................................................................. 17

ACI-ACRIS Semantic Model and other Industry Models ....................................................... 19 The ACI-ACRIS Semantic Model Roadmap .......................................................................... 19 Benefits of the ACI-ACRIS Semantic Model .......................................................................... 20 Annex A: Reference .............................................................................................................. 21 Appendix B. Knowledge Representation Patterns and UML Components ............................. 24 Annex B: Concept Definitions .............................................................................................. 30

Archetype Definitions ........................................................................................................ 30 Information Subject Definitions .......................................................................................... 30


Purpose

The purpose of this document is to describe the ACI-ACRIS Semantic Model, its structure and an approach to its development within the context of a dynamic Airport ecosystem. This document takes an ecological approach (42) to the description of the Airport ecosystem and suggests that Service orientation is an application of the ecological analogy to the IT landscape. It suggests three levels of service orientation, namely, at the Airport ecosystem, Airport enterprise and IT ecosystem levels. This document suggests how the ACI ACRIS Semantic Model may be used to compose reusable services Airport ecosystem services. This document will interest ACI members and third party Suppliers with interest in community information exchange and knowledge sharing based on international standards and the community’s common knowledge.

The Airport Ecosystem and the ACI-ACRIS Semantic Model

The Airport is a place populated by a number of networked organisations that collaborate to produce and deliver airport services (aeronautical and non-aeronautical services) to the paying public (and to each other). These organisations include people and technology which together may be called an Ecosystem (42). An Airport is a type of business ecosystem which has been defined (35) as “an economic community supported by a foundation of interacting organizations and individuals – the organisms of the business world.” A business ecosystem includes customers, lead producers, competitors, and other stakeholders. They are based on core capabilities – those required to produce the core product. In addition to the core product, a customer receives “a total experience” which includes a variety of complementary offers. In this document, organizations operating within the Airport ecosystem are referred to as the Airport Community and individual members of the Airport community are referred to as Constituents. An Airport is complex. It involves many different organizations that interact with each other in many different ways. The business ecosystem analogy helps explain these in a holistic way. It is a complex system that is not fully explained by the sum of its component parts. This indicates why traditional approaches to business improvement often fail. They try to reduce these interactions to a simplistic level that just cannot explain how these relationships work in practice. This implies that in any analysis of complex systems, one should not study the parts without understanding the whole. The ecosystem analogy also enables us to use the kind of analytical tools that other areas such as service science and engineering research domain (39) have used to great effect to optimize the ecosystem and create wealth for the Airport community. The Airport community faces multiple challenges including meeting capacity demands, increasing revenue and improving public services in the face of rising costs of services, increasing competition, increasing government and industry regulations. At the same time, there is pressure on revenues from airlines and the need to grow revenue from other sources. The Airport community has opportunities to become multi-modal transportation hubs and centres of economic growth for local economies. The Airport community also has the


opportunity to simplify its IT landscape through service orientation and obtain real business value from its investments through shared community services.

Figure 1. The Airport community as a value-generating business ecosystem To address the above challenges and exploit opportunities for growth, Airport communities must become more responsive to the needs of their stakeholders and more innovative in developing new services. They must become intelligent communities. Ecosystem and corporate intelligence (36) depends both on people learning and organisations learning. But this is not enough. This learning must create new knowledge. The Airport community must embrace new business and technology models that enable them to acquire and use shared knowledge across the community to optimise decisions and business operations. In an industry comprised of ecosystems, competition is less between firms as between ecosystems (30). For example, in the Airport industry, regional hub-level competition is increasing. This has implications for the type of strategic enterprise core competencies (37 & 47) that Airports deploy for sustainable strategic advantage. Adopting the ecological perspective of the Airport enables constituents to identify opportunities for exploiting intangible assets such as expertise, new ideas, knowledge, relationships and reputation. Collaborating and sharing knowledge can create wealth and address unplanned events. Further, they can leverage physical assets (shared ecosystem resources) that they do not own. The business ecosystem analogy suggests that members of the Airport community are autonomous intelligent groups that work together to share knowledge to achieve common business objectives. This has two main elements. Organisations are modular and are loosely integrated (loosely coupled). This is evident in the abundance of specialist business roles in many Airports today. The inherent loose coupling of the Airport community enables the dynamic

Airport

Operator

Ground

Handler

Aircraft

Operator

Air Traffic

Controller

Passenger

Government

Agency

«flow»

«flow»

«flow»

«flow»

«flow»

«flow»

«flow»

«flow»

«flow»

«flow»


re-configuration that assists business coordination to address unplanned events such as severe weather. For example, dialogue through meaningful knowledge sharing was required to manage stakeholder expectations in a recent adverse weather condition that affected most UK Airports. The ecological metaphor has been widely adopted by IT Standards organisations (26 & 32) serving other communities. This is often referred to as Service Oriented Architecture (21, 22 & 26), the Digital Business System Ecology (41) and the recently announced Object Management Group’s Business Ecology Initiative (38). Researchers (50) at the MIT Sloan School’s Centre for Information System Research (CISR) developed a framework for the assessment of the stage of maturity of an enterprise’s digital ecosystem. The highest level of maturity (Level 4) is the “Business Modularity” stage. This stage is characterized by re-usable business process components or “plug and play” process modules that enable speed to market and strategic agility. ACI ACRIS recommends the Service Oriented Architecture approach to members of the Airport community as a mechanism for achieving the MIT Sloan Level 4 digital ecosystem maturity level. Among other factors including trust, the richness of a community’s interactions is an indicator of its “health” or sustainability (42). Community interactions which share knowledge rely on a common vocabulary which tends to differ from the Airport community level to the digital ecosystem level. To support rich interactions across the Airport community, shared knowledge at the community level must be used to capture shared vocabulary (community information standards) for the implementation of inter-organisational information systems. Software components that deliver software services must communicate to ensure coordination of service delivery. In the absence of information standards based on the Airport community’s shared vocabulary, the software components are unable to communicate in a meaningful way. It is therefore important to establish a shared business vocabulary based on the Airport community common business knowledge. The ACI ACRIS Semantic Model is the Airport community’s shared vocabulary and based on a representation of the community’s common knowledge.

ACI-ACRIS Services Orientation Strategy

The ACI ACRIS workgroup recommends the adoption of services orientation for the Airport ecosystem. Service Oriented Architecture is an approach to managing the complexity of the enterprise digital ecosystem to align technology with the business purpose. This approach reduces the brittleness between the business and digital ecosystems. This applies at various levels. At the Airport ecosystem level, service orientation is the perception of community members as modular components in a system that collaborates to deliver Airport services. At the Airport enterprise level, service orientation is the logical partitioning of the business into a number of modular business processes, people and knowledge that deliver discrete business services. At the technical level, service orientation is the identification and provisioning of software components and data that deliver cohesive and reusable software services that support the delivery of business services There are three common strategies to service orientation and these include:

1. Top-down strategy in which community services are defined based on a shared

community vocabulary (the ACI-ACRIS Semantic Model).

2. Bottom-up strategy where existing applications are exposed as web services.


3. Middle-out strategy that combines elements of the top-down and the bottom-up to deliver

services based on the ACI-ACRIS semantic model but also recognises the technical

constraints of existing investments in IT.

The ACI ACRIS recommends the middle-out strategy as it recognises that no Airport ecosystem constituent is an IT green-field site.

Benefits of the Middle – Out Approach to SOA

It supports community level standards based knowledge sharing across organisations in the Airport community.

It reduces the costs of business information exchange across the community. This is critical for the Baggage community which identified savings from reductions in lost baggage from improvements in Baggage messaging.

It takes the existing legacy application into consideration and leverages past investments in IT. It ensures that current IT infrastructure may not constrain future investments in IT by using a neutral information mediation layer for communications.

Airports are better able to control the costs of implementation inter-organisation business systems integration. Examples include the EUROCONTROL Airport Collaborative Decision Making (A-CDM) systems.

It enables IT innovation that leverages existing investments and new thinking that addresses real concerns of business management.

The middle-out strategy also enables the gradual roll-out of services in organizations while also providing a blueprint that guides future evolution of Airport community digital ecosystem.

The middle-out strategy also lends itself to the concept of the OMG Model-Driven Architecture which enables the generation of re-usable services artifacts from the ACI-ACRIS semantic model using widely available modeling tools.

It enables inter-community information exchange, for example, the Airport – Government Agencies information exchange because the ACI-ACRIS Semantic model is aligned to other community standards including the United Nations Centre for Facilitation of Trade (UN/CEFACT) and the World Customs Organisations (WCO) Data Model.

The ACI-ACRIS Semantic Model

It is shared vocabulary based on a representation of the Airport community common knowledge. A vocabulary comprises of business terms used by the Airport community to represent business ideas and documents these using internationally agreed terminology documentation methodologies (ISO 11179 and ISO15000). The Semantic Model comprises information standards based on the UNCEFACT Unified Modeling Methodology and the Core Component Technical Specification (CCTS). It leverages knowledge representation patterns which have been used to integrate divergent views of business operations. A semantic model is known by other names in different IT communities including:

Domain Model in the Domain and Software Engineering Community

Semantic Model in the Enterprise Architecture framework Community


Ontology in the Artificial Intelligence and Semantic Web Community

Conceptual Data Model in the Enterprise Data Modeling Community

Conceptual Class Model in the Object Oriented Analysis Community

Fact Model in the Business Rules Community Research and practice in some of these IT communities have historically developed in isolation. These communities may have purists with preferences for different symbols to capture community-specific style of knowledge representation but they all have one purpose which is the capture and representation of community common knowledge. The notation adopted by ACI-ACRIS is the widely used OMG Unified Modeling Language (UML) and the techniques are best practice across these communities.

Purpose of the ACI-ACRIS Semantic Model

The primary purpose of the model is to capture, represent and specify Airport community’s common knowledge in a standard and accessible form that enables integration of fragmented views of the Airport business. It also enables the specification of re-useable information services (ACI-ACRIS Services) across the Airport community.

Structural Composition of ACI-ACRIS Semantic Model

The ACI-ACRIS Semantic Model comprises of Airport domain concepts represented by business terms and the relationships between these terms. The concepts are ideas about the smallest unit of community knowledge. The concepts are entities commonly recognized by people working within the Airport. Figure 2 is a UML model that captures and illustrates relationships between an idea, knowledge, terms and vocabularies. Different business terms may represent a single idea and a single term may be used for different ideas depending on the context. An example of a term that may be used in several contexts is “Flight”. It may represent the service purchased by a Passenger or the movement of an Aircraft. An example of an idea with one or more terms is that of the “Aircraft Operator” which terms include “Airline” and “Carrier”. Different business term for a single idea may be preferred by different groups within the Airport community. For example, while the standards organisation, IATA uses the term Airline, the EUROCONTROL standards organisation uses Aircraft Operator in its information standards. An important part of the ACI-ACRIS semantic model development process is the identification, documentation of business terms (community vocabulary). In the ACI-ACRIS semantic model, business terms (for concepts) are represented by UML Classes (Business Entities). In the ACI-ACRIS model, the relationships between the terms are statements that express business assertions recognized to be true about the Airport ecosystem. Three types of relationships may exist between terms including:

1. Term has Term (Attributive relationships) 2. Term is a type of Term (Taxonomic relationships) 3. Entity is associated with entity (Association Relationships)


Figure 2: A model that relates the Airport community common knowledge to the shared vocabulary In the ACI-ACRIS semantic model, business terms are organised by subjects or topical areas. The subjects include Parties, Offerings, Places, Resources, Cases, Events, Interactions, Controls and Plans. These subjects were obtained by the application of the 5W (Where, What, Why, Who, When and Where) and 1 H (How) interrogatives to a typical Passenger journey scenario in the Airport. An analysis of the scenario description enabled us to identify terms that were abstracted to establish the ACI-ACRIS information subjects (Figure 3).

Knowledge

Idea

Term

Vocabulary

Unit of

Knowledge 1..*

Shared

Community

Knowledge

Standard

Term 1..*

Common

Vocabulary

Broader

Termrelates to

Narrower

Term

Business

Concept

described by

Symbol

Descriptive

Attribute

0..*


Figure 3. Passenger Travel scenario

Model Abstraction Levels (Figure 2)

The ACI-ACRIS semantic model has four primary abstraction levels including:

Information Archetype Level

This level is holds the most general categories of terms and serves to classify business terms within the Airport domain. Examples of archetype categories include Entities, Moments and Motivations. This level of abstraction is the most general of the ACI-ACRIS Semantic Model. It is documented in the OMG UML notation as a Package (Figure 6).

Information Subject Level

This abstraction level comprises categories which serve to classify Airport community concepts by information topics or subjects. Examples of subject categories include Offerings, Parties, Places and Agreements. This layer is also documented as a UML Package (Figure 6).

Plans

Events

Joe is traveling to Paris

on business from

Heathrow Airport

Agreements

Parties

ResourcesPlaces

Identities

Offerings

Cases

Interactions

Controls

Baggage

Security

Policies and

Rules

Check-In &

Boarding

Customer

Complaints,

Service Issues

Retail

Products

and

In-flight

Services

Passenger

Identity, Bag

Identity

Heathrow &

Paris Charles

De Gaul

Airports

Terminal

Lounges &

Vehicles

(includes

Aircraft)

Passengers,

Airlines,

Ground

Handlers

Contracts and

Service Level

AgreementsAircraft

Movement

Service

and Flight

Plans


Community level

This level holds business concepts that are common across different organisations that comprise the Airport community. The primary purpose of this level is to enable vocabulary integration across the enterprises that operate in the Airport. Examples of concepts at this level include Item, Aircraft Movement and Party

Enterprise Level

The purpose of this level is to hold concepts as used within the context of individual enterprises that operate or impact the operation of the Airport. This level holds concepts like Missed Bag, Luggage, Passenger, Marketing Airline and Scheduled Flight, Cargo Flight.

Figure 4. ACI-ACRIS Semantic Model Abstraction Levels

Information Archetype Layer

Information Subject Layer

Community Layer

Enterprise Layer


Figure 5. ACI-ACRIS Semantic Model (Information Blueprint View)

Community Information Blueprint

Entities

Moments

Motivations

Offerings Parties Places Resources

Facility

Revenue

Party

Party Role

Location

Address

Item

Transport

Cases Events Interactions

Compliance

Episode

Incident

Movement

Action

Communication

Agreements Controls Plans

Arrangement

Obligation

Governance

Law

Business Direction

Measure

Budget

Work Effort

Risk

Specification

Channel

Medium

Social

Environment

Permission

Good

Assistance

Service


Figure 6. A UML Package View of the ACI-ACRIS Semantic Model

The ACI-ACRIS Semantic Model Development Process

The process outlined below is recommended for the development of the ACI-ACRIS semantic model. This method identifies terms from business sources including documents and domain experts and uses these to identify recurring patterns of relationships between the terms (Knowledge Representation Patterns). These patterns are translated into UML components and relationships established with business statements to compose the ACI-ACRIS semantic model. The development process is based on the research (1, 2, 5, 6, 6, and 18) and successful practical implementations (8, 12, 15, and 22) within and outside the Airport community. The process is aligned to the UN/CEFACT’s Unified Modeling Methodology (UMM). The process comprises of the following steps:

1. Abstract and document Airport community common knowledge

a. Abstract Airport community knowledge to identify re-usable knowledge

representation patterns. These patterns are also known as Taxonomies (18, 20 &

23). This activity includes analysis of various knowledge sources including

process knowledge descriptions, domain models from the different communities

that comprises the Airport ecosystem, existing ACI-IATA information exchange

schema (IATA AIDX and PADEX), documents and domain experts (12, 13). The

derived knowledge representation patterns are agreed by the community. Figure

6 is an example of a pattern for the term, “Party”.


Figure 7: Party Pattern 2. Arrange the patterns to populate the ACI-ACRIS information blueprint

a. The patterns are organised to establish the Airport community blueprint (5, 6 &

9, 12 & 15)

3. Use the Patterns to establish UML components.

a. The highest term in the pattern corresponds to a UML class and the terms below

it on the pattern are often its categories (or types). This step involves activities

that translate the knowledge representation pattern to a UML component

comprising of an entity class, the entity class type and an entity category. Figure

8 illustrates a UML component derived from the party pattern. Appendix B holds

the diagrams (Figures 14- 25) that illustrate other knowledge representation

patterns and their equivalent UML components.

Party

Person Organisation

Informal

Organisation

Legal

Organisation


Figure 8: A UML Component Derived from the Party Pattern

4. Integrate the Knowledge Components using Assertions (Business Rules)

a. Associate the UML components to build the ACI-ACRIS semantic model using

statements that express relationships (assertions known as fact types in the

business rules community). Figure 9 illustrates a semantic model fragment

created from some of the UML components listed in Appendix B

Party Type

Party

Party

Category

defines

belong to


Figure 9. Airport Community Semantic Model (A Fragment of the Business Rules View)

5. Apply the ACI-ACRIS Semantic Model to Integrate fragmented information schema

a. Use the semantic model to categorize and integrate the data items in existing

data sources.

Uses of the ACI-ACRIS Semantic Model

The ACI-ACRIS semantic model may be put to a number of uses which include process improvement, reusable software service discovery and definition, information modeling, reusable XML component development and XML message schema composition.

Semantic Business Process Improvement

Semantic business process improvement (SBPM) is the application of domain knowledge in the form of a semantic model to the definition and improvement of business processes. This concept is not new as it has been a part of the Information Engineering approach to process innovation as documented by Clive Finklestein.

Movement

Movement Type

Transport

Transport Type

Item

Item Type

Party

Airline

operates

Aircraft

Passenger

owns

Bag

Conveyor BeltconveysBag

Aircraft

is used

Scheduled

Flight

definesdefines

defines


Most business activities process information. These processes are commonly named based on the naming standard which combines a verb with a noun – “Verb” + “Noun”. For example the check-in of a bag may be named “Register Bag”. The acquisition of cargo may also be named “Register Cargo”. The abstraction of business processes based on the ACI-ACRIS semantic model names indicates opportunities for process definition re-use. Still using the example above, both “Register Bag” and “Register Cargo” may become “Register Item” where the type of item may be a Bag or Cargo. It is then possible to identify similar activities within the Baggage Handling domain and the Cargo Handling domain for which one service definition may support.

Reusable Service Definition

The purpose of service orientation at the software level is the definition of re-usable services in various business contexts. An often cited criticism of the use of object oriented modeling methods for service definitions has been the resultant low level of granularity of services which are often not reusable. This approach creates model components that enable re-use in several business contexts. Examples where service re-use may occur include:

The party component enables the reuse of services for Passenger, Business Partner Relationship Management like the Airport-CDM (A-CDM), Customer Relationship Management (CRM) and Employee / Talent Management (HRM) contexts.

For Airports that are multi-modal transportation hubs, the Movement component enables the development of services for aircraft movement (flight), automobile movement (track vehicles within Airport perimeters) and rail movement (for Airports like Heathrow and Gatwick that operate Transit Vehicles and /or Rail transportation).

The Item component enables the same service to be reused or re-purposed for Bags and Cargo handling.

The benefit of this capability is the reduction in application integration costs and the ability to rationalize the application landscape which holds redundant application functionalities.

Information Standards Definition

There are many standards organisations currently developing standards for the Airport community including ACI, IATA, OpenTravel and EUROCONTROL SESAR. The ACI-ACRIS Semantic model must be able to re-use existing and future information standards from these standards organisations and more outside the list above. The ACI-ACRIS semantic model is an integration of multiple domain vocabularies to facilitate an integrated community vocabulary for specifying the structure of business documents exchanged by services. The ACI-ACRIS is used to define an information model (Figure 9) by populating it with business facts (UML Class Attributes) based on an understanding of the rationalized data items from business documents (for example, the ACI-IATA AIDX and EUROCONTROL FOIPS) and other data sources. The international standards ISO 11179 (51 & 52) and ISO 15000 (14) are applied to achieve standard data item names. The UML stereotypes <<ABIE>> and <<BBIE>> are obtained from the UN/CEFACT ISO 15000. These stereotypes mean that the class diagrams hold classes that represent aggregate business information entities (ABIE) and basic business information entities (BBIE) and these are not software classes.


Figure 10. Fragment of the ACI-ACRIS Information Model

Reusable Library of XML Components

Given that the purpose for creating the ACI-ACRIS semantic model is to utilise community knowledge to drive the development of information services artifacts that enable digital information exchange. The fragment of the ACI-ACRIS Information Model in figure 9 was utilised to create a library of re-usable XML components (figure 10) that could be used as the building blocks for composing XML based messages. These components are global “simpleType” components which naming standard is based on the ISO 11179. The tool used, Sparxsystems Enterprise Architect enforces the naming standards based on rules derived from the ISO11179 standard. Figures 11 and 12 illustrates an example of how an XML message schema may be defined using the component library. Figure 13 is the XML schema directly generated from the UML document model.

«ABIE»

Movement

«BBIE»

+ Number: Integer

+ Description: String

+ Date: Date

+ Scheduled Time: Time

+ Public Time: Time

+ Onblock Time: Time

+ Offblock Time: Time

«ABIE»

Movement Type

«BBIE»

+ Identifier: String


«ABIE»

Party

«BBIE»

+ First Name: String [0..1]

+ Surname: String [0..1]

+ Role: String

+ Name Record: String [0..1]

«ABIE»

Item

«BBIE»


+ Tag Number: String [0..1]

+ Type: String

+ Usage: String [0..1]

«ABIE»

Item Type

«BBIE»



«ABIE»

Transport

«BBIE»

+ IATA Identifier: String

+ Description: String [0..1]

+ Model: String [0..1]

+ Type: String

+ Category: String [0..1]

«ABIE»

Transport Type

«BBIE»



1..*

1..*

10..*

1..*

0..*

1..*

0..*

1..*

1..* 1..*


Figure 11. Library of reusable XML components generated from the figure 9 model fragment

Figure 12. A UML Model of an Passenger XML Message. <?xml version="1.0"?>

<xs:schema targetNamespace="http://www.aci-acris.org" xmlns:xs="http://www.w3.org/2001/XMLSchema"

elementFormDefault="qualified" version="0.8">

<xs:simpleType name="ItemTagNumberType">

<xs:restriction base="xs:string"/>

</xs:simpleType>

<xs:simpleType name="MovementNumberType">

<xs:restriction base="xs:integer"/>

</xs:simpleType>

<xs:simpleType name="PartyNameRecordType">


</xs:simpleType>

<xs:simpleType name="PartySurnameType">


</xs:simpleType>

<xs:element name="PassengerInformation" type="PassengerInformation"/>

<xs:complexType name="PassengerInformation">

string

«XSDsimpleType»

PartyFirstNameType

string

«XSDsimpleType»

PartySurnameType

string

«XSDsimpleType»

PartyNameRecordType

«enumeration»

PartyTypeCode

Person

Organisation

Group

string

«XSDsimpleType»

ItemIdentifierType

string

«XSDsimpleType»

ItemTagNumberType

string

«XSDsimpleType»

ItemUsageType

string

«XSDsimpleType»

MovementDescriptionType

integer

«XSDsimpleType»

MovementNumberType

«enumeration»

TransportCategoryType

string

«XSDsimpleType»

TransportCategoryType

string

«XSDsimpleType»

TransportDescriptionType

string

«XSDsimpleType»

TransportIATAIdentifierType

string

«XSDsimpleType»

TransportModelType

string

«XSDsimpleType»

TransportRegisterationNumberType

string

«XSDsimpleType»

PartyFirstNameType

string

«XSDsimpleType»

PartySurnameType

string

«XSDsimpleType»

PartyNameRecordType

string

«XSDsimpleType»

ItemTagNumberType

«XSDcomplexType»

PassengerInformation

«XSDelement»

+ PassengerFirstName: PartyFirstNameType [0..1]

+ PassengerSurname: PartySurnameType [0..1]

+ PNR: PartyNameRecordType [0..1]

+ BagTagNumber: ItemTagNumberType [0..1]

+ FlightNumber: MovementNumberType [0..1]

integer

«XSDsimpleType»

MovementNumberType


<xs:sequence>

<xs:element name="PassengerFirstName" type="PartyFirstNameType" minOccurs="0" maxOccurs="1"/>

<xs:element name="PassengerSurname" type="PartySurnameType" minOccurs="0" maxOccurs="1"/>

<xs:element name="PNR" type="PartyNameRecordType" minOccurs="0" maxOccurs="1"/>

<xs:element name="BagTagNumber" type="ItemTagNumberType" minOccurs="0" maxOccurs="1"/>

<xs:element name="FlightNumber" type="MovementNumberType" minOccurs="0" maxOccurs="1"/>

</xs:sequence>

</xs:complexType>

<xs:simpleType name="PartyFirstNameType">


</xs:simpleType>

</xs:schema>

Figure 13. XML schema generated from the UML Passenger Message model in figure 11.

ACI-ACRIS Semantic Model and other Industry Models

In the Aviation industry, the ACI ACRIS is the currently the only industry semantic model that is aligned to the ISO 11179 and ISO 15000 international standards. It is designed to subsume enterprise – and business domain - level models and so is comparable to the World Customs (WCO) Data Model (53), the UN/CEFACT Transportation model (an extension of the OASIS Universal Business Language). It is comparable to the Telecommunications industry TM Forum SID (24) and the Insurance industry ACORD (25)

The ACI-ACRIS Semantic Model Roadmap

The first version of the ACI-ACRIS Semantic Model will be published as part of the IATA Baggage XML Workgroup information standards. In this version, existing information standards including the IATA-ACI AIDX and PADEX will be integrated using the ACI-ACRIS Semantic Model. This has been achieved at BAA and the resulting artefacts are being used within the Heathrow Baggage transformation programme.


Benefits of the ACI-ACRIS Semantic Model

The ACI-ACRIS semantic model provides a number of benefits including:

Members of the Airport community are able to develop IT assets based on common knowledge of the Airport ecosystem and shared business vocabulary (20 & 23) expressed as the ACI-ACRIS semantic model. This model will help community members reduce risks inherent in IT systems implementation and resultant costs.

Members of the Airport community are able to deploy new systems or integrate existing systems that deliver quality information for improved decision-making which results in increasing employee productivity.

Members of the Airport community are able to utilise the ACI-ACRIS semantic model as an IT planning tool for benchmarking existing and planned IT investments. The model enables the rationalization of applications within Airport community member’s digital ecosystem.

Members of the Airport community may use the model to define their enterprise services blueprint (inventory). The Airport community semantic model provides a basis for the consistent identification of business services at a level of granularity that ensures re-use across the community (17).

The use of the ACI-ACRIS semantic model will enable the community improve existing information standards development efforts (ACI-IATA) by providing a common framework for documenting information requirements.

The ACI-ACRIS semantic model has been proven to integrate existing disparate community information standards by using a consistent community neutral vocabulary. This enables the community to leverage existing and future information standards from IATA, ACI, EUROCONTROL SESAR, SEMIC-EU, UN/CEFACT and OpenTravel.


Annex A: Reference

1. Christopher Welty , Nicola Guarino. Supporting Ontological Analysis of Taxonomic Relationships (2001) 2. Nicola Guarino. Formal Ontology, Conceptual Analysis and Knowledge Representation (1995) 3. Thomas R. Gruber. Toward Principles for the Design of Ontologies Used for Knowledge Sharing (1993) 4. Randall Davis , Howard Shrobe , Peter Szolowits. What is a Knowledge Representation? (1993) 5. Jeon Sofia & II-Yeol Song. OMP = Ontology + Patterns. College of Information Science. Drexel University. Philadelphia. USA. 6. Il-Yeol Song, Kurt Yano, Drexel University, USA, Juan Trujillo and Sergio Luján Mora, University of Alicante, Spain. Taxonomic Class Modeling Methodology for Object Oriented Analysis. In Information Modeling Methods and Methodologies. 2004 7. James Bean. SOA and Web Services Interface Design. Principles, Techniques and Standards. 2010. (Page 31) 8. Segun Alayande. BAA Common Information Model. BAA Airports Limited. United Kingdom. 2010 9. Modelware International Pty Ltd. Business Classification Model Methods Guide. 1999. 10. Dave McComb. Semantics in Business Systems. The Savvy Manager's Guide. Morgan Kaufman. 2004 (Chapters 12 & 13) 11. Patrick Grassle, Henriette Baumann, Philippe Baumann. UML 2.0 In Action. A Project Based Tutorial (Chapter 5). 12. ASC X12. Reference Model for XML Design. 2002 (Sections 4.4 - 4.7) 13. Chris Partridge. Business Objects. Re-engineering for Re-Use. 2005 14. ISO/TS 15000-5:2005. Electronic Business Extensible Markup Language (ebXML) -- Part 5: ebXML Core Components Technical Specification, Version 2.01 15. Open Group. Universal Data Definition Framework (UDEF). 16. IBM. IBM Industry Models for Financial Services. The Information FrameWork (IFW) Process Models () 17. Mike Rosen, Boris Lublinsk, Kevin T Smth, Marc J. Balcer. Applied SOA. Service Oriented Architectures and Design Strategies. (Chapter 5 ) 18. Semantic Interoperability Centre Europe (SEMIC EU). Study on Methodology. Http://www.semic.eu/semic/view/.../semic-eu-study-on-methodology-v1.2.pdf 2009. 19. Dirk Krafzig, Karl Banke, Dirk Slama. Enterprise SOA: Service-Oriented Architecture Best Practices. (Chapters 5 & 6) 20. Patrick Lambe. Organising Knowledge: Taxonomies, Knowledge and Organisational Effectiveness. Chandos Publishing 2007 21. Paul C. Brown. Implementing SOA: Total Architecture in Practice. Addison Wesley Professional. 2008 (Chapter 20- 26) 22. IBM. Building Service-Oriented Banking Solutions with IBM Banking Industry Models and Rational SDP. 23. Jan Wyllie, in association with David Skyrme and Simon Lelic. Taxonomies: Frameworks for Corporate Knowledge 24. John P. Reilly. Getting Started with the SID. A SID Modelers Guide. Tele-Management Forum. April 2007 25. Frank Neugebauer, Boris Bulanov and Kenneth Ekers. The ACORD Information Model. A Primer. ACORD. 2009. 26. Serge Garcia, Iwan Gramatikoff and John Wilmes. Business Transformation with TM Forum Solution Frameworks and SOA. TeleManagement Forum. March 2009.


27. John P. Reilly and Mike Kelly. The eTOM. A Business Process Framework Implementer’s Guide. TeleManagement Forum. April 2009. 28. John P. Reilly and John Wilmes. Application Integration Using the SID. TeleManagement Forum. April 2008. 29. Jeffrey T. Pollock and Ralph Hodgson. Adaptive Information. Improving Business Through Semantic Interoperability, Grid Computing and Enterprise Integration. 2004. Wiley. 30. Rob Cross and Robert Thomas. Driving results Through Social Networks. How Top Organisations Leverage networks for Performance and Growth 31. Ronald G. Ross. Business Rule Concepts. Getting to the Point of Knowledge. Business Rule Solutions. 2005. 32. Bruno Bonati, Joachim Regutzki and Martin Schroter. Enterprise Services Architecture for Financial Services. Taking SOA to the Next Level. SAP Press. 2005. 33. Nancy M. Dixon. Common Knowledge. How Companies Thrive by Sharing What They Know. Harvard Business School Press. 2000 34. Thomas H. Davenport & Lawrence Prusak. Working Knowledge. How Organisations Manage What They Know. Harvard Business School Press. 1998. 35. Moore, J.F. The Death of Competition: Leadership & Strategy in the Age of Business Ecosystems. New York, Harper Business, 297p. 1996. 36. Quinn, James Brian. Intelligent Enterprise: A Knowledge and Service based Paradigm for Industry, The Free Press, New York, 1992. 37. Marco Iansiti and Roy Levien. The Keystone Advantage. What the New Dynamics of Business Ecosystems Mean for Strategy, Innovation and Sustainability. Harvard Business School Press. 2004. 38. OMG. Business Ecology Initiative. http://www.business-ecology.org/ 39. Tian C.H et al. BEAM. A Framework for Business Ecosystem Analysis and Modeling. IBM Systems Journal Vol. 47. Number 1. 2008. IBM. 40. Guimera R and Amaral L.A.N. Modeling the World-Wide Airport Network. European Physical Journal B. Issue 38. 2004. 41. FP6 IST e-Business Integrated Project. The Digital Business Ecosystem. November 2003. 42. Joseph Abe, Patricia Dempsey and David Basset. Business Ecology. Giving Your Organization the Natural Edge. Butterworth Heinemann 1998. 43. Brian Byrne, John Kling, David McCarty, Dr. Guenter Sauter, Peter Worcester. The Information Perspective of SOA Design, Part 4: The Value of Applying the Canonical Modeling Pattern in SOA. 2008 44. Holger Kett, Konrd Voight, Gregor Scheithauer and Jorge Cardoso. Service Engineering in Business Ecosystems. The THESEUS programme. http://www.thesesus-programm.de 45. Stephen Pryke and Hedley Smyth. The Management of Complex Projects. A relationship Approach. Blackwell Publishers. 2006 46. Jeffrey Word. Business Network Transformation. Strategies to Reconfigure Your Business Relationships for Competitive Advantage. Jossey Bass. 2009. 47. frank Binnekade, Robert Biciocchi and Brian E. O’Rourk. Creating Smarter Airports. An Opportunity to Transform Travel and Trade. IBM Whitepaper. 48. Eric Van Heck and Peter Vervest. Smart Business Networks. How the Network Wins. Communications of the ACM. Volume 50. No 6. June 2007. 49. Richard Veryard. Ecosystem SOA. http://rvsoapbox.blogspot.com/2009/10/ecosystem-soa.html. Last viewed on 19.01.2011 50. Jeanne W. Ross, Peter Weill and David C. Robertson. Enterprise Architecture as Strategy. Creating a Foundation for Business Execution. Harvard Business School Press. 2006. 51. ISO 11179. Information technology — Metadata Registries (MDR) — Part 4: Formulation of data definitions. 2004 52. ISO 11179. Information technology — Metadata Registries (MDR) — Part 5: Naming and identification principles. 2005.

http://www.business-ecology.org/

http://www.thesesus-programm.de/

http://rvsoapbox.blogspot.com/2009/10/ecosystem-soa.html

http://rvsoapbox.blogspot.com/2009/10/ecosystem-soa.html


53. WCO Customs data Model. http://www.wcoomd.org. Last accessed on the 19.01.2011.

http://www.wcoomd.org/


Appendix B. Knowledge Representation Patterns and UML Components

Figure 14. Movement Pattern.

Figure 15. Movement UML Component

Movement

Movement Type Movement Category

defines belong to

Movement

Aircraft

Movement

Rail

Movement

Automobile

Movement

Ground

Movement

Runway

Movement

Airspace

Movement

Apron

Movement


Figure 16. Offering Pattern.

Offering

Service Product

Aeronautical

Service

Non-Aeronautical

Service

Retail

Service

Baggage

ServiceFlight

Service

Facility

Building Node

Terminal

BuildingFire Station

Offering

Offering Type Offering Category

defines belong to


Figure 17. Offering UML Component

Figure 18. Party Pattern.

Figure 19. Party UML Component

Party

Party Type Party Role

belong todefine

Person

Party

OrganisationGroup


Figure 20. Party-Role Pattern.

Figure 21. Party-Role UML Component

Party Role

PassengerAirport

OperatorAirline

Party Role Type

Party Role

Party Role Category

belong todefines


Figure 22. Item Pattern

Figure 23. Item UML Component

ItemItem Usage

Container Consumable

BagUnit Load

Device

Logistic

Item

Material

Item

Item Type

Item

Item Category

belong todefines


Figure 24. Transport Pattern

Figure 25. Transport UML Component

Transport

VehicleTram Dolly

CraftWheeled

VehicleRocket

Aircraft VesselCar

Transport

Transport Type Transport Category

defines belong to


Annex B: Concept Definitions

Archetype Definitions

Concept Definition

Moments

Motion

Motivation

Information Subject Definitions

Concept Definition


Concept Definition

32

aci acris semantic model for service oriented architecture v1.0

Documents