Welcome to the Knowledge Engineering and Semantic Web lecture. So last week, we started talking about OWL. And today, we want to continue some remaining bits and pieces

about the web ontology language. Let's maybe briefly go through what we discussed last week. So OWL builds on top of RDF schema and on RDF. So all OWL ontologies are also RDF files

or can be represented in RDF. Ontologies is a term which already originated from philosophy. So it's well-known for many decades. Actually, one of the first ontology projects I did, I did with the Protestant Church. And they were very excited about using ontologies.

And then it became quite popular in computer science. Increasingly, it started with a definition by Tom Cooper in 1993. But since then, it's increasingly gained more popularity for representing knowledge.

So it's a standard by W3C, which we discussed. There are some shortcomings of RDF and RDF schema, which OWL addresses, especially when you want to represent more complex knowledge. And OWL also builds on description logics.

And there is also this Manchester syntax, which you should maybe be able to read a bit. But this is just another syntax. And everything can be also represented in RDF, in Turtle, for example, or other RDF serializations.

And OWL documents usually have a header with some prefix declarations. You can add some meta information about the ontology, for example, like comments, versioning, imports. There are a number of properties which are added in the OWL standard for versioning, like versioning info, prior version, backward compatibility,

incompatibility, deprecated class, deprecated property, because of course ontologies are evolving. They are not fixed, but they should evolve because the domains, of course, also change.

The conceptualization should be refined. But on the other hand, since it's a shared conceptualization, you should not or try not to break the conceptualization. That's why it's a good practice to try to be backward compatible. So don't redefine classes differently in later versions,

but introduce maybe a new class and then mark the old one as deprecated class, for example. That helps to keep things compatible. So OWL documents are sets of axioms and different syntaxes exist there as well.

But as I said, the RDF syntaxes can be used for all OWL documents, like turtle, for example. And the Manchester syntax is one which is a bit more concise and easier to read and write

and a bit more closer to maybe the logic viewpoint. So then we talked about classes, roles, and individuals. So the terminology maybe is sometimes a bit different. Don't be confused about that. Individuals, you can also call instances. Roles are also called properties,

and they are defined classes and roles in the same way as we have seen that already in RDF schema. We can define domain and ranges. One new addition in OWL is that we distinguish two types of properties, object properties

and data type properties. So object properties are used to establish links and relationships between objects, between individuals or also classes, between resources, basically, while data type properties attach data values or describe an individual with data values.

And of course, domain and range can be used there as well. So the data type properties, they are called in the logic terminology, concrete roles. Data type property, for example, here,

first name is a data type property. The domain is a person, but the range is then a data type, here in that case, a string. And then we can, of course, use these properties or roles to describe instances or individuals, like here in that example, Albert Einstein

with his first name. Then there are different types of relationships between classes, which are here given as an overview. So we can construct new classes out of existing classes. That's something which we could not really do in RDF schema.

So here we can define in OWL then the equivalence of classes, the disjointness of classes, the union of classes, and these are class expressions which are possible in OWL. So equivalent class basically means that two classes are subclasses of each other mutually in both directions.

So here we had this example of publication and publications, which are both, which are equivalent and that's why publications is a subclass of publication and publication is a subclass of publications. That's basically the meaning of equivalent class.

It's basically a shortcut for defining two classes as being mutual subclasses of each other. So subclass of we can use then disjoint with. So this is quite important because by default individuals can belong to several classes at the same time.

Maybe some of you notice from object oriented programming there is this concept of multiple inheritance that you inherit from several classes and the same is possible in OWL. So instances individuals can belong to several classes

and sometimes even implicitly. So you don't have explicitly defined a class to be or an instance, an individual to be an instance of a class but by reasoning, by inference, applying inference rules it becomes apparent that the only interpretation

of your model, of your ontology is that an individual must belong also to a different class and that's why it's also good practice to define classes which must be disjoint as disjoint. And that's what you see here. The class faculty staff is defined to be disjoint

with application. Sounds pretty clear for us, but for a reasoner if it's not explicitly stated, it could be that there are instances which belong to faculty staff and to publication. Yeah, and that's why adding such axioms is a good practice

and then a reasoner can maybe determine some inconsistencies if there is no possibility that an individual can be belong to these disjoint classes.

Then there's this subclass reasoning. So if you have a book, for example as a subclass of publication. So yeah, basically you can imagine classes as sets of instances of individuals, right? So if you have a class person then you have the set of people

