• Last verification: 20220909
• Tools required for this lab:
  • Protégé Desktop 5
  • OOPS! (OntOlogy Pitfall Scanner!) (web service)

• OWL References for Humans @Cambridge Semantics

During this lab we will continue the development of the ontology started in the previous classes.
During the previous lab you did a lot of conceptual work – you thought about the purpose of an ontology, its scope and basic concepts.
Now, we will focus on the more technical aspects, introducing selected constructs of the OWL language.

NOTES:

1. As previously, the lab is divided into several sections. Each of them should take approx. 10 minutes!
2. The following tasks will sometimes involve specific situations. Try to implement them analogously in your knowledge graph to best understand the particular aspects.
3. The key classes are:
   • RiversideBandMusicCD (in Primitive class hierarchy section),
   • BaroqueOrganMusicCD (in Properties and Restrictions section),
   • GuitarMusicCD (in Defined Classes section),
   • ACapellaMusic (in Union in OWL section),
   • ACapellaMixMusicCD (in Universal Restriction and Open World Assumption section).
4. The Build your first ontology tutorial studied in previous classes may be useful as a reference.

Let's start!

1. Download your ontology from WebProtégé
   1. Open the projects list: https://webprotege.stanford.edu/#projects/list
   2. From hamburger menu (on the right) select Download
2. Download and start Protégé Desktop 5
3. Load your ontology in Protégé Desktop: File → Open…
4. You can change the prefix for your ontology using: File → Preferences → New entities → Entry IRI, e.g. https://your-name/game-of-thrones.
   • This will be a prefix for all concepts/relations/individuals that we will define in our ontology.
   • This will not change the existing URIs (generated, e.g., by WebProtégé)
