what is a business model ontology

Presented by Mark von Rosing DOI: 10.13140/RG.2.1.4141.4481 [1]

The Business Ontology presented in this publication has taken the Global University Alliance members over a decade to research and develop, with hundreds of ‘man years’ involved to create the product introduced in this paper. This paper provides an overview of he business ontology research and analysis done and elaborates on its development and adaption journey. This research paper therefore has the aim to provide an overview of the research and analysis that has been done around the subject of Business Ontology. It does so by firstly defining what Ontology means in the context of this research after which it elaborates on the chosen research approach. It than describes how the Business ontology is a part of formalizing a Domain Ontology. Followed by a historic overview of the Business Ontology development adaption and how the business ontology is used to develop enterprise and industry standards. The Overview of the Business Ontology Research & Analysis paper than concludes with mentioning the main research team members.

What is Ontology in the context of the research

As ontology formally represents knowledge as a set of concepts within a domain, and the relationships between those concepts, it can be used to model a domain and support reasoning about concepts. The Global University Alliance has used the concept of ontology as both a shared vocabulary and the very definition of its objects and concepts. In order to go the next steps and fully use the potential of its ontology.

The Research Approach

The Global University Alliance (GUA) is an open group of academics with the ambition to provide both business and academia with state-of-the-art insights. Through its ties with the LEADing practice community, which includes large firms and governments, the GUA is able to evaluate and valorize its scientific output. Since 2004, the members of the GUA strive for a continuous improvement of their expertise through the research, comparison, analysis and development of Best and LEADing Practices in Business. Throughout this process, the GUA built its own implicit ontology that revolves around its expertise of Best and LEADing practices.

This is where the Global University Alliance (GUA) has developed a unique collaborative process between research and industry. After 5 years of already working together, the GUA was founded in 2004 as a non-profit organization and today (September 2015) they are an international consortium consistent of over 450+ professors, lecturers and researchers whose aim it is to provide a collaborative platform for academic research, analysis and development. As illustrated in figure 1, they do this through defining clear research themes, with detailed research questions, where they analyse and study patterns, describe concepts with their findings. This again can lead to additional research questions/themes as well as development of artefacts which can be used as reference content by practitioners and industry as a whole. What the GUA also does uniquely is the collaboration with standards bodies like:

• ISO: ‘The International Organization for Standardization (French: Organisation internationale de standardization)
• CEN: The European Committee for Standardization (CEN, French: Comité Européen de Normalisation).
• IEEE: Institute of Electrical and Electronics Engineers is the largest association of technical professionals with more than 400,000 members
• OMG: Object Management Group: Develops the software standards.
• NATO: North Atlantic Treaty Organizations (NATO’s) with the 28 member states across North America and Europe and the additional 37 countries participate in NATO’s Partnership for Peace and dialogue programmes, NATO represents the biggest non-standard body that standardises concepts across 65 countries.
• ISF: The Information Security Forum, Investigates and defined information security standards.
• W3C: World Wide Web Consortium- The W3C purpose is to lead the World Wide Web to its full potential by developing protocols and guidelines that ensure the long-term growth of the Web/Internet.
• LEAD: LEADing Practice, the largest enterprise standard body (in member numbers), which actually has been founded by the GUA.  The LEADing Practice Enterprise Standards are the result of both the GUA research and years of international industry expert consensus and feedback on the artefacts and thereby repeatable patterns.

The Business Ontology: Formalising a Domain Ontology

All ontologies have a controlled vocabulary as a foundation. (Lassila & McGuinness, 2001) As the business ontology is an extensive ontology that has the ambition to cover all aspects of business (as opposed to academic ontologies), its terms are organized in a top-level domain and multiple intersecting subdomains (e.g., Business Competency, Business Process, Infrastructure). Figure 2 shows that the business ontology’s top-level has been formalised into the following four levels:

• Business Ontology Meta Meta Models
• Business Ontology Meta Models
• Business Ontology Models
• Business Ontology Objects

Historic overview of the GUA Business Ontology

The first GUA Business Ontology research was published within the LEADing Practice concepts in December 2004 and today resulted in the Business Ontology Framework. The Initial Business Ontology modelling and architecture principles yielded the attention of mayor software vendors like SAP AG, IBM, Software AG (IDS Scheer and ARIS). Some of these vendors used our entire conceptualization, while others adapted the Business Ontology meta-model or specific concepts e.g. eXtended BPMN concepts. IGrafx, which is a new player in the extended process modeling field, currently incorporates our modelling aspects into their methods and or meta-models.

Below is a short overview of the fast adoption of GUA-concepts by industry:

• 2009 our information ontology modelling and architecture concept was presented at SAPphire 2009 (SAP biggest customer event).
• 2010, our process and measurement ontology principles where presented at the IDS Scheer, ARIS Process World.
• 2010, the Official SAP book was published, using our Business Ontology  principles: Taylor, J,  von Rosing, M.,  von Scheel, H., Rosenberg, A., Applying Real-World BPM in an SAP Environment, Issue Date: 2011-01, Published by: SAP Press, ISBN: 978-1-59229-343-8, Page(s): 694.
• 2011, The Institute of Electrical and Electronics Engineers publishes a paper based on the research and findings around combining our Business Ontology process and architecture principles: Presten, T., Hove, M., von Rosing, M., Academic paper on Combining BPM and EA in Complex IT Projects, Published by: IEEE Commerce and Enterprise Computing Page(s): 271 – 278, Issue Date: 2011-05.
• 2010-2012, the Global University Alliance collaborated with TOGAF (The Open Group Architecture Framework) to develop the profession of a Business Architect, this included the business and process ontology modelling as well as architecture principles.
• 2010-2011, SAP adapted the process, value, measurement ontology modelling principles into their SAP ASAP Method, thereby the SAP customers apply the process, value, measurement ontology modelling principles within their blueprint, implementation, maintenance and upgrade methods and approaches.
• 2011-2012: Software AG-IDS Scheer enhace their ARIS process modelling meta model, based on the LEADing Practice ontology concepts.
• 2012: OMG & GUA start to collaborate on joints developments.
• 2012, the Government of Canada, uses the LEADing Practice Business Ontology modelling and architecture concepts to transform their organization as well as blueprint/implement SAP and Oracle ERP systems.
• 2012-2013: IGrafx, builds the entire LEADing Practice Business Ontology modelling and architecture concepts into their process flow, process modeller, performance reporting and enterprise modeler software.
• 2013, LEGO Group wins the Gartner Group‘s BPM award: Best BPM Transformation by leveraging the LEADing Practice Business Ontology principles.
• Sept 2013 LEAD 3.0 is published having the full Business Ontology concepts within them and has a community of over 2500 certified practitioners.
• 2012: Elsevier asks GUA to write officially with OMG/LEAD & GUA logo ‘The Complete Business Process Handbook’ series, which will consist of over 2100 pages together.
• 2013: German Government receives the GUA/LEADing Practice award of the year based on their extraordinary Service Oriented and BPM automation using extended BPMN and business architecture principles.
• 2013/4: OMG & GUA partnership moves to a strategic partnership.
• 2014: GUA members are asked to join the International Standardization Organization (ISO) to do joint developments (based on the Business Ontology).
• 2014: the US Government joint the LEADing Practice community and they do joint development around the Alignment Unity Framework and Reference Content.
• 2014: Prof. August-Wilhelm Scheer the fathers of process modelling, BPM as well as ARIS, receives a Life Time Award from the Global University Alliance and LEAD Community.
• 2014: NATO partners with GUA/LEAD to develop the enterprise standards for a 5-year timeframe.
• 2014/2015: John A. Zachman the fathers of Enterprise Architecture thinking today joins the Board of LEADing Practice and Global University Alliance.
• 2015: European Airtraffic Management Systems are coordinated across International countries using the GUA Business Ontology.

Developing Enterprise & Industry Standards based on the Business Ontology

The recent Business Ontology workgroup within the Global University Alliance, has adopted the concept of holistic Business Ontology Frameworks, as it identified the necessity of introducing such a framework into today’s enterprises through the LEADing Practice community. In order to develop this Business Ontology Framework, the GUA recently started looking for more mature business and enterprise ontologies that could provide them with state of the art semantics they could found their practices on. These practices should promote new ways of thinking, working and modelling about value identification, creation, and realization through the use of Business Ontology.

The Business Ontology concepts in the framework should provide sound semantic foundations for best and LEADing practices in different domains (e.g. process, service, value, information). The concepts and practices will be shared and published as an open standard in the LEADing Practice community. Thereby enabling all academics and practitioners in the community to build on common leading principles to identify, create and realize value, competitive advantage and agility to deal with future challenges. To realize this vision, the GUA alliance reaches out to all business and Business Ontology researchers to contribute to the consolidation of academic findings in a research-based Business Ontology Framework that can be used by industries and universities alike.

Based on the Business Ontology various Enterprise & Industry Standards have been developed. The standards are both agnostic and vendor neutral and are built on repeatable patterns that can be reused/replicated and thereby implemented by any organization, both large and small, regardless of its products/services or activities. All together describing the set of procedures an organization needs to follow in order to replicate the ability to identify, create and realize value in the specified area/subject. The Standards have been developed in the following ways:

• Research and analyze Industry Best Practice & Leading Practices.
• Identify common and repeatable patterns (the basis of our standards).
• Apply the identified repeatable patterns to the Business Ontology meta objects, models, meta model and meta meta model to develop a sound re-usable and replicable standard.
• By using the developed standard, capture the the common output to build specific accelerators within the standards, enabling to adopt and reproduce the Best & Leading Practices faster.

What the Enterprise & Industry Standards include

We realize that organizations apply various method and approaches, therefore we have ensured that based on the business ontology all our Industry Standards have a structured Way of Thinking, Working, Modelling, Implementation and Governance. To ensure full integration to other method and approaches within an organization, the industry standards have the business ontology and with it the semantic concept build in that allows for the industry standards meta objects to be reused and thereby applied.

This includes applying the standards to:

• engineering principles – how and where it can or needs to be decomposed and composed together,
• modelling principles – which design concepts can or should be applied, and;
• architecture principles – which architecture rules apply and which artifacts and templates e.g. maps, matrices and models could or should be used.

Creating the ability to use the Ontology and Semantics to develop standards with reference content, making it easier, less time consuming and cheaper to apply object descriptions, relations and rules to enable Enterprise Modelling, Enterprise Engineering and Enterprise Architecture. Developing whole new standards that are fully integrated and standardized based on a sound Business Ontology. While multiple standards have been developed linked or based on the business ontology [2] , for an overview of the the standards developed in the LEADing Practice standard body, which is the GUA standardization arm please visit the referenced link [3] .

Research Team

If you are interested in or would like to contribute to the Business Ontology Framework, do not hesitate to contact the coordinator.

Research Coordinator: Professor Wim Laurier Saint-Louis University Brussels & Ghent University, Belgium

LEADing Practice Coordinator: Georg Etzel LEADing Practice, Co-CEO

Global University Alliance Coordinator: Professor Mark von Rosing Head of Global University Alliance, Denmark

The members involved in this work have been a team that includes academics, researchers and analysts:

• Enterprise Ontology, Wim Laurier
• Enterprise Semantics, Simon Polovina
• Business Model, Mark von Rosing
• Business Process Management, Marlon Dumas
• Information Management, Hans Scheruhn
• Value & Performance Management, Maria Hove
• Enterprise Sustainability, David Coloma
• ERP, Karin Gräslund
• Enterprise Services, Maxim Arzumanyan
• Enterprise Modelling, Ulrik Foldager
• Measurement & Reporting, Ulrik Foldager

[1] OMG Standards: https://www.omg.org/news/releases/pr2014/10-29-14.htm . [2] LEADing Practice Standards: https://www.leadingpractice.com/wp-content/uploads/2014/03/LEADing-Practice-Enterprise-Standards-Industry-Standards.pdf Internet Standards: W3C www.w3.org/2001/11/StdLiaison#L [3] Published in: https://www.researchgate.net/publication/287958619_Overview_of_the_Business_Ontology_Research_Analysis

Article Contents

1. introduction, 2. definitions and requirements as units of analysis, 3. capability meta-model, 4. implementing the capability meta-model as rdf ontologies, 5. capability of a business process, 6. evaluation of the meta-model, 7. related work, 8. conclusion.

• < Previous

Using Ontologies for Business Capability modelling: Describing What Services and Processes Achieve

• Article contents
• Figures & tables
• Supplementary Data

Wassim Derguech, Sami Bhiri, Edward Curry, Using Ontologies for Business Capability modelling: Describing What Services and Processes Achieve, The Computer Journal , Volume 61, Issue 7, July 2018, Pages 1075–1098, https://doi.org/10.1093/comjnl/bxy011

• Permissions Icon Permissions

In current business process modelling environments, the functional perspective (also can be referred to in the literature as business capability, functionality or business function) for each process activity is limited to its label. Using labels only prevents stakeholders from easily and quickly understanding what business processes or services achieve. In this paper, we define a business capability meta-model that can be used for modelling business capabilities as entities composed of a set of actions and related properties. This meta-model is implemented as Resource Description Framework (RDF) vocabularies that help experts design their domain-specific high-level business capabilities that can be used for annotating their processes, services, applications, etc. We validate the business capability meta-model by using two evaluation methods: (1) ontological evaluation in order to make sure that there is no semantic ambiguity among its constructs; (2) interviews with domain experts to assess the ability of the model to represent real capabilities and to evaluate their point of view with respect to our approach.

In current business process models, the functional perspective (also can be referred to in the literature as business capability, functionality or business function) for each process activity is limited to its label [ 1 ]. A single label is not enough to describe properly the capability of a particular process element (i.e. activity, fragment or entire process). Using labels only prevents stakeholders from easily and quickly understanding business processes or identifying the differences and commonalities between them in terms of business properties [ 2 ]. When required, stakeholders need to read the business process documentation in order to find out what a process element does, expressed in terms of business properties.

Information Systems’ vendors such as IBM, Oracle or SAP offer together with their solutions the related documentation that is usually (1) extremely large and (2) combines various levels of the technical implementation [ 3 ]. For example, searching in SAP ERP documentation requires in depth knowledge of a large and proprietary terminology [ 3 ]. This problem can be resolved by properly describing capabilities in a way that serves machine processing (well-structured capabilities allow for their indexing, searching, detecting differences between them, etc.) and featuring business rather than technical terms (business properties that business experts are familiar with). Therefore, the problem that we are addressing in this paper is the lack of a structured business capability model that allows to describe what services, processes, computer applications, etc. do from a functional perspective.

This problem has been investigated for the modelling of IT capabilities. Indeed, the literature proposes various IT capability description approaches as a part of efforts for describing related concepts such as business processes, services and search requests (WSMO [ 4 ], OWL-S [ 5 ], SA-WSDL and SA-REST [ 6 , 7 ]). They primarily describe capabilities either as part of their implementations (i.e. invocation interface) or as part of other concepts (i.e. services). For all these approaches, the semantics of the action performed by services are derived through reasoning over its inputs, outputs, preconditions and effects (IOPE). The main criticism towards these approaches comes from the fact that they mainly focus on modelling IT capabilities rather than business capabilities.

Oaks et al . [ 8 ] explores a frame-based modelling approach for describing service capabilities by using natural language constructs such as the action performed and associated parameters (i.e. temporal, location, etc.). Even though the action performed is captured in terms of action verbs, the associated business parameters remain as a part of the service inputs, outputs, preconditions and effects (IOPE). As the solution proposed by Oaks et al . does not go beyond classical IOPE-based capability descriptions (i.e. IT capabilities), we consider that it has the same problem of semantic web service solutions.

In this paper, and more specifically in Section 3 , we define a conceptual model for describing the actions of services and processes in a structured format. We use the term Business Capability to refer to this functional perspective [ 8 ]. The model should define business capabilities as standalone entities independent from their implementations and feature business terms . Business Capabilities should be machine processable : can be indexed , searched and compared between each other. Business Capabilities and related concepts should be defined by domain experts (and optionally by modelling experts) and presented in domain-related ontologies (that we call capability domain ontologies) and serialized in a standard format to facilitate their portability.

In terms of realization, in Section 4 , we have been particularly interested in investigating the use of semantic web technologies for implementing the model as a set of vocabularies using the Resource Description Framework (i.e. aka RDF). These vocabularies/ontologies can be used to create semantic annotations of services or processes, an approach that is widely used in semantic web service management [ 9 ]. Its main advantage is that we create semantic annotations without constraints from the service or process modelling language; instead, we only need hooks in services or process descriptions where semantic annotations can be attached. This choice is further motivated by the vision of better enabling computers and people to work in cooperation [ 10 ]. Within this vision and in the context of business process modelling, people represent business experts that are expressing their needs and requirements in terms of Business Capabilities and describing applications and processes from a functional perspective .

We provide a tool support, discussed in Section 4.6 , that allows stakeholders to annotate a particular process model using predefined business capabilities from a capability domain ontology . This requires the extension of the chosen business process modelling language serialization to integrate business capability descriptions. We call the resulting models Business Capability Annotated Business Process Models .

Ontological Evaluation : The ontological evaluation of conceptual models consists of mapping the proposed conceptual model constructs to ontological concepts/constructs in order to assess the ability to model capabilities without semantic ambiguity by avoiding construct overload and redundancy [ 11 , 12 ].

Interviews with Domain Experts : We chose to carry out semi-structured interviews [ 13 , 14 ] with five domain experts that have strong background and are currently active in the area of service computing and information system design and development. The interviews were done after explanation of the objective of this work and details about service modelling approaches. The main targeted outcome of these interviews was to identify if these experts can confirm that the proposed model is good enough to model business capabilities and if it can be adopted in their working environment.

Before concluding the paper and defining future perspectives in Section 8 , we discuss the related work in Section 7 with respect to a set of requirements that are defined in Section 2 .

The concept of capability has been defined by Dutta et al . [ 15 ] and Amit and Schoemaker [ 16 ], from organizational and data perspectives, as the ability of organizations to efficiently use their resources (i.e. human capital, knowledge, available data, etc.) to generate value and achieve their objectives. BPM [ 17 ], defines capabilities, from a control-flow perspective, as the way (i.e. HOW) organizations achieve their goals by capturing explicitly process tasks and their temporal and logical order. From a functional perspective, OASIS Reference Model [ 18 ] considers capabilities as the effect of a service in terms of data generated or change of the world and Oaks et al . [ 8 ] define capabilities as what a service does in terms of action performed that creates a value for the customers.

Considering the functional perspective, the definition given by OASIS Reference Model [ 18 ] is tight to the actual implementation of a service and thus defines IT capabilities while Oaks et al . [ 8 ] try to give a more business/functional capability definition. The capability conceptual model proposed by Oaks et al . [ 8 ] uses IT capabilities of services for deriving the semantics of the action performed. Furthermore, OASIS Reference Model [ 18 ] considers the concept of a service as a core element that enables a requester to access and achieve a particular business capability . Within this vision, we notice that the concept of service has evolved from the notion of remote invocation interface (such as WSDL [ 19 ]) to a more comprehensive entity. Within this vision, the invocation interface is only one aspect of the whole service description. Another core aspect of a service, which is the focus of this paper, is the notion of business capability which describes what a service achieves.