which belong to the person class. And similarly, you have a class publication and then you have, for example, books and papers which belong to the publication class. And if they are not defined to be disjoint it could be that a person also becomes a publication

for some reason. For example, if you later add more axioms to your ontology, for example, this all value or some values from public restrictions which we discussed later or last week already then a reasoner might infer new knowledge

and he might infer that some author also is a publication because you maybe made some mistake in the representation, right? So this implicit information has the result that you might do make some mistake.

For example, I can give you an example. There is the schema.org vocabulary, which I've shown you. And there is, for example, the class point of interest and the class point of interest has a phone number attached. And then there are subclasses of point of interest. And so the domain of has phone number

is a point of interest. And then there are some subclasses defined and there is some subclass, for example, mountain which is one specific type of point of interest. And then since the domain of has phone number

is a point of interest, it also includes a mountain. So that in the end means a mountain has a phone number, right? So this is, for example, something where you, which leads a bit to some inconsistency later on

where you figure out, it looks on a superficially your knowledge representation looks fine. You have the class point of interest, you have the class mountain, you defined a phone number for point of interest, but since then mountain is a subclass and then have a mountain having a phone number doesn't really make sense.

And this is what I mean by that this implicit information can result in some unintended consequences. And one unintended consequence can also be that an individual belongs to two classes which should not belong. And that's in order to avoid that,

you can define the classes to be disjoint. Still a reasoner will say that this individual should also be, should not only be a faculty member but it should also be a publication, but it cannot because it's defined as disjoint. So a reasoner will discover an inconsistency

and that helps you to fix your ontology. So that's a bit the idea of defining classes to be disjoint. So, and then we had also role properties for properties, basically properties of properties.

So domain and range, we had an RDF and RDF schema already, but then also transitivity, symmetry, functionality, inverse functionality and these can be expressed also in OWL. Also same as, you can define the two instances,

two individuals are the same. And that's what you use this term OWL same as for. And similarly you can also define the two individuals are different than you use OWL different from. So that's a bit the same as yeah, disjoint but disjoint applies to classes, to sets

while same as and different from applies to individuals, to instances. And here we had this example where there was a contradiction, right? So the contradiction here was we defined

the domain of latitude and longitude to be spatial thing. And then we have defined our latitude and longitude applied that to a company, company XY, yeah.

And that for example would result that company actually becomes a spatial thing. So here you have an example where you use the properties latitude and longitude for company. And since you have previously defined latitude and longitude to have the domain spatial thing,

company becomes a spatial thing, yeah. So company is defined to be an organization but implicitly since you use the properties latitude and longitude, a reason I would infer are since latitude and longitude have to domain spatial thing company XY also must be a spatial thing.

And that's actually an unintended consequence. So a company should not be a spatial thing. A reason I would infer it's a spatial thing, there would be no problem as long as you don't have defined company and office to be disjoint classes, yeah.

So you actually should define company and office to be disjoint because of course a company is something different than the office of a company. And then here in that example you would really find an inconsistency in your ontology.

You would find that there's company XY which is a company, which is an organization. And then by inference, it also is a spatial thing. And since you defined in your ontology both as being disjoint, this would lead to an inconsistency, yeah.

And these inconsistencies, then you can investigate what's the reason for this inconsistency. Here the reason is that you attach the latitude and the longitude directly to company XY. You actually should attach that to office and not to a company. So it should be attached to office XY, yeah.

So you should create another individual office XY and then attach latitude and longitude to office XY and then everything is fine. So then there is a possibility to define classes as enumerations. This is also called nominals.

Basically that you list all the members of the class, all the instances, the individuals which belong to the class. So here in that case, we define the class moon of Mars and we say there are two instances there, Phobos and Deimos. And this is in turtle syntax.

It looks a bit more, yeah, a bit more complex. You define moon of Mars then has an equivalent class. The equivalent class is an anonymous class, a blank node, which then uses this one off property to define and the list of two things

that those two things belong or basically create this anonymous class. And then since they are equivalent, that means that moons of Mars are exactly those two individuals. So, and then there are these logical class constructors,

intersection of, union of, complement of. They are used to construct complex classes from simpler classes. And we can see, look again at some examples. For example, we define the equivalence of,

the moon of Mars is equivalent to the moons and objects near Mars. So this is an intersection, yeah? Since we have defined classes or you can imagine classes as being sets, you can build intersection of sets. And if you build the intersection of all moons

