|
| 1 | +--- |
| 2 | +title: "Training: Ontology Engineering" |
| 3 | +icon: material/presentation |
| 4 | +tags: |
| 5 | + - BeginnersTutorial |
| 6 | + - Vocabulary |
| 7 | +--- |
| 8 | +# Ontology Engineering |
| 9 | + |
| 10 | +<div class="training-deck"> |
| 11 | +<iframe src="slides.html" title="Slides: Ontology Engineering" allow="fullscreen"></iframe> |
| 12 | +</div> |
| 13 | + |
| 14 | +!!! abstract "About this module" |
| 15 | + |
| 16 | + This hands-on module shows how to develop an ontology for a domain, from the first requirements to a formal vocabulary in eccenca Corporate Memory. |
| 17 | + The example is the product domain whose data the [SPARQL exercises](../sparql-basics/index.md#exercises) query. |
| 18 | + It follows [Ontology Modeling](../ontology-modeling/index.md) and is part of the [Corporate Memory training](../index.md). |
| 19 | + |
| 20 | + Use **Show slide** next to a heading to bring the matching slide into view, or **Read the explanation** under the slides to jump to the text for the current slide. |
| 21 | + |
| 22 | +## What an ontology is { #what-is-an-ontology } |
| 23 | + |
| 24 | +An ontology is a shared, structured conceptualization of a domain. |
| 25 | +Each of the three words carries part of the meaning: |
| 26 | + |
| 27 | +- **Conceptualization** – an abstract, simplified view of the domain, made for a purpose. |
| 28 | + It captures the objects and concepts of the domain and the relations between them. |
| 29 | +- **Structured** – written in a standard modeling language such as RDF Schema, OWL or SKOS, so that machines can process it. |
| 30 | +- **Shared** – agreed on by the domain experts, so that it serves as a common, extensible standard for the data of the domain. |
| 31 | + |
| 32 | +Domains range from the most basic things, such as persons, places and activities, to specialist areas such as supply chains or manufacturing. |
| 33 | + |
| 34 | +## Methodology { #methodology } |
| 35 | + |
| 36 | +There is no single correct way to engineer an ontology, and no single correct result. |
| 37 | +The domain and the application decide. |
| 38 | + |
| 39 | +A few principles hold in general. |
| 40 | +The concepts of the ontology stay close to the physical or logical objects of the domain and the relations between them. |
| 41 | +They are usually the nouns and verbs of sentences that describe the domain: nouns become classes, verbs become properties. |
| 42 | +The intended use decides which of them the ontology needs. |
| 43 | + |
| 44 | +Ontology engineering is iterative. |
| 45 | +A first model is discussed with the domain experts, applied to real data, and refined, again and again. |
| 46 | + |
| 47 | +## Scope and requirements { #scope-and-requirements } |
| 48 | + |
| 49 | +The scope of an ontology depends on its domain, its application and its users. |
| 50 | +A few questions clarify it at the start: |
| 51 | + |
| 52 | +- Is there data already, or is the model built on a green field? |
| 53 | +- If there is data, what is it used for? |
| 54 | +- Is the goal a clearer, logical model of the domain, or compatibility with existing structures? |
| 55 | +- How much metadata is needed? |
| 56 | +- Which other data sources are relevant? |
| 57 | +- Do ontologies for the domain exist already, see [Reuse existing vocabularies](../ontology-modeling/index.md#reuse)? |
| 58 | + |
| 59 | +## Competency questions { #competency-questions } |
| 60 | + |
| 61 | +Competency questions turn the requirements into a test. |
| 62 | +They are the questions the ontology has to be able to answer, collected in a catalog at the start. |
| 63 | + |
| 64 | +After each milestone, example data that follows the ontology is created, and the questions are answered by querying or browsing it. |
| 65 | +A question that cannot be answered shows a gap in the model. |
| 66 | + |
| 67 | +For the product domain, typical competency questions are: |
| 68 | + |
| 69 | +- Which products is a department responsible for? |
| 70 | +- Who manages a given product, and in which department does that person work? |
| 71 | +- Who can take over a product when its manager leaves? |
| 72 | + |
| 73 | +The [SPARQL exercises](../sparql-basics/index.md#exercises) answer exactly such questions on the product data. |
| 74 | + |
| 75 | +## Source material { #source-material } |
| 76 | + |
| 77 | +The knowledge for an ontology comes from many sources: |
| 78 | +existing databases and spreadsheets, slide decks and training material, company taxonomies, product catalogs, books and standards, and interviews with domain experts. |
| 79 | + |
| 80 | +In practice, it is usually a combination. |
| 81 | +A project receives a spreadsheet and a slide deck, interviews a domain expert, drafts a first ontology, iterates it with the expert, and receives further material along the way. |
| 82 | + |
| 83 | +## The domain { #the-domain } |
| 84 | + |
| 85 | +The exercise models a short description of a product domain: |
| 86 | +products and services, the product managers who manage them, the departments the managers work in, and the product categories in which the departments and managers have expertise. |
| 87 | + |
| 88 | +The second paragraph of the description names concrete things: a product with its identifier and name, a product manager and a department. |
| 89 | +These are the instances the model has to accommodate. |
| 90 | + |
| 91 | +## Concepts, relationships, instances and attributes { #concepts-relationships-instances-and-attributes } |
| 92 | + |
| 93 | +Reading the description four times, each time with a different question, structures the domain: |
| 94 | + |
| 95 | +1. **Concepts** – what kinds of things are there? |
| 96 | + Products, services, product managers, departments, direct reports and categories. |
| 97 | +2. **Relationships** – how are they connected? |
| 98 | + Products are *managed by* product managers, managers *have* direct reports, products are *structured into* categories, departments are *responsible* for products, and managers and departments *have expertise* in categories. |
| 99 | +3. **Instances** – which concrete things are mentioned? |
| 100 | + P516-8211068, Film Multiplexer Rheostat Warp, Kristen Bauers and Procurement. |
| 101 | + In a real project, instances come from the data sources rather than from documentation. |
| 102 | +4. **Attributes** – which values describe a thing? |
| 103 | + A product is *named*, so it has a name. |
| 104 | + |
| 105 | +## Defining classes { #defining-classes } |
| 106 | + |
| 107 | +Three strategies lead from the candidates to a class hierarchy: |
| 108 | + |
| 109 | +- **Top-down** starts with the most general classes and specializes them. |
| 110 | +- **Bottom-up** starts with the most specific classes and groups them into more general ones. |
| 111 | +- **Middle-out** starts with the most important classes and generalizes and specializes from there. |
| 112 | + |
| 113 | +In the product domain, middle-out works well. |
| 114 | +*Product* is central, and *hardware* and *service* specialize it. |
| 115 | +*Product manager* and *direct report* turn out not to be classes of their own: both are employees, distinguished only by their relations. |
| 116 | +They become the class *Employee*, its subclass *Manager*, and the common superclass *Agent* for anyone who can be a member of a department. |
| 117 | + |
| 118 | +A drawing helps at this stage: classes as boxes, relations as arrows between them. |
| 119 | + |
| 120 | +## The model { #the-model } |
| 121 | + |
| 122 | +The diagram shows the core of the products vocabulary as it is installed with the **Product Data Demo** package, version v1.2.0: |
| 123 | + |
| 124 | +| Class | Meaning | |
| 125 | +| --- | --- | |
| 126 | +| `prod:Product` with `prod:Hardware` and `prod:Service` | what the company offers | |
| 127 | +| `prod:Agent` with `prod:Employee` and `prod:Manager` | people who act in the company | |
| 128 | +| `prod:Department` | an organizational unit | |
| 129 | +| `prod:ProductCategory` | a category of products | |
| 130 | + |
| 131 | +| Property | From | To | |
| 132 | +| --- | --- | --- | |
| 133 | +| `prod:hasProductManager` | Product | Employee | |
| 134 | +| `prod:hasCategory` | Product | ProductCategory | |
| 135 | +| `prod:areaOfExpertise` | Agent | ProductCategory | |
| 136 | +| `prod:memberOf` | Agent | Department | |
| 137 | +| `prod:responsibleFor` | Department | Product | |
| 138 | +| `prod:hasManager` | Employee | Manager | |
| 139 | +| `prod:eligibleFor` | Service | Product | |
| 140 | + |
| 141 | +The relations of the description map onto these properties: *managed by* became `prod:hasProductManager`, *have expertise* became `prod:areaOfExpertise`. |
| 142 | +The direct report relation is `prod:hasManager`, read from the other end, and `prod:hasDirectReport` exists as well. |
| 143 | + |
| 144 | +The vocabulary has grown beyond the first draft of the exercise. |
| 145 | +It adds suppliers, prices, bills of material and physical dimensions, and models addresses as simple attributes of an agent. |
| 146 | + |
| 147 | +!!! note "Older vocabulary versions" |
| 148 | + |
| 149 | + Earlier versions of this exercise and of the build tutorials use the vocabulary version 0.0.1. |
| 150 | + It names the expertise property `prod:expertFor`, has a property `prod:managesProduct`, and models addresses as a class `prod:Address` of their own. |
| 151 | + |
| 152 | +## Class or attribute? { #class-or-attribute } |
| 153 | + |
| 154 | +A recurring modeling decision is whether something becomes a class with instances of its own, or remains an attribute value. |
| 155 | + |
| 156 | +Take facilities and the cities they are in. |
| 157 | +As long as the city is only a name, an attribute such as `cityName` with a string value is enough. |
| 158 | +Once the data says something about the city itself, such as its location, the city has to become a resource: the facility is `locatedIn` a city, and the city has a label and a location. |
| 159 | + |
| 160 | +Make something a class when |
| 161 | + |
| 162 | +- it is a business object in its own right, |
| 163 | +- there are, or will be, statements about it, |
| 164 | +- other datasets describe the same things, so that links to them become possible. |
| 165 | + |
| 166 | +Both options are valid, and the requirements decide. |
| 167 | + |
| 168 | +## Formalize { #formalize } |
| 169 | + |
| 170 | +The drawing is then written down as RDFS and OWL. |
| 171 | +Each class and property gets a type, its place in the hierarchy, domain and range, a label, and a link to the ontology that defines it. |
| 172 | + |
| 173 | +Any text editor can produce Turtle. |
| 174 | +Ontology editors such as Protégé add forms, consistency checks and reasoning. |
| 175 | +In Corporate Memory, the Business Knowledge Editor creates classes and properties visually, see [Visually Authoring Ontologies](../../explore-and-author/bke-module/visually-authoring-ontologies/index.md). |
| 176 | + |
| 177 | +## Quality checks { #quality-checks } |
| 178 | + |
| 179 | +An ontology is easier to use and maintain when it meets a few rules consistently: |
| 180 | + |
| 181 | +- The ontology header names the version, the preferred namespace and the preferred prefix. |
| 182 | +- Every class and property has an `rdf:type` and an `rdfs:isDefinedBy` pointing to the ontology. |
| 183 | +- Every class and property has at least one `rdfs:label` and one `rdfs:comment`, without placeholders such as "todo". |
| 184 | +- Labels differ from comments, and no two resources share a label or a comment. |
| 185 | + |
| 186 | +Such rules can be checked automatically with SPARQL queries or SHACL shapes. |
| 187 | +SHACL also checks the instance data against the model, and Corporate Memory can run these checks in workflows and in continuous integration pipelines, see [Continuous integration](../../automate/continuous-integration/index.md). |
| 188 | + |
| 189 | +## Visualize and use { #visualize-and-use } |
| 190 | + |
| 191 | +A diagram shows the structure of an ontology at a glance. |
| 192 | +It helps domain experts, who often find a picture easier to follow than Turtle, and it reveals modeling errors such as missing relations. |
| 193 | + |
| 194 | +Corporate Memory supports the whole cycle: |
| 195 | + |
| 196 | +- the [Vocabulary Catalog](../../explore-and-author/vocabulary-catalog/index.md) installs and manages vocabularies, |
| 197 | +- the [Business Knowledge Editor](../../explore-and-author/bke-module/index.md) explores and authors ontologies visually, |
| 198 | +- the mapping editor transforms data from spreadsheets, databases and other sources into instances of the ontology, see [Lift data from tabular data](../../build/lift-data-from-tabular-data-such-as-csv-xslx-or-database-tables/index.md). |
| 199 | + |
| 200 | +An ontology without data stays theory. |
| 201 | +Mapping the sources onto it fills it with life. |
| 202 | + |
| 203 | +## Exercise { #exercise } |
| 204 | + |
| 205 | +Develop a small ontology, either for a domain from daily work or by extending the product domain, for example with suppliers: |
| 206 | + |
| 207 | +1. Write five competency questions. |
| 208 | +2. Describe the domain in a few sentences, and mark the concepts, relations, instances and attributes. |
| 209 | +3. Draw the model. |
| 210 | +4. Formalize it in Turtle, or create it in the Business Knowledge Editor. |
| 211 | +5. Create a few instances, and answer the competency questions with SPARQL. |
| 212 | + |
| 213 | +Compare the result with the products vocabulary of the Product Data Demo, which models suppliers with the class `prod:Supplier` and the property `prod:hasSupplier`. |
0 commit comments