The notion of business capability is a fundamental concept not only for Service-Oriented Architecture (SOA) but also for enterprise information systems. The ARIS architecture [ 20 ] recognizes the importance of the functional perspective in enterprise information systems and considers it as one of its views. The concept of business capability is the glue point between services and business processes. A service gives access to a certain capability which can be achieved by a business process. Despite its importance, this concept has not drawn the research community attention as it deserves. Current approaches for capability modelling were part of efforts for describing related concepts such as business processes, service descriptions and search requests.

Requirement 1.1 —Explicitly represent the action performed.

Requirement 1.2 —Explicitly capturing functional and non-functional features related to the action performed.

Requirement 1.3 —Ability to express these features using simple (e.g. integer, boolean, string) as well as complex types (e.g. conditional values, enumerations).

Requirement 2.1 —Ability to explicitly identify relationships between capabilities based on their descriptions.

Requirement 2.2 —Ability to index and search capabilities.

Requirement 3.1 —Use of domain or general ontological concepts for describing capabilities.

Requirement 3.2 —Searching capabilities should not be relying on keyword extraction and comparison.

We use these requirements in the rest of the paper for driving our design decisions in Sections 3 and 4 as well as conducting a related work analysis in Section 7 .

We propose in this section our contribution as a business capability meta-model. This meta-model defines the high-level concepts required for defining domain-specific business capabilities.

3.1. Business Capabilities as Property-featured Entities

We propose to model a business capability as an action category enriched by (zero or many) functional or non-functional properties (see the concept of property entry below). As examples, we refer to Table 1 1 that lists five capabilities with the same action category: i.e. ‘ Shipping ’. Capability A has two functional properties: i.e. From and To with International Address as possible values. Simply, Capability A describes the shipping action within two international locations. The rest of the capabilities, in the same table, have either additional properties or different property values.

Examples of Business Capabilities.

A property entry ( P , v ) is specified w.r.t. a property declaration defined in a shared ontology. As example , we refer to columns 3 and 4 of Table 1 . Column 3 shows the list of properties P and column 4 shows their respective values v .

A property declaration, d = ( P , V , R ) ⁠ , defines (i) a property P as a relevant functional or non-functional feature of the capabilities of a given domain , (ii) V the most general value ( super class ) that property entries defined according to d can have and (iii) a set of relations R that tell when a value v 1 is more specific than a value v 2 w.r.t. the semantics/meaning of the property P ( see Example 1 ).

Let v 1 and v 2 be two values and R a set of specification relations . v 1 variantOF v 2 if ∃ r ∈ R such that v 1 r v 2 ( see Example 1 ).

Property Entry and Property Declaration .

Capability A, listed in Table 1 , includes as part of its description the property From that indicates where (location) the shipment is taken from. This property is defined w.r.t. the property declaration listed in Table 2 . d From = (From, GeographicalLocation, LocatedIn) where From is the actual property, GeographicalLocation is the most general value of this property and LocatedIn is the specification relation that exists between possible values of this property.

Let From EU and From IE be two property entries. From EU = ( From , Europe ) and From IE = ( From , Ireland ) defined w.r.t. d From (see Table 2 ). Note that the specification relation LocatedIn holds between the values Ireland and Europe .

Business Capability

Category: A predefined concept in a domain-related ontology that comes from a shared agreement on its action semantics. A category is a specific property that is present in all capability descriptions via the property achieves .

Properties: A set of property entries ( Property , Value ) as explained in Definition 1 .

Examples of Property Declarations.

Capability is the class that captures the capability (see Definition 2 ). This class is composed of at least 1 Action Category and, optionally, multiple Property Entries .

Action Category is the class that represents the category of the capability (see Definition 2 ).

Property Entry is the class that represents a property entry that has a name and a Value (see Definition 1 ). A property Entry is defined with respect to a Property Declaration (the connection between both classes the same property name).

Property Declaration is the class that represents the property declaration (see Definition 1 ). It has a property name, the most general value and a set of specification relations (see Definition 1 ).

EnumerationValue extends the class Value to represent enumerations of other values (see relation hasElement in Fig. 2 ).

RangeValue extends the class Value to represent ranges of other values presented as minimum and maximum (see relations hasMin and hasMax in Fig. 2 ).

DynamicValue extends the class Value to represent a dynamic value that is evaluated with respect to an Expression (see relation hasEvaluator in Fig. 2 ).

ConstrainedValue extends the class Value , it has a value only if a certain Constraint is valid (see relation constrainedBy in Fig. 2 ).

ConditionalValue extends the class Value , it has a value only if a certain Constraint is valid (see relation hasCondition in Fig. 2 ). Additionally, its value is computed dynamically with respect to an Expression (see relation hasEvaluator in Fig. 2 ).

Constraint is the class that represents a constraint that is defined via an Expression (see relation hasExpression in Fig. 2 ).

Expression is the class that represents an expression, it has a type and a value (both of type String).

Capability UML class diagram.

UML class diagram for the possible values.

The idea of modelling business capabilities as a set of features was highly influenced by the frame-based modelling paradigm. Indeed, the conclusions of Wickler [ 27 , 28 ] after an extensive analysis of multiple modelling mechanisms and languages suggest that frame-based descriptions of capabilities in the context of software agents were the most expressive and flexible means. Additionally, using the model suggested in this paper, one can describe business capabilities independently from their actual implementations by highlighting the action being performed with a set of related properties. Contrary to the Input, Output, Precondition and Effect paradigm, it features the functional (business) and non-functional characteristics which end-users are mostly interested in and which are specified in their requests. This constitutes a natural way on how users describe their needs, for example, users need a service that ships packages from an address to another . This is expressed via Capability A in Table 1 with an action category ‘shipping’ and the properties ‘from’ and ‘to’.

3.2. Specification and Extension Relations between Capabilities

Another benefit of using frame-based modelling of capabilities is the possibility to infer potential relationships between them by analysing their features (or properties). We have been particularly interested in this work in relations of specifications and extensions that may exist between capabilities. These relations are captured in Fig. 1 as ‘ specifies ’ and ‘ extends ’ between capabilities and are described, respectively, in Definitions 3 and 4 .

For abbreviation purposes and by misnomer we say that a certain capability cap has a property pr .

We refer to the property pr of cap by cap.pr .

We refer to the set of properties of cap by cap.properties .

We say that two capabilities C 1 and C 2 (or more) share the same property pr if both of them have the property pr (but possibly with different values).

Given two capabilities C 1 and C 2 ⁠ , C 1 specifies C 2 if (i) all the properties of C 2 are also properties of C 1 ( in other terms C 1 inherits all the properties defined in C 2 ⁠ ), (ii) for every shared property pr , the value of C 1 . pr is either equal to or variantOf the value of C 2 . pr ⁠ , and (iii) there exists at least one shared property pr ′ such that the value of C 1 . pr ′ variantOf C 2 . pr ′ ( see variantOF in Definition 1 ).

Given two capabilities C 1 and C 2 ⁠ , C 1 extends C 2 if (i) C 1 has all the properties of C 2 and has additional properties , and (ii) for every shared property pr , the value of C 1 . pr is equal to the value of C 2 . pr ⁠ .

Fine-grained relations can be defined based in these relations. Let C 1 and C 2 be two capabilities such that C 2 specifies C 1 ⁠ , and let pr be a shared property, we say that C 2 specifies C 1 on pr ⁠ , denoted C 2 specifies_pr C 1 iff the value of C 2 ⁠ .pr is variantOf the value of C 1 ⁠ .pr.

Hierarchy of Capabilities

Figures 3 and 4 show two examples hierarchies of capability descriptions. 2 Capability A is the root of these hierarchies, it represents an abstract capability description for shipping goods from any source and destination at an international scale. This capability can be extended either to Capability B or Capability C . Both extend the initial capability by one or two attributes; fine-grained relations can be seen in Fig. 4 . As an example of specification relation between capabilities, we refer to the link between Capability D and Capability B in Fig. 3 . Capability D specifies Capability B as it becomes a European shipping capability instead of International. This fine-grained semantics of the specification relation is further shown in Fig. 4 . It is also clear that Capability E extends Capability D .

Example of Shipping Capabilities Hierarchy using coarse-grained relations.

Example of Shipping Capabilities Hierarchy using fine-grained relations.

Note that the hierarchies depicted in Figs 3 and 4 are simple and can be easily created manually. However, when it comes to large set of capabilities, more dedicated algorithms for creating optimal hierarchies are needed [ 30 ]. We have explored the potential of using this model to describe and create an indexing structure of sensor capabilities using Formal Concept Analysis [ 31 ]. The results show that using this approach we were able to index and discover capabilities of a large repository in few milliseconds that proves to be more time efficient than existing approaches.

The proposed conceptual model allows to model high-level capabilities in a particular domain that can be tailored to specific use cases. Similar to domain ontologies which define shared concepts and shared attributes/properties, high-level capabilities in a given domain can also be defined as an ontology where an agreement about their meaning is reached and shared. Like any other ontology concepts, these capabilities can be reused to define other ones. We implemented this model as a set of ontologies that are detailed in the following section.

We have, recently, noticed a wide adoption of the Linked Data [ 32 , 33 ] principles, and a growing amount of data sets specified in RDF. It is clear that Linked Data provide the best practices for publishing structured data on the Web. Linked Data are published using RDF where URIs are the means for referring various entities on the Web giving the possibility to interlink them. Currently, organizations are highly interested in publishing their data in RDF [ 34 ] as well as various public vocabularies (ontologies) are being released. Consequently, we have chosen to implement the proposed capability meta-model in RDF and make use of Linked Data principles in order to define capabilities, categories and properties as well as their values.

Meta-Model : is the lowest level that defines the required classes and properties for defining action categories (see Section 4.1 ) and property declarations (see Section 4.2 ).

Categories and Properties : this level defines the set of categories (see Section 4.1 ) and properties (see Section 4.3 ) related to particular domain.

Domain Ontology : is the actual capability domain ontology. It creates abstract capabilities that associate for each action category the possible set of properties (see Section 4.3 ).

Capabilities : at this level, capabilities are created with respect to the capability domain ontology.

From meta-model to actual capabilities.

4.1. Action Categories

The action category meta-model proposes the set of classes and properties for defining the actions being performed in a particular domain. Figure 1 did not give any details about the ActionCategory class as it can be defined based on the implementation choices.

After analysing existing actions categories such NAICS [ 35 ], UNSPSC [ 36 ] and MIT Process Handbook [ 37 ], we propose to model action categories and relations between them (i.e. Meronymy and generalization relations). Meronymy (part-of) relations between action categories are used in NAICS [ 35 ] and MIT Process Handbook [ 37 ] and also investigated in [ 38 ] in order to capture granularity relations between actions at several levels of abstraction. The generalization relation is also used in NAICS [ 35 ] to represent that an action is more specific or general than another one (e.g. ‘book accommodation’ is more general than ‘book hotel’).

Figure 6 illustrates the proposed meta-model for action categories. We use in this ontology the prefix ac for the namespace http://vocab.deri.ie/ac . 3 This ontology has only one rdfs class (rdfs:Class) and five rdf properties (rdf:Property). ac:ActionCategory is the class of action categories. The properties ac:hasPart and ac:hasOptionalPart are used to create a meronymy hierarchy of action categories. An action is performed only if all its parts are performed. We use the property ac:hasLevel to assign the level (xsd:Integer) of an action category within a meronymy hierarchy of action categories. The top of the hierarchy can start from 0. The properties ac:isMoreGeneral and ac:isMoreSpecific (inverse relations) are also used to create a specification hierarchy of action categories.

Action category meta-model.

Listing 1. Action categories ontology snippet from the distribute via Electronic Store Domain.

Example of action categories from the Distribute via Electronic Store Domain [ 39 ].

4.2. Capability Meta-Model

Listing 2 shows the concept cmm:Capability as an rdfs:Class and cmm:PropertyValue as an equivalent class to owl:Thing because it needs to be the most general class to allow for the reuse of existing vocabularies for possible attribute values for example using vcard open vocabulary for defining addresses. Then, the property cmm:achieves allows linking a cmm:Capability to its corresponding ac:ActionCategory . Furthermore, the property cmm:property allows to create domain-specific properties that will be created as an rdfs:subProperty of cmm:property and will be interpreted as properties of a capability. Finally, the property cmm:hasMostGeneralValue is used to define during the property declaration its most general value.

Listing 2. Capability meta-model snippet.

Listing 3. Shipping domain ontology snippet.

4.3. Property Declarations and Capability Domain Ontology

One can define a domain-specific capability ontology by modelling its action category and properties. We discuss in this section the various property types that our model supports. We will use the Distribute via Electronic Store domain (its set of action categories has already been discussed in the previous section) for defining the property declarations that are related to the action categories shown in Fig. 7 .

Listing 3 shows the N3 [ 40 ] description of the capability desco:deliverViaCourrier (see Line 5). Line 6 links this capability to its action verb from the Action Categories of the domain which is deso:deliverViaCourrier . The rest of the listing illustrates how two properties desco:from and desco:to are defined. Both properties are rdfs:subProperty of cmm:property (Lines 10 and 13).

The range of the properties desco:from and desco:to is vcard:VCard to refer to an address. More complex and detailed property types are required for modelling more advanced properties. As depicted in Fig. 2 , we consider five classes used for describing the values of a capability properties.

Listing 4. Example of a constraint.

4.3.1. Constraint and Expression

A constraint enables to specify the possible values an attribute can have. The class Constraint represents all constraints. The class Expression enables to specify expressions among them the value of a given constraint. The class Expression has two attributes/properties, ExprType which specifies the type of expression and ExprValue which defines the expression itself. The type of the expression, ExprType , indicates how to build the corresponding queries during a matching process. Currently, the only type of expression our meta-model supports is SPARQL (queries).

Listing 4 shows an example for expressing a constraint on the weight of the package. The constraint PackgConstraint is defined in Line 1. This constraint has an expression of type SPARQL. The value of the constraint expression (Line 5) indicates that the weight of the package has to be lower than or equal to 50 kg.

4.3.2. Constrained Value

Listing 5. Example of a constrained value.

4.3.3. Dynamic Value

A DynamicValue defines how to compute the value of a property which value depends on (i) consumer provided properties, (ii) dynamic values or (iii) hidden variables. As shown in Fig. 2 , a DynamicValue refers to an expression that defines how to compute it.

Listing 6. Example of a dynamic value.

4.3.4. Conditional Value

A ConditionalValue assigns a value to the corresponding property if a certain condition holds. That is, the value assignment itself is conditional. As shown in Fig. 2 , a ConditionalValue has a condition expressed as a constraint and an element which corresponds to the corresponding property value.

Listing 7 gives an example showing how to specify a shipping price when the target country is a European country. The value Y , of the property price , is a ConditionalValue (Line 3). It assigns the Property Value, EuropeanPrice , when the PriceCondition holds (Line 5). PriceCondition is a Constraint which requires that the target country is in Europe (Lines 9–12). EuropeanPrice is a DynamicValue (Line 14) and has as evaluation expression PriceExpression which was detailed in Listing 6 .

4.4. Updates from the Previous Version of the Model

Listing 7. Example of a conditional value.

Mapping between the previous and the current version of the capability RDF concepts.

4.5. Requirements’ Satisfaction of the Business Capability Model

Expressiveness—Explicitly represent the action performed : the actions performed by a business capability are captured via the rdfs property cmm : achieves ⁠ . The action categories are defined in an ontology of actions with composition and specification relations between them. This model can be further enriched by exploring other relations such as synonymy .

Expressiveness—Explicitly capturing functional and non-functional features related to the action performed : contrary to the IOPE paradigm, our model expresses a business capability with a set of properties that can be both functional and non-functional. The related properties of a particular high-level business capability are captured also in a domain-specific ontology.

Expressiveness—Ability to express these features using simple as well as complex types : a property value of a business capability can be assigned any simple value such as string, integer or an address vcard (see Listing lst:SDOnto). Furthermore, the proposed business capability meta-model proposes a set of advanced types such as conditionalValue and enumerationValue (see Fig. 2 ).

Inferences—Ability to explicitly identify relationships between business capabilities based on their descriptions : the proposed model identifies two relations to capture specification (see Definition 3 ) and extension (see Definition 4 ) relations between business capabilities.

Inferences—Ability to index and search capabilities : Example 2 Hierarchy of Capabilities shows how an indexing structure of business capability can be constructed based on their proprieties. However, this paper did not elaborate of how specification and extension relations can be extracted and used for building such structure. Future works will use this feature to build an indexing structure of business capabilities based on their properties.

Use of Ontologies—Use of domain or general ontological concepts for describing business capabilities : actual business capabilities are derived from high-level ones that are defined in domain-specific ontologies. In the examples shown in this paper, we illustrated the use of general and domain-specific ontological concepts.

Use of Ontologies—Searching capabilities should not be relying on keyword extraction and comparison : capability are described using ontological concepts, this allows the development of mechanisms of discovery using those concepts without relying on extraction of keywords from textual descriptions. Future works will focus on the indexing and discovery of business capability using this modelling approach.

4.6. Annotating Process Models with Business Capabilities

In this section, we provide a proof of concept to show how we can use the capability model to annotate tasks of a process model.

It is important to note that our vision for describing business capabilities is to abstract from any service or process modelling language. In other words, a capability of a process task can be described in RDF outside the scope of the process model; while a link between the task and its capability needs to exist. Existing annotation mechanisms such as in Business Process modelling Notation 6 (BPMN for short) can be used to create this link but not for describing the capability. Using BPMN annotations as capability attributes loses the connection between the capability as an entity to its action categories and related properties. For other languages that do not provide annotation mechanisms such as EPC, additional changes in their specifications might be required.

As it is difficult for new users to write RDF annotations for describing the capability of their services or business processes, we have implemented an extension of EPCTools 7 [ 45 ], a business process modelling tool using EPC, in order to assist users in the annotation operation. Figure 8 shows screenshots of the extended version of EPCTools. When a user wants to annotate a particular task of a model, he needs to right click it and choose Capability from the contextual menu (see 1 in Fig. 8 ). After loading the required ontologies, the user has to select the action category for the current task (see 2 in Fig. 8 ). Finally, the user has to choose what properties associated to the action category he wants to define in his capability (see 3 in Fig. 8 ).

Extended version of EPCTools that supports annotation of business process tasks.

The extended version of EPCTools offers two options to save the model either in its existing EMPL serialization with additional tags for the capability or exporting the entire model as RDF. Note that the primary purpose of this tool support is to provide a proof of concept for testing the applicability of the proposed model. A proper evaluation of the model itself is carried out in Section 6 .

While process models explicitly capture the involved activities and workflows together with organization-specific resources, the proposed capability model focuses at providing an abstract representation of what these processes achieve or the outcome that customers or collaborators need. Within the same organisation, there may be several workflows for specific outcomes (e.g. by rearranging activities and resources), but on a broader scale the organisation would not expose the different workflows, but would only show the business capabilities if offers. The model proposed can serve this need, however, at least one further steps is required: identification of the business capability of an entire process given that all of its activities are annotated with their business capabilities.

As illustrated in Fig. 9 , determining the capability of an entire business process consists of determining its ActionCatery and associated Properties . Values of these concepts depend on the control flow of the process model as well as the capabilities of all its activities (i.e. cap1, cap2, cap3 and cap4 in Fig. 9 ).