in the, for example, solar system, there are a lot of moons for different planets. And then the ones, the objects which are near Mars, there might be also other objects near Mars, not only moons, maybe there are some asteroids also, but those which are moons and which are near Mars,

these are the moons of Mars. So we can build new classes from existing classes. Here in that case, the existing classes are the classes of moons and the objects near Mars. Similarly, we can build the union, for example, to define boat as a union of a sailboat and motorboat.

Maybe I translate, so this turtle syntax here, let's maybe translate that as a small exercise to triples. So I hope you see my screen here. I can make it a bit larger, yeah? So this uses, of course, some syntactic sugar.

So we say boat subclass of, and then we have here actually this square brackets indicates a blank node. So we can indicate a blank node, one, two, three, for example, let's translate that into n triples.

So then we have underscore one, two, three, type our class. So now we have represented that. And then we have underscore one, two, three, our union of, and then this in round brackets,

that's the list. Now we have to, I think we missed this part in RDF about lists. So we can look this up in the RDF document and the standard. So this list basically uses this first.

So now we have a union of, and then we have to, again, create an identifier for our list. So six, seven, eight, then underscore six, seven, eight, type RDF lists. Actually, here we have to do full stops

always in the end of the triples. So, and then a list has a first element. So that's written here, like the first element, RDF first. So, and the first element is our sailboat, full stop. And then we have rest.

The list has also a rest, the remaining, basically, list. Now we have to introduce another blank node, underscore three, four, five, for example. And then underscore three, four, five, RDF.

As again, first, and that's now our motorboat, and that is RDF needle. So the empty, an empty list. I think that should be also somewhere here

in the standard, yeah, RDF needle. Needle stands for an empty list. The resource RDF needle is an instance of RDF list that can be used to represent an empty list or a list-like structure, yeah. So this is basically the example from this example here,

this turtle example written down in N triples. So in full triples, yeah. And that's basically, here we have some blank nodes. Yeah, the square brackets and the round brackets indicate blank node identifiers.

I have a question. Sure. Can you go to the symbol code, what you showed us? This one, yeah. Yeah, you created blank node for the rest, okay? But for the first, we didn't need to create also another blank node? No, yeah, the first then indeed is the resource.

Why should we create another blank node there? We actually want to list in the list the sailboats and the motor boats, yeah. That's why the first is always referring to a concrete resource or individual instance, yeah.

The rest, so basically what we do here, the problem is a bit in RDF, we have only triples. We have only subject predicate object, right? A list usually has more as two or more elements, right? And this is not easily possible in RDF to represent members.

And that's why these lists are constructed by first defining a list and then giving the first element of the list and then the rest of the list. And the rest is again, actually here, we could again define that underscore three, four, five,

RDF type, RDF list. So a list is constructed incrementally by always defining the first element of the list and then the rest of the list,

which is again a list, yeah. And this way you can create arbitrary long lists. There was, is actually also another possibility to do this with these underscore properties. So this is an ordered list here and the advantage is here, you really have them ordered,

yeah, you have always the first and the rest and that's why you have an order in the list, yeah. First, second, third, and so on. And also the list is in a way closed because in the end we have these rest RDF nil. So that means the list ends there, yeah.

And there's also this other possibility of defining lists using underscore one, two, three as properties. So three, we actually don't need here in our case. So we could also define this in a way and that's maybe a bit a simpler way

to do it one sailboat and two motor boat, yeah. Underscore six, seven, eight. This is also possible to do it that way, yeah, to basically list the members using these underscore properties in RDF.

Okay, but this is just to show you basically how to translate the syntactic sugar from these examples in the end into RDF triples. In the end, it's always only subject predicate object triples, yeah. That's important. Everything you see here can be translated

in subject predicate object triples. And that's also very important because we have those triple stores. We will also learn in two weeks how we can query them using the Sparkle query language. And if there would be a different, if it would be not only triples,

it would be very complicated to actually run queries on top of RDF knowledge bases. That's why everything in RDF and RDF schema and OWL can be represented in simple subject predicate object statements. Here's also an example of a disjoint union. For example, professor is a subclass

of an anonymous class in that case. And this anonymous class is a disjoint union of active and retired professors. That was disjoint union and then the complement. So here faculty staff is defined

