Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Semantic Web, Part 3: From Model to Database

...

...

If, for example, you provide a specific property companyName with a domain axiom Company, the reasoner ensures that every individual that uses companyName automatically becomes a member of the Company class - without this requiring an explicit class assignment Ă  la

dnp:Company_EbnerVerlag rdf:type dnp:Company

the The desired and helpful side of the inference.

If, on the other hand, you assign a generic property name with a domain axiom Product, all Individuals that use this property also automatically become members of the Product class. Consequently, an individual individuals who uses the name property would also become a Product object, which is logically correct but semantically nonsensical.

...

dnp:Invoice_A dnp:hasCustomer dnp:Customer_B

The object property hasCustomer links invoice A with customer B. To create such a property, click on the Object properties tab at the bottom of the Protégé UI. Like the data properties, all object properties in OWL are derived from owl:topObjectProperty. Select owl:topObjectProperty and click the Add sub property button. Protégé prompts you to enter the name of the object property (Fig. 1).

...

To create such a property, click on the Object properties tab at the bottom of the Protégé UI. Like data properties, all object properties in OWL are derived from owl:topObjectProperty. Select owl:topObjectProperty and click the Add sub property button. Protégé will prompt you to enter the name of the object property.

Classes - Classification vs. Schemas

...

Classes - Classification vs. Schemas

The next step after creating the taxonomy, data and object properties is to specify the individual classes with their respective properties and constraints. Previously, we looked at how domain and range axioms are used in ontologies to automatically classify individuals, i.e. to automatically group individuals into members of one or more classes: implicit single or multiple classification.

Coming from the OOP world, however, one is tempted to regard the classes in an ontology not as groups of individuals, but as schemas, as a predefined framework of properties and their constraints, which the instances of the classes must adhere to. In general, however, semantic databases are initially schema-less, which means that each individual can have any properties. Individuals also do not necessarily have to have one or even several classifications, neither explicit ones using rdf:type nor implicit ones using domain and range axioms.

What is ideal for mapping complex real environments, environments and knowledge domains due to its openness and freedom may seem impractical compared to the tables and collections from the SQL and NoSQL world, as ERP systems, for example, usually have a large number of similar instances such as customers, products or invoices. usually have a large number of similar instances such as customers, products or invoices, all of which are subject to their own schemas. However, OWL also offers mechanisms for defining schemas, albeit from a slightly different perspective than perhaps expected.

...

While traditional schemas say, for example, "A person has a name", ontologies express this as "A person is a subclass of all things that have a name". This expression comes from Description Logic (DL), sounds a bit confusing, but basically means the same thing. Since there is no concrete class Thing with a name, it is technically the inheritance of a so-called anonymous class. Because multiple inheritance is an integral part of OWL, defining multiple properties per class according to this concept is not only not a problem, but also an intended and established modeling practice.

Figure 2 shows the Product class with its data properties. In accordance with the DL/OWL conventions mentioned, these are not to be found in the properties, but in the SubClass Of area.

...

The data types are specified as so-called data restrictions (Fig. 3), a kind of type and value constraints. The information on the cardinality (the permitted number) of properties is an additional feature of OWL. Two aspects are important here:

...

The classes with their restrictions have been created, now it is the turn of the individuals, the actual data records in the ontology. In Protégé, switch to the Individuals by class tab and to the Direct Instances area at the bottom left. It shows all existing individuals of the class selected above, in Figure 4 using the example of Product.

...

Note that in the dotnetpro sample ontology for this article [5](https://github.com/innotrade/enapso-dotnetpro ), all products are labeled and the Protégé renderer shows the labels in the screenshot. If the mouse pointer hovers over an article, the tooltip shows its complete IRI.

In contrast to classes and properties, which are unique per ontology, the IRI assignment for a large number of individuals is, as expected, different. While classes and properties are usually given unique and human-readable identifiers, the uniqueness of the IRI per resource would no longer be guaranteed if there were several individuals with possibly the same name. An IRI dnp:AlexanderSchulze would inevitably lead to conflicts with an individual of the same name in the database.

...

To create a new individual, click on the Add button above the list and then on New Entity Options. Protégé offers a wizard that can be used to configure the assignment of the IRI (Figure 5).

...

Next, select the Autogenerated ID option and enter the desired prefix for the IRI below, in this case Product_. As soon as you enter a name for the new individual (Fig. 6), Protégé creates a new UUID with every letter you type and appends it to the selected prefix.

...

To create an annotation for an entity, select the entity on the left-hand side of the Protégé UI. Its annotations then appear on the right in the tab of the same name. Figure 7 shows an example of the data property purchasePrice, for which two label and two comment annotations have already been created in German and English.

...

To create a new annotation, click the Add button; to change an existing one, use the Edit button behind the annotation in question. Protégé prompts you to enter the type of annotation and its value. Figure 8 shows the entry of documentation in English for the purchasePrice property in the form of a comment annotation.

...

To configure the renderer, select the Renderer tab under Preferences in the Protégé main menu and then the Render by annotation property option. Figure 9 shows the settings dialog.

...

By clicking on Configure ... you can then specify which annotation type is to be used to display the interface and which language is to be used (Fig. 10).

...

So lĂ€sst sich dann die Ontologie leicht auf die gewĂŒnschte Sprache „umstellen“, was die Wartung von Ontologien auch kulturĂŒbergreifend sehr einfach macht. Bild 11 zeigt exemplarisch, wie die Taxonomie nun in Deutsch gerendert wird.

...

Da die meisten Bezeichner fĂŒr Klassen und Eigenschaften in Ihrer Ontologie wahrscheinlich ohnehin in Englisch erfasst werden, mag der Einsatz und die Wartung von Labels fĂŒr jede EntitĂ€t zunĂ€chst umstĂ€ndlich erscheinen. SpĂ€testens aber, wenn Sie eine Vielzahl an Individuals in ProtĂ©gĂ© verwalten, werden Sie die Labels schnell zu schĂ€tzen wissen. Denken Sie etwa an IRIs mit UUIDs fĂŒr Produkte wie das folgendeThe ontology can then be easily "converted" to the desired language, which also makes it very easy to maintain ontologies across cultures. Figure 11 shows an example of how the taxonomy is now rendered in German.

...

Since most of the identifiers for classes and properties in your ontology are probably recorded in English anyway, the use and maintenance of labels for each entity may seem cumbersome at first. However, if you manage a large number of individuals in Protégé, you will quickly come to appreciate the labels. Think of IRIs with UUIDs for products like the following:

Product_c2318c23_2db8_4c8b_9dbf_cd20970d7723

...

What is still done manually in Protégé can easily be automated in applications. A good practice is to define a template for each class, on the basis of which the labels are automatically composed of certain fields of the respective Individuals, for a product, for example, from the fields productCode and productName. More on this in a later article on programming with ontologies and semantic graph databases.

...

To conclude this article, let's take a look at how the models created in Protégé can be exported for use in W3C-compliant graph databases. To do this, it can simply be saved from Protégé in one of the standard formats offered, such as RDF/XML, Turtle or JSON-LD. To do this, simply select the menu item File | Save As and select the desired format.

...

The next article will show you how to set up and operate a semantic graph database, as well as how to conveniently manage data and knowledge in it and make it available for applications. So stay tuned!

References

[1] Alexander Schulze, Working with Knowledge Instead of Data, Semantic Web Part 1, dotnetpro 4/2020, page 78 ff., http://www.dotnetpro.de/A2004Semantik
[2] Alexander Schulze, The Model Comes First, Semantic Web Part 2, dotnetpro 5/2020, page 96 ff., http://www.dotnetpro.de/A2005Semantik

...