The capability of a business process is the aggregation of the capabilities of its activities.

5.1. Determining the Action Category

The action category is a mandatory property in the business capability description. Its value is taken from an Actions Ontology that is also used for determining the action category of aggregated business capabilities. An aggregated business capability has as action category corresponding to the Lowest Common Ancestor (LCA) of the action verbs of its components.

Using the ontology of Action Categories depicted in Fig. 7 , consists of looking for the LCA of all the action verbs of the activities of that process model: LCA(Obtain Order in electronic store, Receive payment through check, Receive Payment through Credit-card charge, Deliver Product of service purchased in Internet) = Sell via electronic Store .

Ideally, all the action categories used in the model are taken from the same actions ontology like in this simple example. For various reasons, modellers can use actions taken from different action ontologies. Instead of searching for the LCA in a single actions ontology, one needs to take into account all the possible ontologies used in assigning action categories to the capabilities of a process model. In such a case, a more elaborated method is needed [ 38 ].

5.2. Determining the Properties

Properties of a capability of a business process model can be determined by propagating them from a start node to an end node. Each node introduces new properties with respect to various conditions (e.g. control flow such conditional branching). In order to propose a correct properties propagation algorithm, we assume that the input process model does not have any loops and is well structure. In a well-structured process model, every split connector has a corresponding join connector, whereas both connectors bound a process model fragment with one entry node and one exit node [ 46 ]. We propose to use the formal semantics of the business capability annotated business process graph as a token game, similar to Petri Nets [ 47 ].

A Petri Net is a tuple ( P , T , F ), where P is a finite set of places (representing events in EPC), T is a finite set of transitions ( ⁠ P ∩ T = ∅ ⁠ ) (representing functions in EPC) and F ⊆ ( P × T ) ∪ ( T × P ) is a set of arcs (flow relations). Petri nets can be used to represent dynamics of business process models by using token propagation to verify if models are regular, sound and well structured [ 48 ].

A token is a theoretical concept that is used as an aid to define the behaviour of a process by firing its nodes. The Initial place generates a token that traverses the sequence transitions and passes through all the places until reaching the Final place [ 49 ]. In this case, a process model is mapped to a petri net using transformation rules depending on the type of its nodes. In EPC, function and event nodes are transformed into transitions and places, respectively, while mapping connectors is more complex. This depends on the type of connector and its linked nodes [ 48 ].

The idea of propagating the properties of a process model is similar; it starts from the InitialNode then fires all the nodes one by one and propagates the subsequent properties until it reaches the FinalNode . Each node introduces some changes on the set of propagated properties. The propagated properties at a particular node are marked on its outgoing arcs.

The propagation of properties and conditions is then guided by the traversal of tokens in the petri nets representing the business process model. However, classical petri nets allow only the modelling of states, events, synchronizations, etc. and are not able to model data objects such as the properties of capabilities. To solve this issue, coloured or typed petri nets [ 50 ] have been introduced as an extension to classical petri nets where tokens represent objects (e.g. data item) in the system. Tokens represent ‘colours’ or set of properties. At each transition, a token is produced with respect to the consumed tokens. More concretely, a transition represents a relation between input and output tokens. Our proposed propagation algorithm [ 51 ] defines the relations of these transitions. The idea of this propagation has been used in the literature for propagating IOPEs of process models to determine their IT capabilities [ 52 ] as well as for the verification the soundness of business process models [ 53 ].

5.3. EPCTools Extension Implementing the Capability Aggregation Algorithm

The proposed business capabilities aggregation algorithm has also been implemented as an extended version of EPCTools 8 [ 45 ]. This extension shown in Fig. 10 computes the business capability of a business process fragment defined by a start and end event (see Area 1 in Fig. 10 ). The result is shown to the user as a set of action categories (see Area 2 in Fig. 10 ) and a set of properties (see Area 3 in Fig. 10 ).

EPCTools extension implementing the capability aggregation algorithm.

Note that the objective of this tool is to provide a proof of concept for determining the capability of an entire business process model. It has been developed to show the applicability of this approach, to carry out some manual verification of the results and to be used as a visual support for conducting interviews with domain experts. Apart from this running example, we manually tested this algorithm on a set of process models from the customs clearance processes: import procedures. The test collection includes 10 business processes that have been previously subject to a case study [ 54 ] for capability modelling in logistics. They describe guidance on the basic regulatory requirements that all importers must consider for importing goods. These processes involve various steps from submission of import documents until the release of the imported goods. The models were manually annotated using the Import Capabilities Domain Ontology (IMPC 9 ). In Section 6.2 , we report on the interviews carried out with domain experts.

We propose to validate the business capability model proposed in this paper using ontological evaluation as a non-empirical evaluation method (see Section 6.1 ) and semi-structured interviews with domain experts as an empirical method (see Section 6.2 ).

6.1. Ontological Evaluation of the Business Capability Model

6.1.1. introduction.

The ontological evaluation of conceptual models consists of mapping the proposed conceptual model constructs to ontological concepts/constructs in order to assess the ability of the model to represent reality [ 12 ]. However, mapping the modelling language constructs to ontological concepts can be subjective especially when we want to identify intrinsic and non-intrinsic attributes or classes and kinds, consequently this can lead to a subjective evaluation. To avoid this issue, Wand et al . [ 11 ] propose to use a set of generic conceptual modelling constructs (i.e. instance, class and attribute) instead of the ontological constructs defined by Bunge [ 55 ]. In this approach, the evaluation of the model is carried out through the verification of a set of rules insuring that a model does not generate any semantic ambiguity by avoiding construct overload and redundancy. These rules are not related to a particular conceptual model and can be applicable to any model that is using generic ontological concepts. Therefore, we evaluated the proposed business capability conceptual model using this methodology.

6.1.2. Evaluation Steps

‘ Things are represented only as instances. Instances should represent only things .’ [ 11 ]

Mapping the business capability conceptual model constructs to generic conceptual modelling constructs and ontological constructs.

‘ Both simple and composite things should be represented using the same construct ( entity , object ).’ [ 11 ]

‘ A class or a kind of thing is defined in terms of a given set of attributes and relationships ; that is , intrinsic attributes and mutual attributes .’ [ 11 ]

‘ An aggregate type/class must have properties in addition to those of its component types/classes .’ [ 11 ]

‘ All attributes and relationships in a class represent properties of things in the class .’ [ 11 ]

‘ Null attributes have no meaning .’ [ 11 ]

‘ The same construct should be used to represent a binary relationship and a higher-order relationship .’ [ 11 ]

This rule is already covered by the mapping proposed by Wand et al . Indeed, both binary and higher-order relationships are mapped to Attributes. Furthermore, the business capability meta-model proposed in this paper does not have any higher-order relationships.

6.1.3. Discussion and Threads to Validity

The above-mentioned rules (i.e. Rules 1 – 7 ), as articulated by Wand et al . [ 11 ], verify that a general conceptual model can be used for modelling reality by avoiding construct overload and redundancy; which is the case with the business capability meta-model proposed in this paper.

Researchers such as Bunge [ 55 ], Wand et al . [ 11 ] and Weber [ 56 ] evaluate conceptual models from a realistic point of view. In other words, they assume that conceptual models should be designed to represent things that ‘exist in the world’. The proposed business capability meta-model is, effectively, representing real things, i.e. actual actions performed by services, processes or human agents. The main observation is that business capabilities are not tangible objects and might need more flexibility to give the designer the possibility to model these actions as he perceives them. Weber [ 56 ] is in favour of such flexibility and argues that ontological foundations for information systems design might be subject to the perception of the designer. This is also aligned with paradigmatic approaches where conceptual models can capture different aspects of things depending on the intended perception and use of the conceptual models.

The idea of validating conceptual models using ontological analysis can be challenging and difficult to apply with complex models, especially when using the ontological analysis of Bunge [ 55 ]. This can be simplified by using the method proposed by Wand et al . [ 11 ] to avoid situations where the designer needs to differentiate between a ‘kind’ and a ‘class’. The evaluation of the proposed business capability meta-model using this method was relatively simple as the model defines 14 constructs. This made the verification of the rules of Wand et al . [ 11 ] straightforward.

Even though in this work, we showed that the proposed business capability meta-model is ‘suitable to represent reality’, few threats of validity, as presented in Table 5 , need to be considered for further assessments of the generated business capabilities to ensure that (1) they are consistent, (2) have an intuitive appeal to the end users, (3) they can be used to represent various domains and (4) can be used in empirical evaluations.

Threads to validity.

6.2. Interviews with Domain Experts

6.2.1. introduction.

In this part of the evaluation, we carry out two rounds of semi-structured interviews [ 13 , 14 ] with 10 domain experts that have strong background and are currently active in the area of service computing and information system design and development.

The objective of the two rounds a slightly different. The first one aims to assess the intuitive appeal of the capability modelling approach while the second examines the capability aggregation work. The reasons for these two interviews come from the fact that both contributions were not evaluated at the same time. First we conducted the assessment of the model, once validated we proceeded with the capability aggregation work and carried out the second round of interviews.

For each round of interviews, five different experts were invited. The interviews were done after explanation of the objective of this work and details about service modelling approaches. The main targeted outcome of these interviews was to identify if these experts can confirm that the proposed model is good enough to model business capabilities and if it can be adopted in their working environment.

6.2.2. Participants

two project managers (P1 and P2): leading teams of developers of information systems for the management of seaports in different countries;

two service providers and consumers (P3 and P4): working as consultants in the area of telecommunication. One of them is also a manager of his own start-up offering automated post services;

and one IT engineer (P5): working in the same start-up as the main developer of the provided service.

two system architects (P6 and P7): working as designers of information systems for clients of a multinational company;

one project manager (P8): leading teams of developers of information systems for the management of seaports in different countries;

one IT engineer (P9): another developer from the start-up offering automated post services;

and one information system consultant (P10): working as a consultant and trainer in the area of business process management.

6.2.3. Approach

The approach used for both rounds of interviews follows the case study research process proposed in [ 58 ]:

Case study design : the objective of the first round of interviews is to assess the intuitive appeal of the proposed model and the objective for the second is to assess the usefulness and intuitive appeal of the proposed aggregation algorithm for identifying the business capabilities of a process model. Interviews run individually using online conferencing and desktop sharing tools (to allow the experts to use the tool themselves remotely). Each interview took about 1 h for each participant.

Preparation for data collection : The discussions were semi-structured to give the participants the freedom to give additional comments and get as much feedback as possible from them.

5 min discussion about the profile of the participant and his knowledge about services and business processes modelling languages.

15 min presentation of the business capability meta-model introduced in this work with open discussion on each component and its use.

15 min for creating simple business capability ontology in RDF

10 min demo and interaction with the tool support

15 min discussion about the proposed approach and modelling language

15 min presentation of the business capability of atomic and aggregated tasks and the propagation algorithm introduced in this chapter with open discussion.

15 min for manually defining the aggregated capability of a simple process model.

10 min demo and interaction with the tool support.

15 min discussion about the proposed business capability aggregation approach.

Analysis of collected data : A post interview analysis of the collected feedback is reported in Section 6.2.4 .

Reporting : A discussion of the resulting feedback is summarized in Section 6.2.5 and shared among the participants.

6.2.4. Results

The following outcomes were identified:

The Experts P1–P5 are familiar with all the standardized service description languages that will be discussed in Section 7 : WSMO [ 22 ], OWL-S [ 23 ], SA-WSDL [ 24 , 25 ] and SA-REST [ 26 ].

Each of these experts (P1–P5) has extensively worked with at least one of these languages.

It is highly agreed by P1, P2, P3 and P4 that all these languages focus primarily on the technical aspect without considering the business aspect.

None of these experts (P1–P5) is still using any of these languages because they are complicated to understand and get familiar with.

Developers need to read a lot about the use of ontologies, rules, reasoners, etc. An average user cannot easily adopt such technologies.

P1–P5 prefer to have their own custom made modelling of their assets.

These experts (P1–P5) are developing REStful APIs that exchange data using JSON format and for them using JSON for their services description was a natural choice.

The use of JSON gives them the flexibility they need to identify their own properties and values.

These experts confirmed that modelling of business capabilities the way we propose in this paper is close to their vision and simple to implement.

‘ Frame-based modelling is same as key value pairs. This is exactly how we model objects in JSON. ’ (P5).

The Experts P6–P10 find that the business capabilities modelling is a promising direction towards end-users understanding. Actions are what users do in their processes and properties use business terms that these experts are familiar with. Two of the experts highlight that the main advantages that the model brings is the simplicity and extensibility.

‘ It looks like your model can also capture other aspects! ’ (P6)

‘ You are proposing a simpler view of what the model achieves. ’ (P10).

Designing sample capabilities by P2 and P5 was easy and intuitive after a short tutorial.

None of the experts is in favour of the idea of exclusively modelling business capability properties.

They are interested in including more implementation/technical properties.

The Experts P6–P10 find that the adoption of this work into their information systems is possible as long as long as it can be adapted to their modelling and annotation techniques.

Regarding the aggregation work, the Participants P6–P9 find it as a useful feature for users that are developing multiple service-based business processes. It allows not only identifying the business capability of the model but also any other aspect of interest and visualize the parameters used or required by the process.

‘ I can add here another property regarding the data format used in one activity to make sure that it is communicated to the following activities as a requirement. ’ (P9).

The consultant and training expert (P10) finds that the results of aggregation can be further used for documentation purposes. This can help delivering business processes and services documentation quickly.

P6, P8 and P9 see that abstraction and aggregation techniques are already in use in their working environment. However, they do not use rich descriptions of models and services and thus do not have rich abstracted service or process descriptions.

Ontologies and taxonomies are already in use and constitute valuable assets for the companies where these experts work. All the experts use ontologies.

The experts (P2, P3 and P4) were not necessarily in favour of using RDF as an underlying implementation language of such model. After discussing JSON-LD, they were convinced that it is a better alternative.

‘ I think RDF is not the best implementation language. ’ (P2).

The tool support was very useful to show how the model can be used to annotate business process models.

While testing the aggregation tool support, the Experts P6–P10 find that it is simple to use and intuitive. It is important to note that in the implemented prototype we used only primitive types.

Experts (P6–P10) do not see using simple types as a major issue as they find that properties are more important to visualize than their values.

‘ At this stage I don ’ t care about the values used, I give more importance to the parameters themselves! ’ (P7).

6.2.5. Summary of the Interviews’ Outcomes

All the expert agree that current modelling languages do not give much importance to business capabilities. The proposed model in this work comes as an addition rather than a substitution to current models for describing a different view of enterprise information systems.

Frame-based modelling is a good modelling paradigm towards ease of use and intuitiveness of the models.

The tool support was very helpful to hide the complexity of RDF as an underlying realization language.

Some of the experts suggested to include technical aspects in the current model to serve as bridge between both business and IT perspectives. This recommendation is aligned with our vision in this work. The business capability is one of the aspects of a service description that can be further extended.

A rich capability can then easily be transformed into a complete documentation using Natural Language Generation techniques [ 59 , 60 ].

6.2.6. Discussion and Threads to Validity

Managers have a global view over the entire lifecycle of business processes.

Consultants have multiple interactions with end-users as they, regularly, give trainings and information sessions to end-users.

Engineers have a strong technical background in the development of services and business process management tools.

A capability denotes what an action does either in terms of world effects or returned information [ 18 ]. The purpose of providing well-defined capabilities of services or business processes is to allow end-users to discover them with respect to the action they perform. In this section, we are particularly interested in service description languages and how they describe capabilities of services. We classify these contributions in three families: Semantic Web Services models, Semantic Annotation of Invocation Interfaces models and Frame-based models. These three families are discussed in details in the following three sections.

7.1. Semantic Web Services models

The first family of contributions for capability descriptions includes Semantic Web Services models (WSMO [ 22 , 62 ] and OWL-S [ 23 , 63 ]). Capability descriptions with this family are split into information transformation and state of the world change captured as Input, Output, Preconditions and Effects (IOPE paradigm) [ 64 ]. A recent contribution that comes to resolve issues of rigidity service description using WSMO [ 22 ] and OWL-S [ 23 ] is Simple Semantic Web Architecture and Protocol (SSWAP) [ 65 ]. It provides yet another paradigm for service descriptions that uses description logics. It has the particularity to add further service meta-data such as provider details and taxonomic descriptions of data items [ 66 ].

Critique : Both OWL-S and WSMO were designed at a time when extensive service descriptions were thought to be effective to build a web service architecture. The major problem with these languages is that they have been extensively enriched making the description of the entire service in some cases complex. Furthermore, describing what a service would do upon the change of state of the world after its execution proved to be a much harder problem than developers of WSMO and OWL-S anticipated. This created a strong dependency on service descriptions that SSWAP proposed a solution to resolve it.

In these solutions, information transformation and state of the world changes define the capability of a service expressed in terms of axioms, consequently the explicit action performed is not captured. However, in OWL-S Profiles, a classification in a service taxonomy such as NAICS [ 35 ] or UNSPSC [ 36 ] can be used to help identify the actual action being performed and in SSWAP a textual description of the service can be used as such.

7.2. Semantic Annotation of Invocation Interfaces Models

The second family of related efforts concerns semantic annotations of invocation interfaces (SA-WSDL [ 24 , 25 ] and SA-REST [ 26 , 67 ]). While these approaches do not directly target capability modelling, they attempt to provide alternative solutions to top-down semantic approaches (WSMO [ 22 , 62 ] and OWL-S [ 23 , 63 ]) by starting from existing descriptions such as WSDL [ 19 ] and annotate them with semantic information.

Critique : These contributions focused mainly on annotating the service interfaces rather than functional capabilities . This is mainly perceived in the fact that there were no clear decisions regarding the attributes to be used in their specifications. The researchers that worked on these contributions could have taken the decision to use RDFS/OWL model that defines terms like ‘category’, ‘precondition’, ‘effect’, etc. that would allow service descriptions to be typed in a standard way.

7.3. Frame-based models

The third family includes frame-based approaches for modelling capabilities. This is another way to describe capabilities featuring functional declarations that are different from the classical IOPEs. Functional declarations are investigated in details by researchers from the linguistics and Natural Language Processing (NLP) domain with the aim to give another view on the structure of sentences by describing verbs using ‘cases’ contained in case frames [ 68 ]. Example of cases include agent (who), location (where) and instrument (how) as declared by Fillmore .

The idea of modelling capabilities using frames has been used to describe the capabilities of software agents [ 28 ] and proves to be effective for enhancing agents' communication and planning while facilitating human understanding of agents capabilities. Celino et al . [ 69 ] use the same approach for describing data and services published on the web. In the same vision, Oaks et al . used frame-based modelling for describing service capabilities. Oaks et al . proposed a comprehensive conceptual model that extends IOPEs paradigm with additional frames extracted from textual descriptions. Frames used by Oaks et al . are similar to those defined by Fillmore . It makes the model easy for humans to read and understand but machines won’t be able to use this model to compose capabilities. Composition is still relying on the classical IOPEs.

7.4. Summary and discussion

This section reviewed related approaches that proposed service description models that can be used as alternatives/extensions to either simple labels and textual descriptions or to existing languages such as WSDL [ 19 ]. A summary of these approaches is in Table 6 .

Comparative analysis of capability modelling approaches.