as a subclass of the complement of publications. So the complement of publication is basically everything, all instances, all individuals, which are not publications. And then you define faculty staff as a subclass of that. So this is basically also the same as disjoint,

that faculty staff is disjoint with publication. And we have these role limitations. Like we can define complex classes using constraints on the roles, on the properties. And the first one is all values from.

So here we have one. Let's maybe also translate that. This turtle into n triples. So let me add this here. We have exam as a subclass of, and we have a blank node, underscore one, two, three. So, and this underscore one, two, three

is of RDF type, OWL restriction. So then we have underscore one, two, three is a restriction on the property examiner, full stop. And since we have a semicolon, basically it's the next triple again, starts with one, two, three,

all values from must be from professor. So that's how it would look really in triples. So this all values from restriction here in turtle syntax. And you see there is one square bracket and this one square bracket indicates a blank node.

And this blank node, we can also write out or create a new blank node and then write it out. So we define exam being a subclass of an anonymous class here. So anonymous class because it doesn't have a name really. This anonymous class is a class which is a restriction.

And it's a restriction on the property examiner and all values of this property must be professors. So what does it mean? So this basically selects all individuals which have the property examiner

and where all values of this examiner property are professors. Yeah, and all these instances which will fill this restriction belong to our anonymous class. And when you define exam to be a subclass of it,

yeah, that means basically that for exam always, here's actually a typo, values from. That basically means that for the exams, the same restriction holds since it's a subclass that means for all properties which are applied

for exams, the value of the examiner property must be professors. So shall we maybe introduce this with an example? We can say CASW exam for our lecture

and then we have a property examiner and then we have maybe another property or an RDF type professor. So if we have such an, K-A-S-W, yeah, if we have such an individual defined,

it has a property examiner and the value of examiner is 0.00 hour. And since 0.00 hour is a professor, it fulfills, this individual here fulfills this restriction.

So this would be implicitly then become an exam or actually here in that case, it's, yeah, could become an or let's maybe do it differently. We say, CASW exam, RDF type exam.

So what would we, we could conclude that 0.00 hour must be a professor in that case, yeah.

So the conclusion would be 0.00 hour RDF type professor because otherwise this could not be true. Only if 0.00 hour is a professor, then actually this restriction would be fulfilled.

And since exam is a subclass of this restriction, the restriction must also hold for all instances of exam including then 0.00 hour and that means he must be a professor, yeah. So that's what reasoners do,

this kind of inferencing then. So we can, there is not only all values from but also cardinalities. So we, for example, can define here in that case, exam to be, is a subclass of an anonymous class and this anonymous class is a restriction

also on the property examiner and the max cardinality is two in that case for the property examiner. That means an exam can have maximum two examiners. What would happen if we have three examiners? So let's say we have here,

Marcus Stocker, Maria Vidal, for example. What do you think in that case? Would there be a problem? Can we actually... We need to increase the maximum cardinality to three? Yeah, that would be one possibility, but let me, let me maybe,

I can do a small questionnaire here for you. Unsistent. The question is, is it inconsistent? Okay, let's try if that works. So now you can basically vote.

You should be able to vote. Is this inconsistent or is it consistent? The question is, is there a model in the real world where this here is basically true given the cardinality restriction?

So you should be able to vote now. So far only two people voted or three. Do you see the questionnaire? Yes, we saw it. Yeah, we can, we have it. But most didn't get the answer.

Okay, most of you say it's inconsistent and this is unfortunately wrong because it can be. The question is, is there a model in the real world which makes it consistent? And it depends a bit how you define the people,

Zurin Awa, Markus Stroker and Maria Vidal, yeah? The question is, how are they defined? But for example, one model could be that Zurin Awa and Markus Stroker actually are the same. Yeah, so if they are not defined to be different people, they could be the same. And in that case, a reasoner would think,

ah, two of those three must be the same. Yeah, so it would not be by default inconsistent. It becomes inconsistent if we define the individuals to be different, right? So we can say Zurin Awa,

all different from Markus Stroker. So we would have to add Maria Vidal and then a third one. Maria and Markus.

Vidal, yeah? Now they are all defined, we are all defined to be different. And then it would become inconsistent, yeah? Because then two of those examiners could not be the same anymore. That's why this knowledge engineering

and semantic web exam would have three examiners. Then it would not fulfill this cardinality restriction anymore. But since it's a subclass exam, we have a problem, right? But only in that case, there is a problem. So what you can see from this example is that in all reason,