5. You can also specify URI for your ontology (ontology is abstract thing in universe we describe, so it also has URI ;) ) using: Refactor → Change ontology IRI… (it CAN be the prefix, e.g. https://your-name/game-of-thrones)

1. Do you have a simple hierarchy of classes and subclasses in your model? If not, complete it now!
   • Use Classes → Class hierarchy tab.
   • In OWL, it always starts with owl:Thing as a root node.
     
   • New subclasses can be added using the Add subclass button on the Class hierarchy tab or by specifying the superclass in SubClass of field in Description panel.
     
2. Create a class that is a subclass of several classes. In media ontology, we declare the RiversideBandMusicCD class (Riverside) as a subclass of BandMusicCD, PolishMusicCD and ProgressiveRockMusicCD ( create the class once, then choose the class, click on the SubClass of button in the class description, and choose appropriate classes from Class hierarchy tab).
   
3. You should now have a small hierarchy of classes.

1. To make sure a Book cannot be a MusicCD at the same time, add disjoints into your primitive tree.
2. Select one of your top level concepts (e.g., Book)
3. Select Make primitive siblings disjoint in the Edit Menu
4. Repeat this where appropriate, for each level of your ontology, selecting a class and making all of its siblings disjoint.
   
5. In Reasoner menu choose HermiT. Start the reasoner. Once your reasoner is running, periodically classify your ontology by pressing the Synchronize reasoner button in the Reasoner menu. Inferred hierarchy can be seen in “Class hierarchy (inferred)” tab:
   
   • If you get inconsistencies (some classes will become red in the hierarchy), see what is wrong with Explain inference button (question mark in Description tab; see picture in Defined Classes section below) and repair the ontology.

In order to describe our classes we need properties, which are used to relate members of a class. We then add restrictions on the class to state logically how these properties are used.
At this stage we are creating Primitive Classes, which only have necessary conditions (in this case, restrictions) on them –- these are conditions that must be satisfied by all members of this class.

1. During this exercise, we will use class hierarchy as shown in the picture:
   
   • The important thing is that we have a class (MusicInstrument) and a set of its subclasses.
   • We will also define another hierarchies, which will be related to the one in the figure (with Artist/MusicCD as a superclass).
   • In your ontology, these hierarchies can be anything, e.g., different areas and the associated hierarchy of rulers or classes of wizards and the associated hierarchy of schools of magic.
2. Step 1: Create Properties
   1. Select the Object Properties tab
   2. Create a new Object Property, containsMusicPerformedBy
      
   3. Create 2 more properties: containsMusic and containsMusicPerformedOn
3. Step 2: Create restrictions
   1. Select the Classes Tab
   2. Select the MusicCD class
   3. In the right panel for this class, select SubClass of (click the circle with + to add new superclass), then choose Object restriction creator tab
   4. In the left window choose containsMusicPerformedBy and in the right choose the Artist class. Make sure that Restriction Type is set to Some (existential). This means that for every MusicCD there exist an artist who performs the music in this MusicCD.
      
4. Step 3: Define a BaroqueOrganMusicCD class
   1. Create a new subclass of MusicCD: BaroqueOrganMusicCD
   2. Select BaroqueOrganMusicCD (note the superclass inherited from the MusicCD)
      
   3. Select SubClass of → Object restriction creator
   4. Using Existential restriction choose containsMusicPerformedOn in the left window and OrganInstrument in the class hierarchy in the right window. Set another restriction saying that BaroqueOrganMusicCD - containsMusic - BaroqueMusicGenre. Eventually you should have a primitive class defined as follows:
      
      
5. Create a class JimiHendrixMusicCD as a subclass of the MusicCD, define that it contains music performed on an electric guitar.
6. Create some other kinds of MusicCD, books or movies (if you haven't exceeded your 10 minutes/section yet)

Creating a Defined Class is similar to creating a primitive class (as in previous step), but a defined class has one or more Necessary & Sufficient Condition. Classes can easily be migrated between primitive and defined.

1. In this exercise, we wish to model the statement: “Any MusicCD that contains music played on any kind of guitar is a GuitarMusicCD”.
   • What would an analogous statement look like for your ontology? Maybe “Any person who practices fire magic is a fire mage” or “Any person who rules a kingdom is a king”?
2. Create a new subclass of MusicCD called GuitarMusicCD. In general, defined classes are not disjoint from their siblings
3. Create a restriction on GuitarMusicCD to state that it contains music performed on guitar.
4. Select both conditions (the new restriction and the superclass, MusicCD) and in the context menu choose Convert selected rows to defined class.
   
5. They should move to the Equivalent to section and the class icon (see class hierarchy) should change to contain an equivalence symbol. You can also create restrictions under this heading automatically by pressing the circle with + next to Equivalent to.
   The result should be as below:
   
6. Classify your ontology (Synchronize the reasoner) and check the Class hierarchy (inferred) to see what has been classified under the new class.
7. All MusicCDs that are set to contain music performed on any kind of guitar should now be subclasses of GuitarMusicCD.
   
   • Click on the JimiHendrixMusicCD which should be classified as a GuitarMusicCD. Choose Explain inference button (with question mark) and analyze the inference the reasoner did to classify the subclass relationship.
   • This option may be unavailable if you use a reasoner older than HermiT 1.3.4
     
     
8. If you have time, create several other defined classes and classify each time to see if their definitions are correct.

In order to define an ACappellaMusicCD, we are going to model the idea of a music performed without instruments. This class is going to be covered by all of the Music that are not InstrumentalMusic. GregorianChant, JewishCantillation, MuslimAnaseheed, etc. are all to be classified as ACapellaMusic.

1. Create a Music class and the following subclasses of the Music: GregorianChant, JewishCantillation, MuslimAnaseheed.
2. Create a new subclass of Music called ACapellaMusic
3. Click on the Equivalent to add button
4. Select the Class expression editor
5. In the expression editor that appears type a list of the Music you would like to be considered ACapella, separated by the union symbol (lowercase “or”)
   
6. Click OK to accept the changes. This can only be done when the expression is correct (e.g., the class names are valid)
7. Classify your ontology –- check that all the expected Music classes are now subsumed by ACapellaMusic.
   

To state that members of a class can only have a specific relationship with individuals from a specific class we use a Universal (AllValuesFrom) restriction. We need to model the fact that:
Any MusicCD that only has music from ACapellaMusic is a ACapellaMusicCD

1. Create a new subclass of MusicCD called ACapellaMusicCD
2. (With the Add button in SubClass of) create an Only (universal) restriction on this class along the containsMusic property with a filler of ACapellaMusic.
   
3. Convert this class into a defined class by selecting the conditions and choosing Convert selected rows to defined class
4. Create a ACapellaMixMusicCD as a subclass of the MusicCD.
5. Add restrictions as in the picture: the CD should contain some GregorianChant, JewishCantillation and some MuslimAnasheed music.
   
6. Classify your ontology.
7. What happens? Do you get the expected results? Is the ACapellaMixMusicCD classified as an ACapellaMusicCD?

Why the ACapellaMixMusicCD wasn't classified as a ACapellaMusicCD, although it has only ACapellaMusic on it?
Because reasoning in OWL-DL is based on the Open World Assumption:

• Non-existence cannot be assumed, it has to be stated explicitly
• CD could have additional kinds of music on it
• Definitions in OWL-DL need closure axiom (to explicitly say class has only the referred restrictions)

Therefore, we need to close our MusicCD descriptions in order for them to classify correctly.

1. Select the ACapellaMixMusicCD
2. Create a new Only (universal) restriction along the containsMusic property. The filler will be a union of all of the music kinds on the CD – ie the union should match all of the music kinds of the existing Some (existential) restrictions using the contains property. Select Add SubClass of button, then Class expression editor and type the following:
   
3. Classify your ontology to check if this class classifies under ACapellaMusicCD.

Data Properties are relations that connect objects and literals.
As a range, you can specify any datatype (most often we use the XSD Datatypes; you have seen them in RDF: Datatypes section of Modeling with RDF and RDFS lab.
Setting a domain on a property may lead to unexpected classifier results if the property is misused (e.g., if the domain has been over-constrained; or we use the property dedicated to other class). We will explore this further in this exercise.

1. Create a publishedIn data property in the Data Properties tab.
2. Set the property's domain to MusicCD, range to dateTime (or other appropriate datatype if dateTime isn't available), set the property as “functional”
   
3. Go to the Entities tab and add a new existential restriction for the class Book saying that it has to be published somewhen (yes, we will use the property that was defined for MusicCD to see if it explodes )
   
4. Run the reasoner: what happens? why?
   
5. Remove the disjoint axioms and run the reasoner again. What happens now?
   
6. Solve the problem so both MusicCDs and Books can be published in the ontology.

1. Finally, we will check our ontology against the most common pitfalls. We can do this using the OOPS! (OntOlogy Pitfall Scanner!).
   1. Export the ontology to RDF/XML format (used by OOPS!): File → Save as → RDF/XML
   2. Paste your RDF/XML file in the OOPS! and click Scanner by RDF
   3. Fix your ontology accordingly to the guidelines.
      • Note: as we are learning how to develop ontologies, there is no need to fix all the issues. Correct the most important errors and see what else should be fixed in ready-to-publish ontology (e.g., Missing annotations or No license declared may be omitted).
2. Save the final version of the ontology in a safe place! We will use it during the next two labs.