All the proposed approaches are reliable for carrying out machine processing operations such as composition and discovery. These solutions were proposed to avoid relying on simple labels or long textual descriptions in these operations. However, most of the proposed approaches do not go beyond the classical IOPEs. This makes search requests exclusively defining the state of the world before and after the execution of a service, something that has been proven to be difficult [ 70 , 71 ] and requires additional abstraction efforts to make end-users able to query services in a more user friendly manner [ 70 , 71 ].

Explicit actions even using simple lexical terms form a good basis for a capability description. This is a natural way human users define what a service or application does. Capturing these actions in a domain-specific ontology helps improve their reuse and creating a common understanding on their semantics.

Capability descriptions models should be open to allow for more flexibility to end-users to include their own ontological concepts and their own way to describe their assets. A good example is the quick and high adoption of JSON as a simple format for exchanging and modelling structured data without strict restrictions on what attributes to use nor any particular order that they should follow, etc.

Enriching the action performed with explicit functional and non-functional properties does not only refine further the action being carried out but also can be used to infer relations between capabilities. These relations can create an indexing structure that is not exclusively built on a categorization schema of lexical terms.

Process aware information systems’ stakeholders range from the IT department engineers that are responsible for the development and monitoring of IT activities within and organization to the domain experts that are responsible for its growth, innovation and response to market demands. A primary requirement for developing an information system that serves the needs of all these stakeholders, is to integrate in its processing in addition to the control-flow perspective (i.e. what activities are involved in a process and how they are ordered, etc.) the other relevant perspectives: i.e. data flow perspective: how data is flowing in between the different process activities, organizational perspective: what are roles are required for each activity, and the functional perspective: what capabilities are achieved by each process element (i.e. activity, process fragment or entire process).

In this work, we have been particularly interested in the integration of the functional perspective into service descriptions and business process models. In our state-of-the-art analysis, we found that even though a proper capability description is recognized to be important for automated discovery, composition, indexing, etc. of services and business process models, little effort has been put towards describing this concept as standalone entity. It has always been part of other concepts such as services and invocation interfaces or simply reduced a simple label or textual description.

In our work, we consider a capability as standalone entity that can exist outside the scope of service descriptions or invocation interfaces. A service, a computer programme, a business process or even a manual task can be described using this concept where an explicit link can be created between them. In a very simple definition, we consider a capability as a set of actions enriched with zero or many properties. Properties allow to refine further the action that is taken for a domain-related ontology. For example, shipping services can be described using the action category ‘shipping’ that can be extended with properties reporting on the ‘source address’, ‘destination address’, etc. One can argue that such properties are also present in current service description. This is true but these are rather part of the input and output parameters of the services rather than its capability that is described via the state change of the world before and after the execution of a service (i.e. precondition and effect).

The modelling of capabilities as a set of actions and properties is inspired by the frame-based modelling approaches that have been proven to be effective in practice with languages such as JSON. It is simple, relies mainly on a shared agreements on the semantics of the used actions and properties that are defined common ontologies. The other advantage of using frame-based modelling is the possibility of indexing, searching and aggregating capabilities without heavily relying on reasoning which is the major issue with current approaches. Detailed analysis of current modelling approaches was carried out in Section 7 and the details of the capability meta-model are discussed in Section 3 . Details about the implementation of the conceptual model (i.e. capability meta-model) are discussed in Section 4 and its evaluation is reported in Section 6 .

As a future research direction, it is possible to investigate the use of NLP techniques for providing suggestions of business capabilities. This can be used either to fully automate the annotations of services and processes with their capabilities or propose autocompletions during their manual annotations. For example, a business capability can be linked to the so called ‘ case frames ’ in linguistics as it is offered by FrameNet project [ 73 ]. In linguistic study, the capability of an action is defined by an action verb that is quite similar to the action category in our proposed model. Then several dimensions may extend that verb by giving more details about the carried work and related aspects. While in FrameNet these dimensions are predefined such as agentive, dative, and objective in our case, we do not impose any predefined dimensions. However, it is possible to establish links between both models to generate structured business capabilities from textual descriptions using linguistic case frames. Such idea has been discussed in the literature [ 74 – 76 ] for automatically annotating process activities with their action verbs derived from the textual documentation; or exploring the idea of mapping case frame dimensions to capability properties to generate a full structured capability using the model proposed in this paper [ 77 ].

Furthermore, the business capability as implemented in this work is well structured. It explicitly lists for its properties various types of values: conditional, range, enumeration, etc. Each of these types has a clear definition on its semantics. In this regard, Natural Language Generation (NLG) techniques can be used to provide a textual description of each of these values. This can be extended to the entire capability description and generate a textual description that serves as a documentation of services and processes. This can also explore another dimension of human understanding by providing customized summary of the capability using natural language.

This publication received the financial support of Science Foundation Ireland (SFI) under Grant Number SFI/12/RC/2289.

Mendling , J. , Reijers , H.A. and Recker , J. ( 2010 ) Activity labeling in process modeling: empirical insights and recommendations . Inf. Syst. , 35 , 467 – 482 .

Google Scholar

Mendling , J. , Recker , J. and Reijers , H.A. ( 2010 ) On the usage of labels and icons in business process modeling . IJISMD , 1 , 40 – 58 .

Hepp , M. and Wechselberger , A. ( 2008 ) Ontonavierp: Ontology-Supported Navigation in ERP Software Documentation. In Sheth , A.P. , Staab , S. , Dean , M. , Paolucci , M. , Maynard , D. , Finin , T.W. and Thirunarayan , K. (eds.) The Semantic Web—ISWC 2008, 7th Int. Semant. Web Conf., ISWC 2008 , Karlsruhe, Germany, October 26–30, 2008. Proceedings, Lecture Notes in Computer Science , 5318 , pp. 764 – 776 . Springer .

Google Preview

Roman , D. , de Bruijn , J. , Mocan , A. , Lausen , H. , Domingue , J. , Bussler , C. and Fensel , D. ( 2006 ) WWW: wsmo, wsml, and WSMX in a Nutshell. In Mizoguchi , R. , Shi , Z. and Giunchiglia , F. (eds.) The Semantic Web—ASWC 2006, First Asian Semant. Web Conf. , Beijing, China, September 3–7, 2006, Proceedings, Lecture Notes in Computer Science , 4185 , pp. 516 – 522 . Springer .

Martin , D. , Paolucci , M. and Wagner , M. ( 2007 ) Bringing Semantic Annotations to Web Services: OWL-S from the SAWSDL Perspective. In The Semantic Web, 6th Int. Semant. Web Conf., 2nd Asian Semantic Web Conference, ISWC 2007 + ASWC 2007 , Busan, Korea, 11-15 November, Lecture Notes in Computer Science, 4825 , pp. 340–352. Springer, Berlin, Heidelberg.

Kopecký , J. , Vitvar , T. , Bournez , C. and Farrell , J. ( 2007 ) SAWSDL: semantic annotations for WSDL and XML schema . IEEE Internet Comput. , 11 , 60 – 67 .

Lathem , J. , Gomadam , K. and Sheth , A.P. ( 2007 ) SA-REST and (s)mashups: Adding Semantics to Restful Services. In Proc. First IEEE Int. Conf. Semantic Computing (ICSC 2007) , September 17–19, 2007, Irvine, California, USA, pp. 469–476. IEEE Computer Society.

Oaks , P. , ter Hofstede , A.H.M. and Edmond , D. ( 2003 ) Capabilities: Describing What Services Can Do. In Orlowska , M.E. , Weerawarana , S. , Papazoglou , M.P. and Yang , J. (eds.) ICSOC , Lecture Notes in Computer Science , 2910 , pp. 1 – 16 . Springer .

Roman , D. , Kopecký , J. , Vitvar , T. , Domingue , J. and Fensel , D. ( 2015 ) WSMO-Lite and hRESTS: lightweight semantic annotations for Web services and RESTful APIs . Web Semant. , 31 , 39 – 58 .

Berners-Lee , T. , Hendler , J. and Lassila , O. ( 2001 ) The semantic web . Sci. Am. , 284 , 34 – 43 .

Wand , Y. , Storey , V.C. and Weber , R. ( 1999 ) An ontological analysis of the relationship construct in conceptual model . ACM Trans. Database Syst. , 24 , 494 – 528 .

Yair , W. and Ron , W. ( 1989 ) An Ontological Evaluation of System Analysis and Design Methods. In Falkenberg , E. and Lindgreen , P. (eds.) Information Systems Concepts: An In-depth Analysis . Elsevier Science Publishers , Amsterdam, The Netherlands .

Bodart , F. , Patel , A. , Sim , M. and Weber , R. ( 2001 ) Should optional properties be used in conceptual modelling? A theory and three empirical tests . Inf. Syst. Res. , 12 , 384 – 405 .

Drever , E. , Scottish Council for Research in Education ( 1995 ) Using Semi-structured Interviews in Small-Scale Research: A Teacher’s Guide . SCRE Publication. Scottish Council for Research in Education .

Dutta , S. , Narasimhan , O. and Rajiv , S. ( 2005 ) Conceptualizing and measuring capabilities: methodology and empirical application . Strategic Management Journal , 26 , 277 – 285 .

Amit , R. and Schoemaker , P.J.H. ( 1993 ) Strategic assets and organizational rent . Strateg. Manage. J. , 14 , 33 – 46 .

Weske , M. ( 2007 ) Business Process Management: Concepts, Languages, Architectures . Springer .

OASIS ( 2006 ). OASIS reference model for service oriented architecture 1.0. http://www.oasis-open.org/committees/download.php/19679/soa-rm-cs.pdf . Accessed: 25/05/2014.

WSDL ( 2001 ). WSDL: Web Services Description Language. http://www.w3.org/TR/wsdl . Accessed: 25/05/2014.

Scheer , A.-W. and Schneider , K. ( 2006 ) ARIS—Architecture of Integrated Information Systems. In Bernus , P. , Mertins , K. and Schmidt , G. (eds.) Handbook on Architectures of Information Systems . Springer , Berlin Heidelberg .

Sycara , K.P. , Widoff , S. , Klusch , M. and Lu , J. ( 2002 ) Larks: dynamic matchmaking among heterogeneous software agents in cyberspace . Auton. Agent. Multi. Agent. Syst. , 5 , 173 – 203 .

WSMO ( 2005 ). WSMO: Web service modelling ontology. http://www.wsmo.org/ . Accessed: 25/05/2014.

OWL-S ( 2004 ). OWL-S: Semantic markup for web services. http://www.w3.org/Submission/OWL-S/ . Accessed: 25/05/2014.

SA-WSDL ( 2007 ). SA-WSDL: Semantic Annotations for WSDL. http://www.w3.org/2002/ws/sawsdl/ . Accessed: 25/05/2014.

Verma , K. and Sheth , A.P. ( 2007 ) Semantically annotating a web service . IEEE Internet Comput. , 11 , 83 – 85 .

SA-REST ( 2010 ). SA-REST: Semantic annotation of web resources. http://www.w3.org/Submission/SA-REST/ . Accessed: 25/05/2014.

Wickler , G.J. ( 1999 ) Using Expressive and Flexible Action Representations to Reason about Capabilities for Intelligent Agent Cooperation. PhD thesis University of Edinburgh, Edinburgh, UK.

Wickler , G. and Tate , A. ( 1999 ) Capability representations for brokering: A survey. Available from : www.aiai.ed.ac.uk/project/oplan/cdl/cdl-ker.ps .

Gao , F. and Derguech , W. ( 2012 ) Ubiquitous Service Capability Modeling and Similarity Based Searching. In Haller , A. , Huang , G. , Huang , Z. , Paik , H. and Sheng , Q.Z. (eds.) Web Information Systems Engineering—WISE 2011 and 2012 Workshops—Combined WISE 2011 and WISE 2012 Workshops, Revised Selected Papers , Sydney, Australia, 28–30 November, Lecture Notes in Computer Science , 7652 , pp. 173 – 184 . Springer .

Derguech , W. and Bhiri , S. ( 2013 ) Modelling, Interlinking and Discovering Capabilities. In ACS Int. Confe. Computer Systems and Applications, AICCSA 2013 , Ifrane, Morocco, May 27–30, pp. 1–8.

Derguech , W. , Bhiri , S. , Hasan , S. and Curry , E. ( 2015 ) Using formal concept analysis for organizing and discovering sensor capabilities . Comput. J. , 58 , 356 – 367 .

Bizer , C. , Heath , T. and Berners-Lee , T. ( 2009 ) Linked Data - The Story So Far. IJSWIS , 5.

Sheridan , J. and Tennison , J. ( 2010 ) Linking UK Government Data. LDOW 2010 .

Lebo , T. and Williams , G.T. ( 2010 ) Converting governmental datasets into linked data. I-SEMANTICS . ACM.

NAICS ( 1997 ) North American Industry Classification System (NAICS). http://www.census.gov/eos/www/naics/ (accessed May 25, 2014).

UNSPSC ( 1998 ) United Nations Standard Products and Services Code (UNSPSC). http://www.census.gov/eos/www/naics/ (accessed May 25, 2014).

MIT ( 2001 ) MIT process handbook. http://process.mit.edu/ (accessed May 25, 2014).

Smirnov , S. , Dijkman , R.M. , Mendling , J. and Weske , M. ( 2010 ) Meronymy-Based Aggregation of Activities in Business Process Models. In Parsons , J. , Saeki , M. , Shoval , P. , Woo , C.C. and Wand , Y. (eds.) Conceptual Modeling—ER 2010, 29th Int. Conf. Conceptual Modeling , Vancouver, BC, Canada, November 1–4, 2010. Proceedings, Lecture Notes in Computer Science , 6412 , pp. 1 – 14 . Springer .

SAP ( 2001 ) Distribute via electronic store.

Berners-Lee , T. and Connolly , D. ( 2008 ) Notation3 (n3): A readable rdf syntax. W3c team submission. W3C.

Bhiri , S. , Derguech , W. and Zaremba , M. ( 2012 ) Modelling Capabilities as Attribute-Featured Entities. In Cordeiro , J. and Krempels , K. (eds.) Web Information Systems and Technologies—8th Int. Conf., WEBIST 2012 , Porto, Portugal, April 18–21, 2012, Revised Selected Papers, Lecture Notes in Business Information Processing , 140 , pp. 70 – 85 . Springer .

Baccar , S. , Derguech , W. , Curry , E. and Abid , M. ( 2015 ) Modeling and Querying Sensor Services Using Ontologies. In Abramowicz , W. (ed.) Business Information Systems—18th Int. Conf., BIS 2015 , Poznań, Poland, June 24–26, 2015, Proceedings, Lecture Notes in Business Information Processing , 208 , pp. 90 – 101 . Springer .

Derguech , W. , Bhiri , S. and Curry , E. ( 2017 ) Designing business capability-aware configurable process models . Inf. Syst. , 72 , 77 – 94 .

Oaks , P. ( 2005 ) Enabling Ad-hoc Interaction with Electronic Services. PhD thesis Faculty of Information Technology, Queensland University of Technology Brisbane, Australia.

Nicolas , C. and Ekkart , K. ( 2006 ) EPC Tools.

Kiepuszewski , B. , ter Hofstede , A.H.M. and Bussler , C. ( 2000 ) On Structured Workflow Modelling. In Wangler , B. and Bergman , L. (eds.) Advanced Information Systems Engineering, 12th Int. Conf. CAiSE 2000 , Stockholm, Sweden, June 5–9, 2000, Proceedings, Lecture Notes in Computer Science , 1789 , pp. 431 – 445 . Springer .

Peterson , J.L. ( 1981 ) Petri Net Theory and the Modeling of Systems. Prentice Hall PTR , Upper Saddle River, NJ, USA .

van der Aalst , W.M.P. ( 1999 ) F ormalization and verification of event-driven process chains . Inf. Softw. Technol. , 41 , 639 – 650 .

Istoan , P. ( 2012 ) Defining Composition Operators for BPMN. In Gschwind , T. , Paoli , F.D. , Gruhn , V. and Book , M. (eds.) Software Composition—11th Int. Conf., SC 2012 , Prague, Czech Republic, May 31–June 1, 2012. Proceedings, Lecture Notes in Computer Science , 7306 , pp. 17 – 34 . Springer .

van der Aalst , W. ( 1994 ) Putting high-level petri nets to work in industry . Comput. Ind. , 25 , 45 – 54 .

Derguech , W. and Bhiri , S. ( 2011 ) Merging Business Process Variants. In Abramowicz , W. (ed.) Business Information Systems—4th Int. Conf., BIS 2011 , Poznan, Poland, June 15–17, 2011. Proceedings, Lecture Notes in Business Information Processing , 87 , pp. 86 – 97 . Springer .

Vulcu , G. , Bhiri , S. , Derguech , W. and Ibáñez , M.J. ( 2011 ) Semantically-enabled Business Process Models Discovery . Int. J. Bus. Process Integration Manage. , 5 , 257 – 272 .

Weber , I. , Hoffmann , J. and Mendling , J. ( 2010 ) Beyond soundness: on the verification of semantic business process models . Distributed Parallel Databases , 27 , 271 – 343 .

Derguech , W. and Bhiri , S. ( 2012 ) Capability Modelling—Case of Logistics Capabilities. In Rosa , M.L. and Soffer , P. (eds.) Business Process Management Workshops—BPM 2012 International Workshops , Tallinn, Estonia, September 3, 2012. Revised Papers, Lecture Notes in Business Information Processing , 132 , pp. 519 – 529 . Springer .

Bunge , M. ( 1977 ) Treatise on Basic Philosophy. Ontology I: The Furniture of the World . Riedel , Boston .

Weber , R. et al.  ( 1997 ) Ontological Foundations of Information Systems . Coopers & Lybrand and the Accounting Association of Australia, New Zealand, Melbourne .

Dalkey , N. and Helmer , O. ( 1963 ) An experimental application of the Delphi method to the use of experts . Manage. Sci. , 9 , 458 – 467 .

Runeson , P. and Höst , M. ( 2009 ) Guidelines for conducting and reporting case study research in software engineering . Empir. Softw. Eng. , 14 , 131 – 164 .

Leopold , H. , Mendling , J. and Polyvyanyy , A. ( 2012 ) Generating Natural Language Texts from Business Process Models. In Ralyté , J. , Franch , X. , Brinkkemper , S. and Wrycza , S. (eds.) Advanced Information Systems Engineering—24th Int. Conf., CAiSE 2012 , Gdansk, Poland, June 25–29, 2012. Proceedings, Lecture Notes in Computer Science , 7328 , pp. 64 – 79 . Springer .

Leopold , H. , Mendling , J. , Reijers , H.A. and Rosa , M.L. ( 2014 ) Simplifying process model abstraction: techniques for generating model names . Inf. Syst. , 39 , 134 – 151 .

Siau , K. and Rossi , M. ( 2011 ) Evaluation techniques for systems analysis and design modelling methods—a review and comparative analysis . Inf. Syst. J. , 21 , 249 – 268 .

Roman , D. , Kopecký , J. , Vitvar , T. , Domingue , J. and Fensel , D. ( 2015 ) Wsmo-lite and hrests: lightweight semantic annotations for web services and restful apis . J. Web Sem. , 31 , 39 – 58 .