always tries to find a model of the world which fulfills the ontology. So, and there are different things. There is this open world assumption and the unique names assumption. So the open world assumption says what is not stated explicitly, we don't know.

Can be true, can be false. So if it's not stated that Zurin Awa, Markus Stroker, Maria Vidal are different from each other, maybe some of them are actually the same, yeah? So that's the open world assumption. And also the unique names assumption here, just that we have different identifiers for things,

it doesn't mean that they are different in reality, yeah? We discussed that when we talked about RDF and identifiers, there are actually always several identifiers for the same person. For example, you can use your text ID, you can use your email address, your passport number.

Some people even have several passports, right? If you have several passports and you use the passport number as an identifier, unique identifier, then you have several identifiers for the same person. That's why just that we have different identifiers, we cannot really be sure that these are also really different individuals. And that's a very important thing to keep in mind

with RDF and Awa and ontologies and reasoning that a reasoner tries to find a model which you have your ontology, you have your data, your instances, your individuals, and then a reasoner will try to find an interpretation of this model or one model of it, which can make sense.

And sometimes this can mean that some individuals are the same as long as it's not explicitly stated, yeah? And that's quite important to keep in mind that reasoners, inference engines,

that they come to conclusions which might be unintended for you, but then you have to investigate what's the problem and then you can figure out what the problem is. Good, we had this cardinality restrictions, then we have also has value, has value restrictions.

So that means not all values of the property have to be long or one property has a certain value. So let's maybe look at this example here. Let's say exam hour, equivalent class. So we translate that and let's use some one, two, three,

some new blank node identifier, underscore one, two, three, RDF type, all restriction, underscore one, two, three, on property examiner, then we have one, two, three,

has value, okay, now you use hour, yeah. That would be the translation into a triples. We resolve basically the blank node here. From this square bracket and we define a new class exam

hour or hour exam, maybe should be this way. Of course, it doesn't really matter how you name your classes. And then it's equivalent to a new anonymous class.

And this anonymous class is of type all restriction. It's a restriction on the property examiner and it should has a value hour. So here, this is now other than all values from,

all values from are referring to a class. All values from this property must belong to a certain class. Here, it just says it has to have at least one value of this property should point to hour. And then question is, would this instance here belong to this class?

Yes, it would because it has KASW exam as one property which points to, okay, here it's zero and hour. We would have to change that. Of course, they have to really match, yeah, like that. So in that case, this individual which we defined here

would belong to this class. And since it's equivalent class, so now we didn't use subclass, but we use equivalent class. That means it really also belongs to our exam. So then actually it can be inferred that,

so I don't know, I indicated maybe in that way that KASW exam is of type hour exam. Using such restriction, we can infer also, it's basically you can understand this a bit

or interpret this a bit like a query, yeah? You run a query on your knowledge base, you look for all instances which have the property examiner and which have the value, at least one value for this property must be, should be zero and hour. And then these instances which you find in your knowledge base,

you add to the class hour exam. And that's a bit how you can picture this type or the restrictions yourself. They are like queries on your knowledge base and then the results which fit to this restriction, they are added to the class if it's equivalent class. Of course, if you have here instead of equivalent class,

if you have subclass, then it would not work. Then still those instances would be added to our anonymous class. But since an instance of a superclass doesn't have to be the instance of a subclass, we cannot be really sure

that it also belongs to our exam. So in that case, if you have your subclass off, we could not make this inference, right? So this triple KASW exam RDF type hour exam could not be made in that case when there are subclass off, only when we have here equivalent class.

Because then the instances of our anonymous class must be also instances of the defined class hour exam. So domain and range, I think is clear. We don't have to talk about that again. Yeah, and there was this, we can model the domain D of a property

without using domain that can be also done with the restriction. Okay, then we had negative facts in our tool. It becomes possible to assert negative property assertions.

Yeah, so here this looks, is again a bit complicated in RDF. We have to say the source individual is Bill, the assertion property is has wife and the target individual is Mary. And that basically means that Bill has wife Mary

is not true, yeah? So that this statement, Bill has wife Mary is not a part of the knowledge base. So that becomes possible in our two negative facts. So there are male and female persons and people have names. So we define here male person as subclass of person,

female person as a subclass of person, has name is a data type property. Yeah, because the name is usually a string. The domain is person and the range is string. So that makes sense.