Sheng , B. , Zhang , C. , Yin , X. , Lu , Q. , Cheng , Y. , Xiao , T. and Liu , H. ( 2016 ) Common intelligent semantic matching engines of cloud manufacturing service based on owl-s . Int. J. Adv. Manuf. Technol. , 84 , 103 – 118 .

Roman , D. , Keller , U. , Lausen , H. , de Bruijn , J. , Lara , R. , Stollberg , M. , Polleres , A. , Feier , C. , Bussler , C. and Fensel , D. ( 2005 ) Web service modeling ontology . Appl. Ontol. , 1 , 77 – 106 .

Gessler , D. , Schiltz , G.S. , May , G.D. , Avraham , S. , Town , C.D. , Grant , D.M. and Nelson , R.T. ( 2009 ) SSWAP: a simple semantic web architecture and protocol for semantic web services . BMC Bioinf. , 10 , 309 .

Nelson , R.T. , Avraham , S. , Shoemaker , R.C. , May , G.D. , Ware , D. and Gessler , D. ( 2010 ) Applications and methods utilizing the simple semantic web architecture and protocol (SSWAP) for bioinformatics resource discovery and disparate data and service integration . BioData Min. , 3 , 3 .

Luo , C. , Zheng , Z. , Wu , X. , Yang , F. and Zhao , Y. ( 2016 ) Automated structural semantic annotation for restful services . IJWGS , 12 , 26 – 41 .

Fillmore , C.J. ( 1968 ) The Case for Case. In Bach , E. and Harms , R.T. (eds.) Universals in Linguistic Theory , pp. 0 – 88 . Holt, Rinehart and Winston , New York .

Celino , D.R. , Reis , L.V. , Martins , B.F. and Souza , V.E.S. ( 2016 ) A Framework-based Approach for the Integration of Web-based Information Systems on the Semantic Web. In Proc. 22Nd Brazilian Symp. Multimedia and the Web , New York, NY, USA. Webmedia ‘16, pp. 231–238. ACM.

Zaremba , M. , Vitvar , T. , Bhiri , S. , Derguech , W. and Gao , F. ( 2012 ) Service Offer Descriptions and Expressive Search Requests—Key Enablers of Late Service Binding. In Huemer , C. and Lops , P. (eds.) E-Commerce and Web Technologies—13th Int. Conf., EC-Web 2012, Vienna, Austria, September 4–5, 2012. Proceedings, Lecture Notes in Business Information Processing , 123 , pp. 50 – 62 . Springer .

Chouiref , Z. , Belkhir , A. , Benouaret , K. and Hadjali , A. ( 2016 ) A fuzzy framework for efficient user-centric web service selection . Appl. Soft Comput. , 41 , 51 – 65 .

Kamaruddin , L.A. , Shen , J. and Beydoun , G. ( 2012 ) Evaluating Usage of WSMO and OWL-S in Semantic Web Services. In Ghose , A. and Ferrarotti , F. (eds.) Eighth Asia-Pacic Conf. Conceptual Modelling, APCCM 2012, Melbourne, Australia, January 2012, CRPIT , 130 , pp. 53 – 58 . Australian Computer Society .

Baker , C.F. , Fillmore , C.J. and Lowe , J.B. ( 1998 ) The Berkeley FrameNet project. In COLING-ACL ‘98: Proceedings of the Conference , pp. 86–90. Montreal, Canada.

Leopold , H. , Smirnov , S. and Mendling , J. ( 2012 ) On the refactoring of activity labels in business process models . Inf. Syst. , 37 , 443 – 459 .

Rahm , E. and Bernstein , P.A. ( 2001 ) A survey of approaches to automatic schema matching . VLDB J. , 10 , 334 – 350 .

Mendling , J. and Simon , C. ( 2006 ) Business Process Design by View Integration. In Business Process Management Workshops, BPM 2006 Int. Workshops, BPD, BPI, ENEI, GPWW, DPM, semantics4ws , Vienna, Austria, September 4–7, 2006, Proceedings, Lecture Notes in Computer Science , 4103 , pp. 55 – 64 . Springer .

Gao , F. and Bhiri , S. ( 2014 ) Capability Annotation of Actions Based on their Textual Descriptions. In Reddy , S. (ed.) 2014 IEEE 23rd Int. WETICE Conf., WETICE 2014, Parma, Italy, 23–25 June, 2014 , pp. 257 – 262 . IEEE Computer Society .

Note that the notation used in these examples is not formal, formal descriptions of the used concepts is shown in Section 4 .

Note that the notation for this example is not formal, formal descriptions of the used concepts is shown in Section 4 .

Note that we also use the prefix xsd for the namespace http://www.w3.org/2001/XMLSchema#

Online version of cmm available at: http://vocab.deri.ie/cmm (accessed June 6, 2015).

Note the namespaces used: ac: http://vocab.deri.ie/ac cmm: http://vocab.deri.ie/cmm cap: http://vocab.deri.ie/cap

http://www.bpmn.org/ (accessed October 11, 2017).

The original version of EPCTools: http://www2.cs.uni-paderborn.de/cs/kindler/Forschung/EPCTools/ (accessed November 30, 2015) and the new version is available at https://goo.gl/iUcQNA

The original version of EPCTools: http://www2.cs.uni-paderborn.de/cs/kindler/Forschung/EPCTools/ (accessed November 11, 2015) and the new version is available at https://goo.gl/iUcQNA .

http://vocab.deri.ie/impc

Note that the durations used here are approximative. Some of the interviews run for few minutes more or less for each section.

Author notes

Handling editor: Rada Chirkova

Email alerts

Citing articles via.

• Recommend to your Library

Affiliations

• Online ISSN 1460-2067
• Print ISSN 0010-4620
• Copyright © 2023 British Computer Society
• About Oxford Academic
• Publish journals with us
• University press partners
• What we publish
• New features  
• Open access
• Institutional account management
• Rights and permissions
• Get help with access
• Accessibility
• Advertising
• Media enquiries
• Oxford University Press
• Oxford Languages
• University of Oxford

Oxford University Press is a department of the University of Oxford. It furthers the University's objective of excellence in research, scholarship, and education by publishing worldwide

• Copyright © 2023 Oxford University Press
• Cookie settings
• Cookie policy
• Privacy policy
• Legal notice

This Feature Is Available To Subscribers Only

Sign In or Create an Account

This PDF is available to Subscribers Only

For full access to this pdf, sign in to an existing account, or purchase an annual subscription.

Ontology Development 101: A Guide to Creating Your First Ontology

Natalya F. Noy   and Deborah L. McGuinness

Stanford University, Stanford, CA, 94305

[email protected]    and     [email protected]

1          Why develop an ontology?

In recent years the development of ontologies—explicit formal specifications of the terms in the domain and relations among them (Gruber 1993) —has been moving from the realm of Artificial-Intelligence laboratories to the desktops of domain experts. Ontologies have become common on the World-Wide Web. The ontologies on the Web range from large taxonomies categorizing Web sites (such as on Yahoo!) to categorizations of products for sale and their features (such as on Amazon.com). The WWW Consortium (W3C) is developing the Resource Description Framework (Brickley and Guha 1999) , a language for encoding knowledge on Web pages to make it understandable to electronic agents searching for information.   The Defense Advanced Research Projects Agency (DARPA), in conjunction with the W3C, is developing DARPA Agent Markup Language (DAML) by extending RDF with more expressive constructs aimed at facilitating agent interaction on the Web (Hendler and McGuinness 2000) . Many disciplines now develop standardized ontologies that domain experts can use to share and annotate information in their fields. Medicine, for example, has produced large, standardized, structured vocabularies such as snomed (Price and Spackman 2000) and the semantic network of the Unified Medical Language System (Humphreys and Lindberg 1993) . Broad general-purpose ontologies are emerging as well. For example,   the United Nations Development Program and Dun & Bradstreet combined their efforts to develop the UNSPSC ontology which provides terminology for products and services ( www.unspsc.org ).

An ontology defines a common vocabulary for researchers who need to share information in a domain. It includes machine-interpretable definitions of basic concepts in the domain and relations among them.

Why would someone want to develop an ontology? Some of the reasons are:

�          To share common understanding of the structure of information among people or software agents

�          To enable reuse of domain knowledge

�          To make domain assumptions explicit

�          To separate domain knowledge from the operational knowledge

�          To analyze domain knowledge

Sharing common understanding of the structure of information among people or software agents   is one of the more common goals in developing ontologies (Musen 1992; Gruber 1993) . For example, suppose several different Web sites contain medical information or provide medical e-commerce services. If these Web sites share and publish the same underlying ontology of the terms they all use, then computer agents can extract and aggregate information from these different sites. The agents can use this aggregated information to answer user queries or as input data to other applications.

Enabling reuse of domain knowledge was one of the driving forces behind recent surge in ontology research. For example, models for many different domains need to represent the notion of time. This representation includes the notions of time intervals, points in time, relative measures of time, and so on. If one group of researchers develops such an ontology in detail, others can simply reuse it for their domains. Additionally, if we need to build a large ontology, we can integrate several existing ontologies describing portions of the large domain. We can also reuse a general ontology, such as the UNSPSC ontology, and extend it to describe our domain of interest.

Making explicit domain assumptions underlying an implementation makes it possible to change these assumptions easily if our knowledge about the domain changes. Hard-coding assumptions about the world in programming-language code makes these assumptions not only hard to find and understand but also hard to change, in particular for someone without programming expertise. In addition, explicit specifications of domain knowledge are useful for new users who must learn what terms in the domain mean.  

Separating the domain knowledge from the operational knowledge is another common use of ontologies. We can describe a task of configuring a product from its components according to a required specification and implement a program that does this configuration independent of the products and components themselves (McGuinness and Wright 1998) . We can then develop an ontology of PC-components and characteristics and apply the algorithm to configure made-to-order PCs. We can also use the same algorithm to configure elevators if we “feed” an elevator component ontology to it (Rothenfluh et al. 1996) .

Analyzing domain knowledge is possible once a declarative specification of the terms is available.   Formal analysis of terms is extremely valuable when both attempting to reuse existing ontologies and extending them (McGuinness et al. 2000) .

Often an ontology of the domain is not a goal in itself. Developing an ontology is akin to defining a set of data and their structure for other programs to use. Problem-solving methods, domain-independent applications, and software agents use ontologies and knowledge bases built from ontologies as data. For example, in this paper we develop an ontology of wine and food and appropriate combinations of wine with meals. This ontology can then be used as a basis for some applications in a suite of restaurant-managing tools: One application could create wine suggestions for the menu of the day or answer queries of waiters and customers. Another application could analyze an inventory list of a wine cellar and suggest which wine categories to expand and which particular wines to purchase for upcoming menus or cookbooks.

About this guide

We build on our experience using Prot�g�-2000 (Protege 2000) , Ontolingua (Ontolingua 1997) , Chimaera (Chimaera 2000) as ontology-editing environments. In this guide, we use Prot�g�-2000 for our examples.

The wine and food example that we use throughout this guide, is loosely based on an example knowledge base presented in the paper describing CLASSIC—a knowledge-representation system based on a description-logics approach (Brachman et al. 1991) . The CLASSIC tutorial (McGuinness et al. 1994) has developed this example further. Prot�g�-2000 and other frame-based systems describe ontologies declaratively, stating explicitly what the class hierarchy is and to which classes individuals belong.

Some ontology-design ideas in this guide originated from the literature on object-oriented design (Rumbaugh et al. 1991; Booch et al. 1997) . However, ontology development is different from designing classes and relations in object-oriented programming. Object-oriented programming centers primarily around methods on classes—a programmer makes design decisions based on the operational properties of a class, whereas an ontology designer makes these decisions based on the structural properties of a class. As a result, a class structure and relations among classes in an ontology are different from the structure for a similar domain in an object-oriented program.

It is impossible to cover all the issues that an ontology developer may need to grapple with and we are not trying to address all of them in this guide. Instead, we try to provide a starting point; an initial guide that would help a new ontology designer to develop ontologies. At the end, we suggest places to look for explanations of more complicated structures and design mechanisms if the domain requires them.

Finally, there is no single correct ontology-design methodology and we did not attempt to define one. The ideas that we present here are the ones that we found useful in our own ontology-development experience. At the end of this guide we suggest a list of references for alternative methodologies.

2          What is in an ontology?

The Artificial-Intelligence literature contains many definitions of an ontology; many of these contradict one another. For the purposes of this guide an ontology is a formal explicit description of concepts in a domain of discourse ( classes (sometimes called concepts )), properties of each concept describing various features and attributes of the concept ( slots (sometimes called roles or properties )), and restrictions on slots ( facets (sometimes called role restrictions )). An ontology together with a set of individual instances of classes constitutes a knowledge base . In reality, there is a fine line where the ontology ends and the knowledge base begins.

Classes are the focus of most ontologies. Classes describe concepts in the domain. For example, a class of wines represents all wines. Specific wines are instances of this class. The Bordeaux wine in the glass in front of you while you read this document is an instance of   the class of Bordeaux wines. A class can have subclasses that represent concepts that are more specific than the superclass. For example, we can divide the class of all wines into red, white, and ros� wines. Alternatively, we can divide a class of all wines into sparkling and non-sparkling wines.  

Slots describe properties of classes and instances: Ch�teau Lafite Rothschild Pauillac wine has a full body; it is produced by the Ch�teau Lafite Rothschild winery. We have two slots describing the wine in this example: the slot body with the value full and the slot maker with the value Ch�teau Lafite Rothschild winery. At the class level, we can say that instances of the class Wine will have slots describing their flavor , body , sugar level , the maker of the wine and so on. [1]

All instances of the class Wine , and its subclass Pauillac, have a slot maker the value of which is an instance of the class Winery ( Figure 1 ). All instances of the class Winery have a slot produces that refers to all the wines (instances of the class Wine and its subclasses) that the winery produces.

In practical terms, developing an ontology includes:

�          defining classes in the ontology,

�          arranging the classes in a taxonomic (subclass–superclass) hierarchy,

�          defining slots and describing allowed values for these slots,

�          filling in the values for slots for instances.

We can then create a knowledge base by defining individual instances of these classes filling in specific slot value information and additional slot restrictions.

3          A Simple Knowledge-Engineering Methodology

As we said earlier, there is no one “correct” way or methodology for developing ontologies. Here we discuss general issues to consider and offer one possible process for developing an ontology. We describe an iterative approach to ontology development: we start with a rough first pass at the ontology. We then revise and refine the evolving ontology and fill in the details. Along the way, we discuss the modeling decisions that a designer needs to make, as well as the pros, cons, and implications of different solutions.

First, we would like to emphasize some fundamental rules in ontology design to which we will refer many times. These rules may seem rather dogmatic. They can help, however, to make design decisions in many cases.

1)       There is no one correct way to model a domain— there are always viable alternatives. The best solution almost always depends on the application that you have in mind and the extensions that you anticipate.

2)       Ontology development is necessarily an iterative process.

3)       Concepts in the ontology should be close to objects (physical or logical) and relationships in your domain of interest. These are most likely to be nouns (objects) or verbs (relationships) in sentences that describe your domain.

That is, deciding what we are going to use the ontology for, and how detailed or general the ontology is going to be will guide many of the modeling decisions down the road. Among several viable alternatives, we will need to determine which one would work better for the projected task, be more intuitive, more extensible, and more maintainable. We also need to remember that an ontology is a model of reality of the world and the concepts in the ontology must reflect this reality. After we define an initial version of the ontology, we can evaluate and debug it by using it in applications or problem-solving methods or by discussing it with experts in the field, or both. As a result, we will almost certainly need to revise the initial ontology. This process of iterative design will likely continue through the entire lifecycle of the ontology.

Step 1.          Determine the domain and scope of the ontology

We suggest starting the development of an ontology by defining its domain and scope. That is, answer several basic questions:

�          What is the domain that the ontology will cover?

�          For what   we are going to use the ontology?

�          For what types of questions the information in the ontology should provide answers?

�          Who will use and maintain the ontology?

The answers to these questions may change during the ontology-design process, but at any given time they help limit the scope of the model.

Consider the ontology of wine and food that we introduced earlier. Representation of food and wines is the domain of the ontology. We plan to use this ontology for the applications that suggest good combinations of wines and food.

Naturally, the concepts describing different types of wines, main food types, the notion of a good combination of wine and food and a bad combination will figure into our ontology. At the same time, it is unlikely that the ontology will include concepts for managing inventory in a winery or employees in a restaurant even though these concepts are somewhat related to the notions of wine and food.

If the ontology we are designing will be used to assist in natural-language processing of articles in wine magazines, it may be important to include synonyms and part-of-speech information for concepts in the ontology. If the ontology will be used to help restaurant customers decide which wine to order, we need to include retail-pricing information.   If it is used for wine buyers in stocking a wine cellar, wholesale pricing and availability may be necessary.   If the people who will maintain the ontology describe the domain in a language that is different from the language of the ontology users, we may need to provide the mapping between the languages.

Competency questions.

One of the ways to determine the scope of the ontology is to sketch a list of questions that a knowledge base based on the ontology should be able to answer, competency questions (Gruninger and Fox 1995) . These questions will serve as the litmus test later: Does the ontology contain enough information to answer these types of questions? Do the answers require a particular level of detail or representation of a particular area? These competency questions are just a sketch and do not need to be exhaustive.

In the wine and food domain, the following are the possible competency questions:

�          Which wine characteristics should I consider when choosing a wine?

�          Is Bordeaux a red or white wine?

�          Does Cabernet Sauvignon go well with seafood?

�          What is the best choice of wine for grilled meat?

�          Which characteristics of a wine affect its appropriateness for a dish?

�          Does a bouquet or body of a specific wine change with vintage year?

�          What were good vintages for Napa Zinfandel?

Judging from this list of questions, the ontology will include the information on various wine characteristics and wine types, vintage years—good and bad ones—classifications of foods that matter for choosing an appropriate wine, recommended combinations of wine and food.

Step 2.          Consider reusing existing ontologies

It is almost always worth considering what someone else has done and checking if we can refine and extend existing sources for our particular domain and task. Reusing existing ontologies may be a requirement if our system needs to interact with other applications that have already committed to particular ontologies or controlled vocabularies.   Many ontologies are already available in electronic form and can be imported into an ontology-development environment that you are using. The formalism in which an ontology is expressed often does not matter, since many knowledge-representation systems can import and export ontologies. Even if a knowledge-representation system cannot work directly with a particular formalism, the task of translating an ontology from one formalism to another is usually not a difficult one.