And then of course, since the domain is applied to person, it can also be used or applied to the subclasses of person which are male person and female person. Yeah, since all instances of male person and instances of female person are also instances of person, of course this domain definition then also applies to the subclasses.

So, and then we have here some individuals, John and Jill, and we defined John with his name as a male person and Jill with her name as a female person. We didn't need also to add disjoint

between male person and female person? Yes, that would be better, exactly, yeah. Yeah, so in reality, of course, you would have to add a lot of disjoint and like it's not always done actually in ontologies.

So you just often ontologies are maybe also not used so much for reasoning. They are just used for describing data. And if you don't do reasoning, yeah, and you can of course use ontologies in two different ways.

You can use them a bit like a database schema and that's what often actually happens in reality. Ontologies are more used like database schemas, yeah. Classes are a bit similar to tables and like a database tables and properties or roles are similar to columns in the tables.

So that's why often ontologies are more used from this kind of database perspective and then they don't contain all these logical axioms. And if as long as you don't use reasoning and your ontologies are not super complex, then maybe there is not such a big problem.

But once the ontologies become more complex and then you also want to apply reasoners, then of course it's important to add these logical axioms because otherwise you would come to inconsistencies. If you use ontologies more as a data schema, data representation schema,

then it's basically your task as an ontology or knowledge engineer to take care of inconsistencies, yeah, to make sure that there are no inconsistencies. Once you add more logical axioms and you use reasoners,

then the reasoners can support you in identifying inconsistencies. But that's a bit depending on how you use ontologies. And I would say in most of the cases, ontologies are more used as a data description, data schema, yeah. And then often these,

also this OWL axioms, which I've shown you like these restrictions, they are rarely used in normal ontologies. In some they are used, but these are, for example, biomedical or in specific domains. I would say maybe 70, 80% of the ontologies

are rather shallow descriptions of data descriptions, data schemas, and then there are few in the life sciences which also add a lot of these logical axioms and are more complex. So then we have this different versions of OWL.

There was OWL1 and then OWL2 in 2009. And in OWL2, it adds these profiles and some new expressivity. OWL2-Fool, and why are these profiles be used?

Because reasoning can be very expensive in terms of resource intensive. So what I showed you, this RDFS rules, that's relatively simple to process RDF schema rules. We had this RDF schema rules,

and they can be just implemented as inferencing. That simple in OWL, it gets much more complicated and reasoners need a lot of memory and a lot of computing power to actually do this reasoning on top of OWL ontologies.

And that's why there are these different flavors introduced in OWL-Fool. You can do everything, but then the reasoning will be very slow, especially when you have large, very large ontologies. As long as your ontology is small, if you only have 100 classes or 200, 500,

it's not a problem, but there are some knowledge bases which have thousands or even millions of individuals. And then this reasoning can be really complicated and resource intensive. And that's why in OWL-2, there are different profiles added. So in addition to OWL-Fool,

there are three of these profiles, OWL-QL, OWL-EL and OWL-RL. And the design principle for the profiles is that our two sub languages are identified that are still implementable in polynomial time,

polynomial time is it doesn't grow exponentially with the number of instances or class definitions. And that's why this polynomial time is something which is computationally still tractable.

And that's why these subsets or sub languages of OWL are introduced. In general, they disallow negation and disjunction because that complicates reasoning and is rarely needed. Yeah, negation and disjunction creates problems.

And this is disallowed in these sub languages of OWL-2. So OWL-QL stands for query language. It's based on the allied family of description logics. There's a whole also research area. It's called description logics, which are the logical foundation

for OWL and for ontologies. And this QL is designed for query answering using SQL reviting on top of relational databases. So if you have a relational database, you can translate or map the schema of your relational database to an ontology.

And then when you have some queries on the ontology, you can translate them into SQL queries of the underlying relational database. And that's possible with the OWL-QL sub language. So subclasses can only be class names

or existentials with unrestricted fillers. So it basically means it cannot be class names, means it cannot be these kind of restrictions. These restrictions are usually anonymous classes, unnamed classes, they are defined by as a restriction. So that's then here disallowed for OWL-QL.

Superclasses can be class names, existentials or conjunctions with superclass fillers or negations with superclass filler. So that's what is possible in OWL-QL. And here are some examples.

So fish is a subclass of animal. Here you see this description logic syntax. So that means subclass, fish, subclass of animal is allowed or also this existential quantification. So this has value restriction here.