There are libraries of reusable ontologies on the Web and in the literature. For example, we can use the Ontolingua ontology library ( http://www.ksl.stanford.edu/software/ontolingua/ ) or the DAML ontology library ( http://www.daml.org/ontologies/ ).   There are also a number of publicly available commercial ontologies (e.g., UNSPSC (www.unspsc.org), RosettaNet (www.rosettanet.org), DMOZ (www.dmoz.org)).

For example, a knowledge base of French wines may already exist. If we can import this knowledge base and the ontology on which it is based, we will have not only the classification of French wines but also the first pass at the classification of wine characteristics used to distinguish and describe the wines. Lists of wine properties may already be available from commercial Web sites such as www.wines.com that customers consider use to buy wines.

For this guide however we will assume that no relevant ontologies already exist and start developing the ontology from scratch.

Step 3.          Enumerate important terms in the ontology

It is useful to write down a list of all terms we would like either to make statements about or to explain to a user. What are the terms we would like to talk about? What properties do those terms have? What would we like to say about those terms? For example, important wine-related terms will include wine , grape , winery , location , a wine’s color , body , flavor and sugar content ; different types of food , such as fish and red meat ; subtypes of wine such as white wine , and so on. Initially, it is important to get a comprehensive list of terms without worrying about overlap between concepts they represent, relations among the terms, or any properties that the concepts may have, or whether the concepts are classes or slots..

The next two steps—developing the class hierarchy and defining properties of concepts (slots)—are closely intertwined. It is hard to do one of them first and then do the other. Typically, we create a few definitions of the concepts in the hierarchy and then   continue by describing properties of these concepts and so on. These two steps are also the most important   steps in the ontology-design process. We will describe them here briefly and then spend the next two sections discussing the more complicated issues that need to be considered, common pitfalls, decisions to make, and so on.

Step 4.          Define the classes and the class hierarchy

There are several possible approaches in developing a class hierarchy (Uschold and Gruninger 1996) :

�          A top-down development process starts with the definition of the most general concepts in the domain and subsequent specialization of the concepts. For example, we can start with creating classes for the general concepts of Wine and Food . Then we specialize the Wine class by creating some of its subclasses: White wine , Red wine , Ros� wine . We can further categorize the Red wine class, for example, into Syrah , Red Burgundy , Cabernet Sauvignon , and so on.

�          A bottom-up development process starts with the definition of the most specific classes, the leaves of the hierarchy, with subsequent grouping of these classes into more general concepts. For example, we start by defining classes for Pauillac and Margaux wines. We then create a common superclass for these two classes— Medoc —which in turn is a subclass of Bordeaux .

�          A combination development process is a combination of the top-down and bottom-up approaches: We define the more salient concepts first and then generalize and specialize them appropriately. We might start with a few top-level concepts such as Wine , and a few specific concepts, such as Margaux . We can then relate them to a middle-level concept, such as Medoc .   Then we may want to generate all of the regional wine classes from France, thereby generating a number of middle-level concepts.

Figure 2 shows a possible breakdown among the different levels of generality.

Figure 2 . The different levels of the Wine taxonomy: Wine , Red wine , White wine , Ros� wine are more general concepts, the top level. Pauillac and Margaux are the most specific classes in the hierarchy, the bottom level.

None of these three methods is inherently better than any of the others. The approach to take depends strongly on the personal view of the domain. If a developer has a systematic top-down view of the domain, then it may be easier to use the top-down approach. The combination approach is often the easiest for many ontology developers, since the concepts “in the middle” tend to be the more descriptive concepts in the domain (Rosch 1978) .

If you tend to think of wines by distinguishing the most general classification first, then the top-down approach may work better for you. If you’d rather start by getting grounded with specific examples, the bottom-up approach may be more appropriate.

Whichever approach we choose, we usually start by defining classes. From the list created in Step 3 , we select the terms that describe objects having independent existence rather than terms that describe these objects. These terms will be classes in the ontology and will become anchors in the class hierarchy. [2] We organize the classes into a hierarchical taxonomy by asking if by being an instance of one class, the object will necessarily (i.e., by definition) be an instance of some other class.

If a class A is a superclass of class B, then every instance of B is also an instance of A

In other words, the class B represents a concept that is a “kind of” A.

For example, every Pinot Noir wine is necessarily a red wine. Therefore the Pinot   Noir class is a subclass of the Red Wine class.

Figure 2 shows a part of the class hierarchy for the Wine ontology. Section 4 contains a detailed discussion of things to look for when defining a class hierarchy.

Figure 3 . The slots for the class Wine and the facets for these slots. The “I” icon next to the maker slot indicates that the slot has an inverse ( Section 5.1 )

Step 5.          Define the properties of classes—slots

The classes alone will not provide enough information to answer the competency questions from Step 1 . Once we have defined some of the classes, we must describe the internal structure of concepts.

We have already selected classes from the list of terms we created in Step 3 . Most of the remaining terms are likely to be properties of these classes. These terms include, for example, a wine’s color, body, flavor and sugar content and location of a winery.

For each property in the list, we must determine which class it describes. These properties become slots attached to classes. Thus, the Wine class will have the following slots: color ,   body , flavor , and sugar . And the class Winery will have a location slot.

In general, there are several types of object properties that can become slots in an ontology:

�          “intrinsic” properties such as the flavor of a wine;

�          “extrinsic” properties such as a wine’s name, and area it comes from;

�          parts, if the object is structured; these can be both physical and abstract “parts” (e.g., the courses of a meal)

�          relationships to other individuals; these are the relationships between individual members of the class and other items (e.g., the maker of a wine, representing a relationship between a wine and a winery, and the grape the wine is made from.)

Thus, in addition to the properties we have identified earlier, we need to add the following slots to the Wine class: name , area , maker , grape . Figure 3 shows the slots for the class Wine .

All subclasses of a class inherit the slot of that class. For example, all the slots of the class Wine will be inherited to all subclasses of Wine, including Red Wine and White Wine . We will add an additional slot, tannin level (low, moderate, or high), to the Red Wine class. The tannin level slot will be inherited by all the classes representing red wines (such as Bordeaux and Beaujolais ).

A slot should be attached at the most general class that can have that property. For instance, body and color of a wine should be attached at the class Wine , since it is the most general class whose instances will have body and color.  

Step 6.          Define the facets of the slots

Slots can have different facets describing the value type, allowed values, the number of the values (cardinality), and other features of the values the slot can take. For example, the value of a name slot (as in “the name of a wine”) is one string. That is, name is a slot with value type String. A slot produces (as in “a winery produces these wines”) can have multiple values and the values are instances of the class Wine. That is, produces is a slot with value type Instance with Wine as allowed class.

We will now describe several common facets.

Slot cardinality

Slot cardinality defines how many values a slot can have. Some systems distinguish only between single cardinality (allowing at most one value) and multiple cardinality (allowing any number of values). A body of a wine will be a single cardinality slot (a wine can have only one body). Wines produced by a particular winery fill in a multiple-cardinality slot produces for a Winery class.

Some systems allow specification of a minimum and maximum cardinality to describe the number of slot values more precisely. Minimum cardinality of N means that a slot must have at least N values. For example, the grape slot of a Wine has a minimum cardinality of 1: each wine is made of at least one variety of grape. Maximum cardinality of M means that a slot can have at most M values. The maximum cardinality for the grape slot for single varietal wines is 1: these wines are made from only one variety of grape. Sometimes it may be useful to set the maximum cardinality to 0. This setting would indicate that the slot cannot have any values for a particular subclass.

Slot-value type

A value-type facet describes what types of values can fill in the slot. Here is a list of the more common value types:

�          String is the simplest value type which is used for slots such as name : the value is a simple string

�          Number (sometimes more specific value types of Float and Integer are used) describes slots with numeric values. For example, a price of a wine can have a value type Float

�          Boolean slots are simple yes–no flags. For example, if we choose not to represent sparkling wines as a separate class, whether or not a wine is sparkling can be represented as a value of a Boolean slot: if the value is “true” (“yes”) the wine is sparkling and if the value is “false” (“no”) the wine is not a sparkling one.

�          Enumerated slots specify a list of specific allowed values for the slot. For example, we can specify that the flavor slot can take on one of the three possible values: strong , moderate , and delicate . In Prot�g�-2000 the enumerated slots are of type Symbol .

�          Instance -type slots allow definition of relationships between individuals. Slots with value type Instance must also define a list of allowed classes from which the instances can come. For example, a slot produces for the class Winery may have instances of the class Wine as its values. [3]

Figure 4 shows a definition of the slot produces at the class Winery .

Figure 4 . The definition of a slot produces that describes the wines produced by a winery. The slot has cardinality multiple, value type Instance, and the class Wine as the allowed class for its values.

Domain and range of a slot

Allowed classes for slots of type Instance are often called a range of a slot. In the example in Figure 4 the class Wine is the range of the produces slot. Some systems allow restricting the range of a slot when the slot is attached for a particular class.

The classes to which a slot is attached or a classes which property a slot describes, are called the domain of the slot. The Winery class is the domain of the produces slot. In the systems where we attach slots to classes, the classes to which the slot is attached usually constitute the domain of that slot. There is no need to specify the domain separately.

The basic rules for determining a domain and a range of a slot are similar:

When defining a domain or a range for a slot, find the most general classes or class that can be respectively the domain or the range for the slots .

On the other hand, do not define a domain and range that is overly general: all the classes in the domain of a slot should be described by the slot and instances of all the classes in the range of a slot should be potential fillers for the slot. an overly general class for range (i.e., one would not want to make the range THING) but one would want to choose a class that will cover all fillers

Instead of listing all possible subclasses of the Wine class for the range of the produces slot, just list Wine . At the same time, we do not want to specify the range of the slot as THING—the most general class in an ontology.

In more specific terms:

If a list of classes defining a range or a   domain of a slot includes a class and its subclass, remove the subclass.

If the range of the slot contains both the Wine class and the Red Wine class, we can remove the Red Wine from the range because it does not add any new information: The Red Wine is a subclass of Wine and therefore the slot range already implicitly includes it as well as all other subclasses of the Wine class.

If a list of classes defining a range or a   domain of a slot contains all subclasses of a class A, but not the class A itself, the range should contain only the class A and not the subclasses.

Instead of defining the range of the slot to include Red Wine , White Wine , and Rose Wine (enumerating all the direct subclasses of Wine ), we can limit the range to the class Wine itself.

If a list of classes defining a range or a   domain of a slot contains all but a few subclasses of a class A, consider if the class A would make a more   appropriate range definition.

In systems where attaching a slot to a class is the same as adding the class to the domain of the slot, the same rules apply to slot attachment: On the one hand, we should try to make it as general as possible. On the other hand, we must ensure that each class to which we attach the slot can indeed have the property that the slot represents. We can attach the tannin level slot to each of the classes representing red wines (e.g., Bordeaux , Merlot , Beaujolais , etc.). However, since all red wines have the tannin-level property, we should instead attach the slot to this more general class of Red Wines . Generalizing the domain of the tannin level slot further (by attaching it to the Wine class instead) would not be correct since we do not use tannin level to describe white wines for example.

Step 7.          Create instances

The last step is creating individual instances of classes in the hierarchy. Defining an individual instance of a class requires (1) choosing a class, (2) creating an individual instance of that class, and (3) filling in the slot values. For example, we can create an individual instance Chateau-Morgon-Beaujolais to represent a specific type of Beaujolais wine. Chateau-Morgon-Beaujolais is an instance of the class Beaujolais representing all Beaujolais wines. This instance has the following slot values defined ( Figure 5 ):

�          Body:   Light

�          Color:   Red

�          Flavor:   Delicate

�          Tannin level: Low

�          Grape:   Gamay (instance of the Wine grape class)

�          Maker: Chateau-Morgon (instance of the Winery class)

�          Region:   Beaujolais (instance of the Wine-Region class)

�          Sugar:   Dry

Figure 5 . The definition of an instance of the Beaujolais class. The instance is Chateua Morgon Beaujolais from the Beaujolais region, produced from the Gamay grape by the Chateau Morgon winery. It has a light body, delicate flavor, red color, and low tannin level. It is a dry wine.

4          Defining classes and a class hierarchy

This section discussed things to look out for and errors that are easy to make when defining classes and a class hierarchy ( Step 4 from Section 3 ). As we have mentioned before, there is no single correct class hierarchy for any given domain. The hierarchy depends on the possible uses of the ontology, the level of the detail that is necessary for the application, personal preferences, and sometimes requirements for compatibility with other models. However, we discuss several guidelines to keep in mind when developing a class hierarchy. After defining a considerable number of new classes, it is helpful to stand back and check if the emerging hierarchy conforms to these guidelines.

4.1         Ensuring that the class hierarchy is correct

An “is-a” relation.

The class hierarchy represents an “is-a” relation: a class A is a subclass of B if every instance of B is also an instance of A. For example, Chardonnay is a subclass of White wine . Another way to think of the taxonomic relation is as a “kind-of” relation: Chardonnay is a kind of White wine . A jetliner is a kind of an aircraft. Meat is a kind of food.

A subclass of a class represents a concept that is a “kind of” the concept that the superclass represents.

A single wine is not a subclass of all wines

A common modeling mistake is to include both a singular and a plural version of the same concept in the hierarchy making the former a subclass of the latter. For example, it is wrong to define a class Wines and a class Wine as a subclass of Wines . Once you think of the hierarchy as representing the “kind-of” relationship, the modeling error becomes clear: a single Wine is not a kind of Wines . The best way to avoid such an error is always to use either singular or plural in naming classes (see Section 6 for the discussion on naming concepts).

Transitivity of the hierarchical relations

A subclass relationship is transitive:

If B is a subclass of A and C is a subclass of B, then C is a subclass of A

For example, we can define a class Wine , and then define a class White wine as a subclass of Wine . Then we define a class Chardonnay as a subclass of White wine . Transitivity of the subclass relationship means that the class Chardonnay is also a subclass of Wine . Sometimes we distinguish between direct subclasses and indirect subclasses. A direct subclass is the “closest” subclass of the class: there are no classes between a class and its direct subclass in a hierarchy. That is, there are no other classes in the hierarchy between a class and its direct superclass. In our example, Chardonnay is a direct subclass of White wine and is not a direct subclass of Wine .

Evolution of a class hierarchy

Maintaining a consistent class hierarchy may become challenging as domains evolve. For example, for many years, all Zinfandel wines were red. Therefore, we define a class of Zinfandel wines as a subclass of the Red wine class. Sometimes, however, wine makers began to press the grapes and to take away the color-producing aspects of the grapes immediately, thereby modifying the color of the resulting wine. Thus, we get “white zinfandel” whose color is rose. Now we need to break the Zinfandel class into two classes of zinfandel— White zinfandel and Red zinfandel —and classify them as subclasses of Rose wine and Red wine respectively.  

Classes and their names

It is important to distinguish between a class and its name:

Classes represent concepts in the domain and not the words that denote these concepts.

The name of a class may change if we choose a different terminology, but the term itself represents the objective reality in the world. For example, we may create a class Shrimps , and then rename it to Prawns —the class still represents the same concept. Appropriate wine combinations that referred to shrimp dishes should refer to prawn dishes. In more practical terms, the following rule should always be followed:

Synonyms for the same concept do not represent different classes

Synonyms are just different names for a concept or a term. Therefore, we should not have a class called Shrimp and a class called Prawn , and, possibly a class called Crevette . Rather, there is one class, named either Shrimp or Prawn . Many systems allow associating a list of synonyms,   translations, or presentation names with a class. If a system does not allow this associations, synonyms could always be listed in the class documentation.

Avoiding class cycles

We should avoid cycles in the class hierarchy. We say that there is a cycle in a hierarchy when some class A has a subclass B and at the same time B is a superclass of A. Creating such a cycle in a hierarchy amounts to declaring that the classes A and B are equivalent: all instances of A are instances of B and all instances of B are also instances of A. Indeed, since B is a subclass of A, all B’s instances must be instances of the class A. Since A is a subclass of B, all A’s instances must also be instances of the class B.

4.2         Analyzing siblings in a class hierarchy

Siblings in a class hierarchy.

Siblings in the hierarchy are classes that are direct subclasses of the same class (see Section 4.1 ).

All the siblings in the hierarchy (except for the ones at the root) must be at the same level of generality.

For example, White wine and Chardonnay should not be subclasses of the same class (say, Wine ). White wine is a more general concept than Chardonnay . Siblings should represent concepts that fall “along the same line” in the same way that   same-level sections in a book are at the same level of generality. In that sense, requirements for a class hierarchy are similar to the requirements for a book outline.

The concepts at the root of the hierarchy however (which are often represented as direct subclasses of some very general class, such as Thing ) represent major divisions of the domain and do not have to be similar concepts.

How many is too many and how few is too few?

There are no hard rules for the number of direct subclasses that a class should have. However, many well structured ontologies have between two and a dozen direct subclasses. Therefore, the following two guidelines:

If a class has only one direct subclass there may be a modeling problem or the ontology is not complete.

If there are more than a dozen subclasses for a given class then additional intermediate categories may be necessary.

The first of the two rules is similar to a typesetting rule that bulleted lists should never have only one bullet point. For example, most of the red Burgundy wines are C�tes d’Or wines. Suppose we wanted to represent only this majority type of Burgundy wines. We could create a class Red Burgundy and then a single subclass Cotes d’Or ( Figure 6 a ). However, if in our representation red Burgundy and C�tes d’Or wines are essentially equivalent (all red Burgundy wines are C�tes d’Or wines and all C�tes d’Or wines are red Burgundy wines), creating the Cotes d’Or class is not necessary and does not add any new information to the representation. If we were to include C�tes Chalonnaise wines, which are cheaper Burgundy wines from the region just South of C�tes d’Or, then we will create two subclasses of the Burgundy class: Cotes d’Or and Cotes Chalonnaise ( Figure 6 b ).

Figure 6 . Subclasses of the Red Burgundy class. Having a single subclass of a class usually points to a problem in modeling.

Suppose now that we list all types of wines as direct subclasses of the Wine class. This list would then include such more general types of wine as Beaujolais and Bordeaux, as well as more specific types such as Paulliac and Margaux ( Figure 7 a ). The class Wine has too many direct subclasses and, indeed, for the ontology to reflect the different types of wine in a more organized manner, Medoc should be a subclass of Bordeaux and Cotes d’Or should be a subclass of Burgundy . Also having such intermediate categories as Red wine and White wine would also reflect the conceptual model of the domain of wines that many people have ( Figure 7 b ).

However, if no natural classes exist to group concepts in the long list of siblings, there is no need to create artificial classes—just leave the classes the way they are. After all, the ontology is a reflection of the real world, and if no categorization exists in the real world, then the ontology should reflect that.

Figure 7 . Categorizing wines. Having all the wines and types of wine versus having several levels of categorization.

4.3         Multiple inheritance

Most knowledge-representation systems allow multiple inheritance in the class hierarchy: a class can be a subclass of several classes. Suppose we would like to create a separate class of dessert wines, the Dessert wine class. The Port wine is both a red wine and a dessert wine. [4] Therefore, we define a class Port to have two superclasses: Red wine and Dessert wine . All instances of the Port class will be instances of both the Red wine class and the Dessert wine class. The Port class will inherit its slots and their facets from both its parents. Thus, it will inherit the value SWEET for the slot Sugar from the Dessert wine class and the tannin level slot and the value for its color slot from the Red wine class.

4.4         When to introduce a new class (or not)

One of the hardest decisions to make during modeling is when to introduce a new class or when to represent a distinction through different property values. It is hard to navigate both an extremely nested hierarchy with many extraneous classes and a very flat hierarchy that has too few classes with too much information encoded in slots. Finding the appropriate balance though is not easy.

There are several rules of thumb that help decide when to introduce new classes in a hierarchy.

Subclasses of a class usually (1) have additional properties that the superclass does   not have, or (2) restrictions different from those of the superclass, or (3) participate in different relationships than the superclasses

Red wines can have different levels of tannin, whereas this property is not used to describe wines in general. The value for the sugar slot of the Dessert wine is SWEET, whereas it is not true of the superclass of the Dessert Wine class. Pinot Noir wines may go well with seafood whereas other red wines do not. In other words, we introduce a new class in the hierarchy usually only when there is something that we can say about this class that we cannot say about the superclass.

In practical terms, each subclass should either have new slots added to it, or have new slot values defined, or override some facets for the inherited slots.

However, sometimes it may be useful to create new classes even if they do not introduce any new properties.

Classes in terminological hierarchies do not have to introduce new properties

For example, some ontologies include large reference hierarchies of common terms used in the domain. For example, an ontology underlying an electronic medical-record system may include a classification of various diseases. This classification may be just that—a hierarchy of terms, without properties (or with the same set of properties). In that case, it is still useful to organize the terms in a hierarchy rather than a flat list because it will (1) allow easier exploration and navigation and (2) enable a doctor to choose easily a level of generality of the term that is appropriate for the situation.

Another reason to introduce new classes without any new properties is to model concepts among which domain experts commonly make a distinction even though we may have decided not to model the distinction itself. Since we use ontologies to facilitate communication among domain experts and between domain experts and knowledge-based systems we would like to reflect the expert’s view of the domain in the ontology.

Finally, we should not create subclasses of a class for each additional restriction.   For example, we introduced the classes Red wine , White wine , and Rose wine   because this distinction is a natural one in the wine world. We did not introduce classes   for delicate wine, moderate wine, and so on. When defining a class hierarchy, our goal is to strike a balance between creating new classes useful for class organization and creating too many classes.

4.5         A new class or a property value?

When modeling a domain, we often need to decide whether to model a specific distinction (such as white, red, or ros� wine) as a property value or as a set of classes again depends on the scope of the domain and the task at hand.  

Do we create a class White wine or do we simply create a class Wine and fill in different values for the slot color ? The answer usually lies in the scope that we defined for the ontology. How important the concept of White wine is in our domain? If wines have only marginal importance in the domain and whether or not the wine is white does not have any particular implications for its relations to other objects, then we shouldn’t introduce a separate class for white wines. For a domain model used in a factory producing wine labels, rules for wine labels of any color are the same and the distinction is not very important. Alternatively, for the representation of wine, food, and their appropriate combinations a red wine is very different from a white wine: it is paired with different foods, has different properties, and so on. Similarly, color of wine is important for the wines knowledge base that we may use to determine wine-tasting order.   Thus, we create a separate class for White wine .

If the concepts with different slot values become restrictions for different slots in other classes, then we should create a new class for the distinction. Otherwise, we represent the distinction in a slot value.

Similarly, our wine ontology has such classes as Red Merlot and White Merlot , rather than a single class for all Merlot wines: red Merlots and white Merlots are really different wines (made from the same grape) and if we are developing a detailed ontology of wine, this distinction is important.

If a distinction is important in the domain and we think of the objects with different values for the distinction as different kinds of objects,   then we should create a new class for the distinction.

Considering potential individual instances of a class may also be helpful in deciding whether or not to introduce a new class.

A class to which an individual instance belongs should not change often.

Usually when we use extrinsic rather than intrinsic properties of concepts to differentiate among classes, instances of those classes will have to migrate often from one class to another. For example, Chilled wine should not be a class in an ontology describing wine bottles in a restaurant. The property c hilled should simply be an attribute of wine in a bottle since an instance of Chilled wine can easily cease being an instance of this class and then become an instance of this class again.

Usually numbers, colors, locations are slot values and do not cause the creation of new classes. Wine, however, is a notable exception since the color of the wine is so paramount to the description of wine.

For another example, consider the human-anatomy ontology. When we represent ribs, do we create a class for each of the “1 st left rib”, “2 nd left rib”, and so on? Or do we have a class Rib with slots for the order and the lateral position (left-right)? [5] If the information about each of the ribs that we represent in the ontology is significantly different, then we should indeed create a class for each of the ribs. That is, if we want to represent details adjacency and location information (which is different for each rib) as well as specific functions that each rib playa and organs it protects, we want the classes. If we are modeling anatomy at a slightly lesser level of generality, and all ribs are very similar as far as our potential applications are concerned (we just talk about which rib is broken on the X-Ray without implications for other parts of the body), we may want to simplify our hierarchy and have just the class Rib , with two slots: lateral position , order .

4.6         An instance or a class?

Deciding whether a particular concept is a class in an ontology or an individual instance depends on what the potential applications of the ontology are. Deciding where classes end and individual instances begin starts with deciding what is the lowest level of granularity in the representation. The level of granularity is in turn determined by a potential application of the ontology. In other words, what are the most specific items that are going to be represented in the knowledge base? Going back to the competency questions we identified in Step 1 in Section 3, the most specific concepts that will constitute answers to those questions are very good candidates for individuals in the knowledge base.

Individual instances are the most specific concepts represented in a knowledge base.

For example, if we are only going to talk about pairing wine with food we will not be interested in the specific physical bottles of wine. Therefore, such terms as Sterling Vineyards Merlot are probably going to be the most specific terms we use. Therefore, Sterling Vineyards Merlot would be an instance in the knowledge base.

On the other hand, if we would like to maintain an inventory of wines in the restaurant in addition to the knowledge base of good wine-food pairings, individual bottles of each wine may become individual instances in our knowledge base.

Similarly, if we would like to record different properties for each specific vintage of the Sterling Vineyards Merlot, then the specific vintage of the wine is an instance in a knowledge base and Sterling Vineyards Merlot is a class containing instances for all its vintages.

Another rule can “move” some individual instances into the set of classes:

If concepts form a natural hierarchy, then we should represent them as classes

Consider the wine regions. Initially, we may define main wine regions, such as France, United States, Germany, and so on, as classes and specific wine regions within these large regions as instances. For example, Bourgogne region is an instance of the French region class. However, we would also like to say that the Cotes d’Or region is a Bourgogne region . Therefore, Bourgogne region must be a class (in order to have subclasses or instances). However, making Bourgogne region a class and Cotes d’Or region an instance of Bourgogne region seems arbitrary: it is very hard to clearly distinguish which regions are classes and which are instances. Therefore, we define all wine regions as classes. Prot�g�-2000 allows users to specify some classes as Abstract, signifying that the class cannot have any direct instances. In our case, all region classes are abstract ( Figure 8 ).

Figure 8 . Hierarchy of wine regions. The "A" icons next to class names indicate that the classes are abstract and cannot have any direct instances.

The same class hierarchy would be incorrect if we omitted the word “region” from the class names. We cannot say that the class Alsace is a subclass of the class France : Alsace is not a kind of France. However, Alsace region is a kind of a French region.

Only classes can be arranged in a hierarchy—knowledge-representation systems do not have a notion of sub-instance. Therefore, if there is a natural hierarchy among terms, such as in terminological hierarchies from Section 4.2 , we should define these terms as classes even though they may not have any instances of their own.

4.7         Limiting the scope

As a final note on defining a class hierarchy, the following set of rules is always helpful in deciding when an ontology definition is complete:

The ontology should not contain all the possible information about the domain: you do not need to specialize (or generalize) more than you need for your application (at most one extra level each way).

For our wine and food example, we do not need to know what paper is used for the labels or how to cook shrimp dishes.

Similarly, the ontology should not contain all the possible properties of and distinctions among classes in the hierarchy.

In our ontology, we certainly do not include all the properties that a wine or food could have.   We represented the most salient properties of the classes of items in our ontology.   Even though wine books would tell us the size of grapes, we have not included this knowledge.   Similarly, we have not added all relationships that one could imagine among all the terms in our system.   For example, we do not include relationships such as favorite wine and favorite food in the ontology just to allow a more complete representation of all of the interconnections between the terms we have defined.

The last rules also applies to establishing relations among concepts that we have already included in the ontology. Consider an ontology describing biology experiments. The ontology will likely contain a concept of Biological organisms . It will also contain a concept of an Experimenter performing an experiment (with his name, affiliation, etc.). It is true that an experimenter, as a person, also happens to be a biological organism. However, we probably should not incorporate this distinction in the ontology: for the purposes of this representation an experimenter is not a biological organism and we will probably never conduct experiments on the experimenters themselves. If we were representing everything we can say about the classes in the ontology, an Experimenter would become a subclass of Biological Organism . However, we do not need to include this knowledge for the foreseeable applications. In fact, including this type of additional classification for existing classes actually hurts: now an instance of an Experimenter will have slots for weight, age, species, and other data pertaining to a   biological organism, but absolutely irrelevant in the context of describing an experiment. However, we should record such design decision in the documentation for the benefit of the users who will be looking at this ontology and who may not be aware of the application we had in mind.

4.8         Disjoint subclasses

Many systems allow us to specify explicitly that several classes are disjoint . Classes are disjoint if they cannot have any instances in common. For example, the Dessert wine and the White wine   classes in our ontology are not disjoint: there are many wines that are instances of both. The Rothermel Trochenbierenauslese Riesling instance of the Sweet Riesling class is one such example. At the same time, the Red wine and the White wine classes are disjoint: no wine can be simultaneously red and white. Specifying that classes are disjoint   enables the system to validate the ontology better. If we declare the Red wine and the White wine classes to be disjoint and later create a class that is a subclass of both Riesling (a subclass of White wine ) and Port (a subclass of Red wine ), a system can indicate that there is a modeling error.

5          Defining properties—more details

In this section we discuss several more details to keep in mind when defining slots in the ontology ( Step 5 and Step 6 in Section 3 ). Mainly, we discuss inverse slots and default values for a slot.

5.1         Inverse slots

A value of a slot may depend on a value of another slot. For example, if a wine was produced by a winery , then the winery produces that wine . These two relations, maker and produces , are called inverse relations . Storing the information “in both directions” is redundant. When we know that a wine is produced by a winery, an application using the knowledge base can always infer the value for the inverse relation that the winery produces the wine. However, from the knowledge-acquisition perspective it is convenient to have both pieces of information explicitly available. This approach allows users to fill in the wine in one case and the winery in another.. The knowledge-acquisition system could then automatically fill in the value for the inverse relation insuring consistency of the knowledge base.

Our example has a pair of   inverse slots: the maker slot of the Wine class and the produces slot of the Winery class. When a user creates an instance of the Wine class and fills in the value for the maker slot, the system automatically adds the newly created instance to the produces slot of the corresponding Winery instance. For instance, when we say that Sterling Merlot is produced by the Sterling Vineyard winery, the system would automatically add Sterling Merlot to the list of wines that the Sterling Vineyard winery produces. ( Figure 9 ).

Figure 9 . Instances with inverse slots. The slot produces for the class Winery is an inverse of the slot   maker for the class Wine . Filling in one of the slots triggers an automatic update of the other.

5.2         Default values

Many frame-based systems allow specification of default values for slots.   If a particular slot value is the same for most instances of a class, we can define this value to be a default value for the slot. Then, when each new instance of a class containing this slot is created, the system fills in the default value automatically. We can then change the value to any other value that the facets will allow. That is, default values are there for convenience: they do not enforce any new restrictions on the model or change the model in any way.

For example, if the majority of wines we are going to discuss are full-bodied wines, we can have “full” as a default value for the body of the wine. Then, unless we say otherwise, all wines we define would be full-bodied.

Note that this is different from slot values . Slot values cannot be changed. For example, we can say that the slot sugar has value SWEET for the Dessert wine class. Then all the subclasses and instances of the Dessert wine class will have the SWEET value for the slot sugar . This value cannot be changed in any of the subclasses or instances of the class.

6          What’s in a name?

Defining naming conventions for concepts in an ontology and then strictly adhering to these conventions not only makes the ontology easier to understand but also helps avoid some common modeling mistakes. There are many alternatives in naming concepts. Often there is no particular reason to choose one or another alternative. However, we need to

Define a naming convention for classes and slots and adhere to it.

The following features of a knowledge representation system affect the choice of naming conventions:

�          Does the system have the same name space for classes, slots, and instances? That is, does the system allow having a class and a slot with the same name (such as a class winery and a slot winery )?

�          Is the system case-sensitive? That is, does the system treat the names that differ only in case as different names (such as Winery and winery )?

�          What delimiters does the system allow in the names? That is, can names contain spaces, commas, asterisks, and so on?

Prot�g�-2000, for example, maintains a single name space for all its frames. It is case-sensitive. Thus, we cannot have a class winery and a slot winery . We can, however, have a class Winery (not the upper-case) and a slot winery . CLASSIC, on the other hand, is not case sensitive and maintains different name spaces for classes, slots, and individuals. Thus, from a system perspective, there is no problem in naming both a class and a slot Winery .

6.1         Capitalization and delimiters

First, we can greatly improve the readability of an ontology if we use consistent capitalization for concept names. For example, it is common to capitalize class names and use lower case for slot names (assuming the system is case-sensitive).

When a concept name contains more than one word (such as Meal course ) we need to delimit the words. Here are some possible choices.

�          Use Space: Meal course (many systems, including Prot�g�, allow spaces in concept names).  

�          Run the words together and capitalize each new word: MealCourse

�          Use an underscore or dash or other delimiter in the name: Meal_Course , Meal_course , Meal-Course , Meal-course . (If you use delimiters, you will also need to decide whether or not each new word is capitalized)

If the knowledge-representation system allows spaces in names, using them may be the most intuitive solution for many ontology developers. It is however, important to consider other systems with which your system may interact.   If those systems do not use spaces or if your presentation medium does not handle spaces well, it can be useful to use another method.

6.2         Singular or plural

A class name represents a collection of objects. For example, a class Wine actually represents all wines. Therefore, it could be more natural for some designers to call the class Wines rather than Wine . No alternative is better or worse than the other (although singular for class names is used more often in practice). However, whatever the choice, it should be consistent throughout the whole ontology. Some systems even require their users to declare in advance whether or not they are going to use singular or plural for concept names and do not allow them to stray from that choice.

Using the same form all the time also prevents a designer from making such modeling mistakes as creating a class Wines and then creating a class Wine as its subclass (see Section 4.1 ).

6.3         Prefix and suffix conventions

Some knowledge-base methodologies suggest using prefix and suffix conventions in the names to distinguish between classes and slots.   Two common practices are to add a has- or a suffix –of to slot names.   Thus, our slots become has-maker and has-winery if we chose the has- convention. The slots become maker-of and winery-of if we chose the of- convention.   This approach allows anyone looking at a term to determine immediately if the term is a class or a slot.   However, the term names become slightly longer.

6.4         Other naming considerations

Here are a few more things to consider when defining naming conventions:

�          Do not add strings such as “class”, “property”, “slot”, and so on to concept names.

It is always clear form the context whether the concept is a class or a slot, for example. In addition is you use different naming conventions for classes and slots (say, capitalization and no capitalization respectively), the name itself would be indicative of what the concept is.

�          It is usually a good idea to avoid abbreviations in concept names (that is, use Cabernet Sauvignon rather than Cab )

�          Names of direct subclasses of a class should either all include or not include the name of the superclass. For example, if we are creating two subclasses of the Wine class to represent red and white wines, the two subclass names should be either Red Wine and White Wine or Red and White , but not Red Wine and White .

7          Other Resources

We have used Prot�g�-2000 as an ontology-developing environment for our examples. Duineveld and colleagues (Duineveld et al. 2000) describe and compare a number of other ontology-development environments.  

We have tried to address the very basics of ontology development and have not discussed many of the advanced topics or alternative methodologies for ontology development. G�mez-P�rez (G�mez-P�rez 1998) and Uschold (Uschold and Gruninger 1996) present alternative ontology-development methodologies. The Ontolingua tutorial (Farquhar 1997) discusses some formal aspects of knowledge modeling.   

Currently, researchers emphasize not only ontology development, but also ontology analysis.   As more ontologies are generated and reused, more tools will be available to analyze ontologies. For example, Chimaera (McGuinness et al. 2000) provides diagnostic tools for analyzing ontologies. The analysis that Chimaera performs includes both a check for logical correctness of an ontology and diagnostics of common ontology-design errors. An ontology designer may want to run Chimaera diagnostics over the evolving ontology to determine the conformance to common ontology-modeling practices.

8          Conclusions

In this guide, we have described an ontology-development methodology for declarative frame-based systems. We listed the steps in the ontology-development process and addressed the complex issues of defining class hierarchies and properties of classes and instances. However, after following all the rules and suggestions, one of the most important things to remember is the following: there is no single correct ontology for any domain . Ontology design is a creative process and no two ontologies designed by different people would be the same. The potential applications of the ontology and the designer’s understanding and view of the domain will undoubtedly affect ontology design choices. “The proof is in the pudding”—we can assess the quality of our ontology only by using it in applications for which we designed it.  

Acknowledgments

Prot�g�-2000 ( http://protege.stanford.edu ) was developed by Mark Musen’s group at Stanford Medical Informatics. We generated some of the figures with the OntoViz plugin to Prot�g�-2000. We imported the initial version of the wine ontology from the Ontolingua ontology library ( http://www.ksl.stanford.edu/software/ontolingua/ ) which in turn used a version published by Brachman and colleagues (Brachman et al. 1991) and distributed with the CLASSIC knowledge representation system. We then modified the ontology to present conceptual-modeling principles for declarative frame-based ontologies. Ray Fergerson’s and Mor Peleg’s extensive comments on earlier drafts greatly improved this paper.

Booch, G., Rumbaugh, J. and Jacobson, I. (1997). The Unified Modeling Language user guide : Addison-Wesley.

Brachman, R.J., McGuinness, D.L., Patel-Schneider, P.F., Resnick, L.A. and Borgida, A. (1991). Living with CLASSIC: When and how to use KL-ONE-like language. Principles of Semantic Networks . J. F. Sowa, editor, Morgan Kaufmann : 401-456.

Brickley, D. and Guha, R.V. (1999). Resource Description Framework (RDF) Schema Specification. Proposed Recommendation, World Wide Web Consortium : http://www.w3.org/TR/PR-rdf-schema.

Chimaera (2000). Chimaera Ontology Environment. www.ksl.stanford.edu/software/chimaera

Duineveld, A.J., Stoter, R., Weiden, M.R., Kenepa, B. and Benjamins, V.R. (2000). WonderTools? A comparative study of ontological engineering tools. International Journal of Human-Computer Studies 52 (6): 1111-1133.

Farquhar, A. (1997). Ontolingua tutorial. http://ksl-web.stanford.edu/people/axf/tutorial.pdf

G�mez-P�rez, A. (1998). Knowledge sharing and reuse. Handbook of Applied Expert Systems . Liebowitz, editor, CRC Press.

Gruber, T.R. (1993). A Translation Approach to Portable Ontology Specification. Knowledge Acquisition 5 : 199-220.

Gruninger, M. and Fox, M.S. (1995). Methodology for the Design and Evaluation of Ontologies. In: Proceedings of the Workshop on Basic Ontological Issues in Knowledge Sharing, IJCAI-95 , Montreal.

Hendler, J. and McGuinness, D.L. (2000). The DARPA Agent Markup Language. IEEE Intelligent Systems 16 (6): 67-73.

Humphreys, B.L. and Lindberg, D.A.B. (1993). The UMLS project: making the conceptual connection between users and the information they need. Bulletin of the Medical Library Association 81 (2): 170.

McGuinness, D.L., Abrahams, M.K., Resnick, L.A., Patel-Schneider, P.F., Thomason, R.H., Cavalli-Sforza, V. and Conati, C. (1994). Classic Knowledge Representation System Tutorial. http://www.bell-labs.com/project/classic/papers/ClassTut/ClassTut.html

McGuinness, D.L., Fikes, R., Rice, J. and Wilder, S. (2000). An Environment for Merging and Testing Large Ontologies. Principles of Knowledge Representation and Reasoning: Proceedings of the Seventh International Conference (KR2000) . A. G. Cohn, F. Giunchiglia and B. Selman, editors. San Francisco, CA, Morgan Kaufmann Publishers.

McGuinness, D.L. and Wright, J. (1998). Conceptual Modeling for Configuration: A Description Logic-based Approach. Artificial Intelligence for Engineering Design, Analysis, and Manufacturing - special issue on Configuration .

Musen, M.A. (1992). Dimensions of knowledge sharing and reuse. Computers and Biomedical Research 25 : 435-467.

Ontolingua (1997). Ontolingua System Reference Manual. http://www-ksl-svc.stanford.edu:5915/doc/frame-editor/index.html

Price, C. and Spackman, K. (2000). SNOMED clinical terms. BJHC&IM-British Journal of Healthcare Computing & Information Management 17 (3): 27-31.

Protege (2000). The Protege Project. http://protege.stanford.edu

Rosch, E. (1978). Principles of Categorization. Cognition and Categorization . R. E. and B. B. Lloyd, editors. Hillside, NJ, Lawrence Erlbaum Publishers : 27-48.

Rothenfluh, T.R., Gennari, J.H., Eriksson, H., Puerta, A.R., Tu, S.W. and Musen, M.A. (1996). Reusable ontologies, knowledge-acquisition tools, and performance systems:   PROT�G�-II solutions to Sisyphus-2. International Journal of Human-Computer Studies 44 : 303-332.

Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F. and Lorensen, W. (1991). Object-oriented modeling and design . Englewood Cliffs, New Jersey: Prentice Hall.

Uschold, M. and Gruninger, M. (1996). Ontologies: Principles, Methods and Applications. Knowledge Engineering Review 11 (2).

[1] We capitalize class names and start slot names with low-case letters. We also use typewriter font for all terms from the example ontology.

[2] We can also view classes as unary predicates—questions that have one argument.   For example, “Is this object a wine?”   Unary predicates (or classes) contrast with binary predicates (or slots)—questions that have two arguments.   For example, “Is the flavor of this object strong?” “What is the flavor of this object?”

[3] Some systems just specify value type with a class instead of requiring a special statement of instance type slots.

[4] We chose to represent only red Ports in our ontology: white Ports do exist but they are extremely uncommon.

[5] Here we assume that each anatomical organ is a class since we would also like to talk about “John’s 1 st left rib.” Individual organs of existing people would be represented as individuals in our ontology.

Theory and Applications of Ontology: Computer Applications pp 411–428 Cite as

Business Ontologies

• Peter Rittgen 4 , 5  
• First Online: 01 January 2010

1910 Accesses

The business domain has many facets and there is no single approach that can claim general validity in the whole domain. Instead a number of approaches that are rooted in different fields of research, e.g. agent systems, language action, socio-instrumental action etc., compete for an appropriate conceptualization We give an overview of them and provide some deeper insight into two of them, socio-instrumental pragmatism and enterprise ontology.

• Domain-level ontologies
• Application-level ontologies
• Socio-instrumental pragmatism
• Enterprise ontology

This is a preview of subscription content, access via your institution .

Buying options

• Available as PDF
• Read on any device
• Instant download
• Own it forever
• Available as EPUB and PDF
• Compact, lightweight edition
• Dispatched in 3 to 5 business days
• Free shipping worldwide - see info
• Durable hardcover edition

Tax calculation will be finalised at checkout

Purchases are for personal use only

Anderson, P. 1999. Complexity theory and organization science. Organization Science 10(3):216–232.

CrossRef   Google Scholar  

Austin, J.L. 1975. How to do things with words . Cambridge, MA: Harvard University Press.

Google Scholar  

Bertolazzi, P., C. Krusich, M. Missikoff. 2001. An approach to the definition of a core enterprise ontology: CEO. Paper presented at the International Workshop on Open Enterprise Solutions: Systems, Experiences, and Organizations (OES-SEO 2001), Rome, 14–15 Sep 2001.

Bugaite, D., and O. Vasilecas. 2005. Framework on application domain ontology transformation into set of business rules. Paper presented at the International Conference on Computer Systems and Technologies – CompSysTech 2005.

Bunge, M. 1977. Ontology I: The Furniture of the World . Dordrecht: Reidel.

Carmichael, D.J., J. Kay, and B. Kummerfeld. 2004. Personal ontologies for feature selection in intelligent environment visualisations. In Artificial intelligence in mobile systems 2004 , eds. J. Baus, C. Kray, and R. Porzel, 44–51. Saarbrücken, Germany: Universität des Saarlandes.

Corbett, D. 2003. Comparing and merging ontologies: A concept type hierarchy approach. In Foundations of intelligent systems , eds. N. Zhong, Z.W. Ras, S. Tsumoto, and E. Suzuki. Proceedings of the 14th International Symposium, ISMIS 2003. Maebashi City, Japan, 28–31 Oct 2003, 75–82. Berlin: Springer.

Davern, M. 1997. Social networks and economic sociology. A proposed research agenda for a more complete social science. American Journal of Economics and Sociology 56(3):287–301.

Dieng, R., and S. Hug. 1998. Comparison of <<personal ontologies>> represented through conceptual graphs. In ECAI 98. 13th European Conference on Artificial Intelligence, ed. H. Prade, 341–345. New York, NY: Wiley.

Dietz, J.L.G. 2006. Enterprise ontology: Theory and methodology . Heidelberg: Springer.

Dietz, J.L.G., and N. Habing. 2004. A meta ontology for organizations. In On the move to meaningful internet systems 2004: OTM 2004 workshops , eds. R. Meersman, Z. Tari, A. Corsaro, P. Herrero, M. S. Pérez, M. Radenkovic, V. Robles, C. Santoro, A. Albani, K. Turowski, M. Jarrar, A. Gangemi, E. Duval, P. Spyns, and A. Palinginis, Proceedings of the OTM Confederated International Workshops and Posters, GADA, JTRES, MIOS, WORM, WOSE, PhDS, and INTEROP 2004, Agia Napa, Cyprus, 25–29 Oct 2004, vol. 3292, 533–543. Berlin: Springer.

Domingue, J. 1998. Tadzebao and WebOnto: Discussing, browsing, and editing on the web. In eds. B. Gaines, and M. Musen. Proceedings of the 11th Knowledge Acquisition for Knowledge-Based Systems Workshop, 18–23 Apr, Canada: Banff.

Embley, D., B. Kurtz, and S. Woodfield. 1992. Object oriented system analysis: A model-driven approach . Upper Saddle River, NJ: Yourdon Press.

Farquhar, A., R. Fikes, and J. Rice. 1997. The Ontolingua server: Tools for collaborative ontology construction. International Journal of Human Computer Studies 46:707–728.

Flood, R.L. 2005. Unleashing the “open system” metaphor. Systemic Practice and Action Research 1(3):313–318.

Fox, M.S., and M. Gruninger. 1998. Enterprise modeling. AI Magazine 19(3):109–121.

Gareth, M. 1997. Images of organization . London: Sage.

Giddens, A. 1986. The constitution of society. Outline of the theory of structuration . Berkeley, CA: University of California Press.

Goldkuhl, G. 2001. Communicative vs material actions: Instrumentality, sociality and comprehensibility. Paper presented at the 6th International Workshop on the Language Action Perspective (LAP2001), Montreal.

Goldkuhl, G. 2002. Anchoring scientific abstractions – Ontological and linguistic determination following socio-instrumental pragmatism. Paper presented at the European Conference on Research Methods in Business and Management (ECRM 2002), Reading, 29–30 Apr 2002.

Goldkuhl, G. 2005. Socio-instrumental pragmatism: A theoretical synthesis for pragmatic conceptualisation in information systems. Paper presented at the 3rd International Conference on Action in Language, Organisations and Information Systems (ALOIS), University of Limerick.

Goldkuhl, G., and P. Ågerfalk. 2000. Actability: A way to understand information systems pragmatics. Paper presented at the 3rd International Workshop on Organisational Semiotics, Stafford, 4 July 2000.

Goldkuhl, G., and P. Ågerfalk. 2005. IT artefacts as socio-pragmatic instruments: Reconciling the pragmatic, semiotic, and technical. International Journal of Technology and Human Interaction 1(3):29–43.

Goldkuhl, G., and M. Lind. 2004. Developing e-interactions – A framework for business capabilities and exchanges. Paper presented at the 12th European Conference on Information Systems, Turku, Finland, 14–16 June 2004.

Goldkuhl, G., A. Röstlinger, and E. Braf. 2001. Organisations as practice systems – integrating knowledge, signs, artefacts and action. Paper presented at the Organisational Semiotics, IFIP 8.1 Conference, Montreal.

Gordijn, J. 2004. E-business value modelling using the e3-value ontology. In Value creation form e-business models , ed. W.L. Curry, 98–127, Chapter 5. Oxford: Elsevier Butterworth-Heinemann.

Guarino, N. 1998. Formal ontology and information systems. In Proceedings of the 1st International Conference on Formal Ontology in Information Systems (FOIS’98), 3–15. Amsterdam: IOS Press.

Guizzardi, G., G. Wagner, N. Guarino, and M.V. Sinderen. 2004. An ontologically well-founded profile for UML conceptual models. In Proceedings of the 16th International Conference on Advanced Information Systems Engineering, CAiSE 2004, vol. 3084, 112–126, Berlin: Springer.

Haase, P., A. Hotho, L. Schmidt-Thieme, and Y. Sure. 2005. Collaborative and usage-driven evolution of personal ontologies. In eds. A. Gómez-Pérez, and J. Euzenat. Proceedings of the 2nd European Semantic Web Conference, Heraklion, Greece, 2005 Vol. 3532, 486–499, Heidelberg: Springer.

Habermas, J. 1984. The theory of communicative action 1 – reason and the rationalization of society . Boston, MA: Beacon Press.

Halpin, T.A. 2001. Information modeling and relational databases . San Francisco, CA: Morgan Kaufmann.

Heflin, J., and J. Hendler. 2000. Dynamic ontologies on the web. In Proceedings of the 17th National Conference on Artificial Intelligence (AAAI-2000), 443–449, Menlo Park, CA: AAAI/MIT Press.

Huhns, M.N., and L.M. Stephens. 1999. Personal ontologies. IEEE Internet Computing 3(5):85–87.

Jensen, M.C., and W.H. Meckling. 1976. Theory of the firm: managerial behavior, agency costs and ownership structure. Journal of Financial Economics 3:305–360.

Kendall, J.E., and K.E. Kendall. 1993. Metaphors and methodologies: Living beyond the systems machine. MIS Quarterly 17(2):149–171.

Klein, B., R. Crawford, and A. Alchian. 1978. Vertical integration, appropriable rents, and the competitive contracting process. Journal of Law and Economics 21:297–326.

Law, J. 1992. Notes on the theory of the actor-network: Ordering, strategy and heterogeneity. Systemic Practice and Action Research 5(4):379–393.

Luhmann, N. 1990. The autopoiesis of social systems. In Essays on self-reference , ed. N. Luhmann, 1–21. New York, NY: Columbia University Press.

OMG. 2005. Unified modeling language: Superstructure. Version 2.0, August 2005, Needham, MA: OMG. Retrieved, June 20 2006, from http://www.uml.org/ .

OMG. 2006. Unified modeling language: Infrastructure. Version 2.0, March 2006, Needham, MA: OMG. Retrieved, June 20 2006, from http://www.uml.org/ .

Osterwalder, A. 2004. The business model ontology – a proposition in a design science approach. Ph.D. thesis, University of Lausanne, Ecole des Hautes Etudes Commerciales HEC: 173.

Rose, J., and M. Jones. 2004. The double dance of agency: A socio-theoretic account of how machines and humans interact. Paper presented at the ALOIS Workshop: Action in Language, Organisations and Information Systems, Linköping.

Ross, S. 1973. The economic theory of agency: The principal’s problem. American Economic Review 63(2):134–139.

Scott, A. 1997. Modernity’s machine metaphor. The British Journal Of Sociology 48(4):561–575.

Searle, J.R. 1997. Speech acts – An essay in the philosophy of language . Cambridge, MA: Cambridge University Press.

Searle, J.R. 1999. Expression and meaning. Studies in the theory of speech acts . Cambridge, MA: Cambridge University Press.

Senge, P.M. 1990. The fifth discipline. The art and practice of the learning organization . New York, NY: Doubleday.

Uschold, M., M. King, S. Moralee, and Y. Zorgios. 1998. The enterprise ontology. Knowledge Engineering Review 13(1):31–89.

Verharen, E. 1997. A language-action perspective on the design of cooperative information agents . Tilburg: Katholieke Universiteit Brabant.

Walsham, G. 1997. Actor-network theory: Current status and future prospects. In Information systems and qualitative research , eds. A.S. Lee, J.Liebenau, and J.I. Degross. London: Chapman & Hall.

Williamson, O.E. 1981. The modern corporation: Origins, evolution, attributes. Journal of Economic Literature 19:1537–1568.

Williamson, O.E. 1983. Markets and hierarchies . New York, NY: Free Press.

Williamson, O.E. 1998. The economic institutions of capitalism . New York, NY: Free Press.

Wittgenstein, L. 2001. Tractatus logico-philosophicus . London: Routledge.

Download references

Author information

Authors and affiliations.

Vlerick Leuven Gent Management School, Leuven, Belgium

Peter Rittgen

University of Borås, Borås, Sweden

You can also search for this author in PubMed   Google Scholar

Corresponding author

Correspondence to Peter Rittgen .

Editor information

Editors and affiliations.

Dipto. Sociologia e Ricerca Sociale, Universita di Trento, Via Verdi 26, Trento, 38100, Italy

Roberto Poli

23rd Place NE., 13544, Seattle, 98125-3325, Washington, USA

Michael Healy

Computer Technology Institute, Hellenic Open University &, N. Kazantzaki Str., Patras, 265 00, Greece

Achilles Kameas

Rights and permissions

Reprints and Permissions

Copyright information

© 2010 Springer Netherlands

About this chapter

Cite this chapter.

Rittgen, P. (2010). Business Ontologies. In: Poli, R., Healy, M., Kameas, A. (eds) Theory and Applications of Ontology: Computer Applications. Springer, Dordrecht. https://doi.org/10.1007/978-90-481-8847-5_18

Download citation

DOI : https://doi.org/10.1007/978-90-481-8847-5_18

Published : 12 August 2010

Publisher Name : Springer, Dordrecht

Print ISBN : 978-90-481-8846-8

Online ISBN : 978-90-481-8847-5

eBook Packages : Humanities, Social Sciences and Law Philosophy and Religion (R0)

Share this chapter

Anyone you share the following link with will be able to read this content:

Sorry, a shareable link is not currently available for this article.

Provided by the Springer Nature SharedIt content-sharing initiative

• Find a journal
• Publish with us

Business Model Canvas

Build & Design , Tools and Methods

Alexander Osterwalder, Yves Pigneur: 2010

Original Source Old Version with description

• Components Overview Value Proposition

Description

The most common and widespread tool for developing and visualizing a business model is the Business Model Canvas by Alexander Osterwalder and Yves Pigneur. The canvas was co-created with many practitioners and was based on  The Business Model Ontology  developed by Alexander Osterwalder in 2004.  The results are a best-seller book, entitled  Business Model Generation , and the tool Business Model Canvas. The canvas has been published online with a Creative Common License and therefore published and iterated by many practitioners.

The 9 Building Blocks

The underlying idea is, that a business model consists of nine building blocks describing the value proposition, customers, value delivery and value creation, as well as the financial perspective.

• Value Propositions:  What kind of value do you deliver to your customer (e.g. efficiency, convenience, social status, low prices)? How do you satisfy your customers’ needs?
• Customer Segments:   For whom are you creating this value? Can you differentiate between different customer groups?
• Channels:   How do you deliver the value to your customer segments? This starts from raising awareness and also applies to purchasing, delivery and aftersales.
• Customer Relationships:   What is the relationship between you and your customer? E.g. self-service, personal assistance during sales, creating a community where members share knowledge.
• Revenue Streams:   How do you generate revenue? Whom do you generate revenue from and what form does the revenue have (e.g. subscription fee, renting fee, advertisement, etc.)?
• Key Activities:   How do you generate value (service / product) for your customer?
• Key Resources:   What knowledge, infrastructure and financial resources do you need?
• Key Partnerships:   Who are our partners that help us to create value? Who are our suppliers?
• Cost Structure:   What costs arise from creating and delivering value to your customer, from your key activities and your key resources?
• Well-known tool for business model innovation
• Easy to apply
• Easy to understand the general structure
• A lot of additional information, resources and online tools available
• Easy to compare different business model canvases
• Helps to focus on the value proposition for the customer instead of the product and its features
• Comprehensive high-level overview
• Relations between components are not visible
• Value exchange between actors and core concept are not visible
• No information on growth strategy and competitive strategy
• No team or cultural elements (only within resources)
• No differentiation between customers and users
• Missing perspective for sustainability and responsibility of business

How to apply this tool?

• With an idea:   start with defining the value proposition for a specific customer segment.
• With potential / existing customers:   start with the customer segment, ask what value proposition you are delivering / could deliver to them and how.
• With your resources:   start thinking about what key resources (competences, experiences, physical resources, financial resources, etc.) you and your partner(s) have and, based on this, develop your offer for a specific customer group.

View on Responsibility

• Social Business Model Canvas

My thoughts and experience of this model is very useful. I was thinking of doing the same structure in kenya where majority of the population is poor with less access to medical treatment. I like the canvas model and finding ways to convince local Doctors and hospitals to emulate the same model. The most challenging thing is balancing between giving out services without going at a loss financially.

Submit a Comment Cancel reply

Your email address will not be published. Required fields are marked *

Save my name, email, and website in this browser for the next time I comment.

Ontology for Businesses

If your business uses any kind of database system, you already have a rudimentary ontology contained within the structure of your database tables. The problem is that if you have several database systems, one for distribution and one for accounting, for example, those systems may not agree in how they understand key terms in your business, such as ‘product’. For this reason, meta-data management systems have been developed to help coordinate information about your business between these various system. However, for many businesses, such meta-data managements systems have seemed like a cumbersome addition to business processes that do not realize a clear business benefit.

Another problem that businesses face is knowledge management, namely retaining key information about your business operations in a way that is not dependent upon individual employees who may quit or retire. While many businesses recognize this problem to be important, it may seem like an extravagance to create a completely new system just for knowledge management, only to worry about whether this new knowledge management system actually agrees with the other business systems.

Formal ontology helps address both of these problems. By formalizing your business rules and processes, formal ontology provides a way to clarify and to retain key knowledge within your company. Plus, Semantic Web technology makes it possible for these same business rules to be incorporated directly into all of your business systems, helping to ensure that all your systems agree about key terms in your business. Since the business rules could be maintained outside of the hard code of your business systems, it would be possible to change those business rules more quickly, without lengthy computer programming and testing delays.

To start exploring how formal ontology could help your business, see the following:

Training in ontology development

Technologies for ontology implementation