That's a description logic syntax for a has value restriction. The has value restriction on the property has house. And this T here is the top level concept. So we basically select the instances, the individuals

which have the property has house and it has some value or it has a value something. And that is a subclass of landlord. So this is also allowed. Let's maybe translate that into, as a small exercise here, into RDF.

So we have house, a landlord. So let's do that here, has house. So we have to define a restriction. So we do this one, two, three, RDF type, OWL, restriction, restriction, yeah.

Underscore one, two, three, OWL on property, has house and underscore one, two, three, has value all thing.

And then we had is a subclass of landlord. So underscore, or we can do it here, underscore one, two, three, subclass of landlord.

Yeah, so this is basically allowed which has value restriction with an unrestricted filler. That's why OWL thing here, that was I think the term which we are super subclasses can be class names

or existentials with unrestricted filler. And that's exactly what we have here. Existential is a has value restriction. So it must exist. It should exist. And an unrestricted filler means we cannot restrict it to something.

It can be anything. That's why OWL thing, yeah, yeah. So this is basically an OWLQL allowed. And then we see here what is forbidden. So here these two things, a bit more complex ones are forbidden. I haven't introduced these description logic syntax to use

so maybe, yeah, we skipped that for today. Maybe we come back to that later on. So also forbidden is equality. This junction is forbidden, yeah, where you have basically disjoint union.

For example, this here would be a disjoint union of ebook and printed book. It's also forbidden in OWLQL. Universals, this is this all values from restriction here. So all values from killed. Human, that would be a murder, yeah.

So this is also not allowed. Self is not allowed. Somebody who loves himself is a narcissistic person. It's just an example, but everything which uses this self. And then also cardinalities are not allowed in OWLQL.

And also keys and property chains and transitive properties. So a lot of things which are then possible in OWL2 are here not allowed in OWLQL. Also nominals, also basically defining classes as a set of individuals.

So here, for example, the class birthday. My birthday guess is defined as Bill, John and Mary. As a set of these three individuals. So this is also not allowed in OWLQL. And functional properties,

so properties which only have one value, for example, has husband, also not allowed in OWLQL. So that's a very simple subset, sub language of OWL. And then there is OWL-EL, which stands for exist.

So this focuses on terminological expressivity used for lightweight ontologies. Allows existential but not universal quantification. No inverse symmetric properties, no disjunctions or negations are allowed there. So, and here are also some examples.

What is allowed? So we can use this existential. This is this has value. Restriction in conjunction with the subclass and another has value. Yeah, here's also has value. Similarly here. Yeah, and this is a property chain down here.

We haven't talked about that. Basically a combination of has parent and has parent is a sub property of has grandparent. Yeah, if you have a chain of two properties has parent, that's a property chain. And then you can define it as a sub property of has grandparent.

So things like that can be expressed in OWL-EL. And then there is OWL-RL, a rule language, which allows subclass axioms as rule-like implications with head and body. So that's the last sub language. But maybe let's not go so much into detail here.

I wanted to show you some example tool how we can create ontologies. And there is the Protege Ontology Editor. So that's a software which you can download and install. It's implemented in Java. Here you see a screenshot and you can basically create ontologies there.

So you don't have to write the source code, the RDF, all source code yourself, but you basically have a nice user interface for that. It's developed by Stanford. And here's the URL where you can download it. And I want to show you actually, yeah, some Web Protege Editor, how that works.

So you can use Web Protege and that's what I want to show you now. You can go to webprotege.stanford.edu. And then you can also create a sign up for an account.

I created one already. So once you log in, you have different projects which you created basically different ontologies. Let's maybe select the first one which I created here, Pizza Ontology. And then you have it in the web browser, basically the possibility to create your ontology.

So here in that case, you see you have different tabs. You have a classes tab, a properties tab, individuals tab, comments, changes, history. And let's maybe first look at the classes tab. So we have here on the left, the class hierarchy

and we see there is our thing. That's the superclass of everything. And then we have two subclasses defined, pizza and zutard, and then we can expand pizza. And then we see here Italian pizza and bicepizza.

So maybe I changed that. Once I click on that, I actually see here on the right hand side, the form, and I can fill that out. So let's change it to Italian pizza. And you see it changes right away. And this one to white pizza. Let's translate it to English. So we have these two subclasses here.

And we have two tarts, this we can also change. And we have different types of ingredients like meat, vegetables, and of course, cheese. So, and that's a nice user interface where you can see basically the class hierarchy. So, and then when you edit a class,

a protege generates an IRI for you. You see it generates really an identifier with some arbitrary alphanumeric code here, yeah? That's why it's very important to add these labels. And these are then used to basically show you

on the user interface, the class names and the instances. Then you can add also other properties here, annotations. You see, it suggests there's some auto-suggestion here. For example, there is Skoss. This is another vocabulary or ontology

which defines also a lot of properties which can be used. So for example, Skoss comment, cheese is the most important in pizza.

And then you can also add here the language tag, EN. So it has always this nice auto-suggestion. And of course, you should also here use EN, yeah? Then you have parents. I don't know why it now on the left-hand side didn't update here, cheese.

And I switched to DE, it shows me cheese because I guess somewhere I configured to show German labels. I don't know. And then with parents, you see here that it's, these are basically the super classes, yeah? And you see that here it's ingredient, but I can also attach it to some other class.

So once I start typing, it suggests me the classes which I have already. So I can, of course, could also add it to pizza. And that's exactly what I meant. You can attach one individual to two classes and you see then our class hierarchy updated and now cheese is part, is a subclass of pizza and of ingredient.

Of course, that doesn't make sense. So we delete this one here. And then there are also relationships. So you can define also our properties for the class. I don't know what we could add here. Yeah, doesn't matter for now.

So let's maybe look at the properties. So we can go to the properties tab and here we have object properties, data type properties and annotation properties. And we have a top object property that's always there on top. And then we have a property has two tarts and we can change that to has ingredient.

Did I type that right? Ingredient, like this. And then you see here domain, it can be applied to pizza and range ingredient. So this is, once you type here,

it basically suggests the classes. And you can add and describe your properties. That's a data type property. We have had bucked sides, has baking time and we define this property to be functional. So it can be only used once.

And a range, we define, we apply it to pizza. And as a range, we have an integer value. And then we can also go to the individuals tab and here you see on the left hand, some individuals. So we can go to pizza margarita. And then on the right hand, we see that margarita,

here it actually draws us a nice diagram that it has two ingredients, tomato sauce and pizza key cheese, which are both ingredients. And it's an Italian pizza and a subclass of pizza. We can also look at the changes here. Who did what?

And we can also look at the form. Like if we go to this details, we can then look at a regular form and we see here labels in different languages. So we have it in German and in Russian. And we have relationships and we have here has baking time, five.

You see that it updated. When I changed the property, it also updated immediately here to has baking time. So that's also very convenient that properties are, when you rename it at some place, they are renamed everywhere. Or renaming, we actually just changed the label

because the original label is actually this alphanumeric or the identifier is this alphanumeric value. And then we have ingredients here, pizza queso and tomato sauce. So these are the, and you could add more as another ingredient.

And you could also directly create salami, we actually have already, but you could also directly create a new individual there. Rucola, for example, we could create. Great, named individual named Rucola. So we have edited here and then we see, here it is.

And now we have to attach a type, of course. Rucola is also an ingredient, so we add it to the ingredient class. So that makes it very easy to create these kind of knowledge bases, ontologies.

And now you see it also here in the list of individuals, Rucola. You can also define same as. Yeah, so link it to another individual. Now let's, so you can create a new individual and then it's automatically updated.

You can also switch here to the hierarchy to select only pizzas. And then we have only margarita or the ingredients. We have these four ingredients. And there are different also tabs where you can see comments.

You can also discuss, actually you can, also different people can collaborate here. So this is a collaborative web application. You can also see the changes by entities. So for example, you can select pizza and you see who changed when, what, what has happened there. So the label was changed from vice pizza

to white pizza that was done by me. And you can exactly see who changed what. And here also in the history, we have to complete a history of all changes, especially when you collaborate with different people, work together. That's quite convenient.

Then there's here this button share. So link sharing is enabled. So anyone with the link can edit. So when you have the link here, then everybody can basically work on this pizza ontology or you can also add specific users who can comment,

edit or manage the ontology. Good, so that's basically WebProtege. Protege itself is which you install on your own computer is a bit more complex and allows also to create these class restrictions. That's here in WebProtege, not so easily possible.

But what's also very nice is basically that it creates, for example, then these visual graphs which shows you basically

visually how the relationship between instances, classes is there. Good, so that's what I wanted to show you for today.