This is the second article in our series that expands the code example from Chapter 5 of Semantic Web Programming to cover the semantics of OWL 2. This article covers property chains. The code can be downloaded from here (zip, 7z, tar.gz) and includes an Eclipse project with all required dependencies.

This article focuses on the semantics of property chains and how they are interpreted and applied in a reasoner that supports most of OWL 2 semantics (Pellet 2.0 RC6 – see the Pellet documentation for a full list of the semantics supported in each release candidate).

As I said in the first article, for a more in-depth exploration of OWL and Semantic Web, feel free to reference the book as needed or buy a copy so you can learn about the cool stuff in this article and more. Click the link below to read the rest of the article…

Recall from Chapter 4 in the book that property chains are a way to define a property in terms of a chain of object properties that connect resources. One of the most common examples of a property that is defined in terms of a property chain is the hasUncle relationship, which is our first example and is defined in OWL below:

ex:Ryan rdf:type ex:Person;
        ex:hasParent ex:Jean.
ex:Jean rdf:type ex:Person;
        ex:hasBrother ex:Doug.
ex:Doug rdf:type ex:Person.

ex:hasUncle rdf:type owl:ObjectProperty.
ex:hasParent rdf:type owl:ObjectProperty.
ex:hasBrother rdf:type owl:ObjectProperty.

[] rdfs:subPropertyOf ex:hasUncle;
   owl:propertyChain (
     ex:hasParent
     ex:hasBrother
     ).

The excerpt above is in the file pc_1.ttl. As you can see, we’ve defined that there exists a sub-property of ex:hasUncle that is the property chain consisting of ex:hasParent and ex:hasBrother. This means that the any time the property chain exists, the super-property (ex:hasUncle) exists. More precisely stated: if A ex:hasParent B and B ex:hasBrother C then A ex:hasUncle C. Note that I didn’t say if and only if. The implication only goes in the one direction. The existence of a statement A ex:hasUncle B alone does not imply anything in this context. In OWL 2 you can’t make a property chain an equivalent-property or a super-property of another property.  Despite these limitations, we will soon see that property chains enable the definition of properties that cannot be defined in any other way.

Executing the code in the accompanying project with the input file pc_1.ttl (input parameters: test/pc_1.ttl TTL output1.txt owl) produces the following output:

Individual: Doug
  type : http://example.org#Person
  type : http://www.w3.org/2002/07/owl#Thing
  sameAs : http://example.org#Doug

Individual: Ryan
  type : http://example.org#Person
  type : http://www.w3.org/2002/07/owl#Thing
  sameAs : http://example.org#Ryan
  hasUncle : http://example.org#Doug
  hasParent : http://example.org#Jean

Individual: Jean
  type : http://example.org#Person
  type : http://www.w3.org/2002/07/owl#Thing
  sameAs : http://example.org#Jean
  hasBrother : http://example.org#Doug

As you can see, Pellet correctly infers that Ryan hasUncle Doug. All we said in the input file was (ex:Ryan ex:hasParent ex:Jean) and (ex:Jean ex:hasBrother ex:Doug). This chain of relationships combined with the property chain definition implied the existence of the statement (ex:Ryan ex:hasUncle ex:Doug). As an exercise for yourself, try defining the ex:hasAunt relationship and give ex:Jean a sister.

This was a relatively simple example, so let’s explore some more interesting applications of property chains. For the first example, consider a trust management system in which a user is a trusted user if he or she is trusted by a trusted user. One way to express this concept is to say that the property trusts is transitive.  That way, if A trusts B and B trusts C, A will trust C. The following RDF captures these concepts (from pc_2.ttl):

ex:Person rdf:type owl:Class.
ex:trusts rdf:type owl:ObjectProperty;
          rdf:type owl:TransitiveProperty.

ex:Ryan rdf:type ex:Person;
        ex:trusts ex:John.
ex:John rdf:type ex:Person;
        ex:trusts ex:Matt;
        ex:trusts ex:Ryan.
ex:Matt rdf:type ex:Person;
        ex:trusts ex:Andrew.
ex:Andrew rdf:type ex:Person;
          ex:trusts ex:Mike.
ex:Mike rdf:type ex:Person.

Focus on ex:Ryan. As the excerpt specifies, Ryan trusts John, who trusts Matt. Matt trusts Andrew, and Andrew trusts Mike. Apparently Mike doesn’t trust anyone. Running this example produces the following output (only the statements about Ryan are included):

Individual: Ryan
  type : http://example.org#Person
  type : http://www.w3.org/2002/07/owl#Thing
  sameAs : http://example.org#Ryan
  trusts : http://example.org#Andrew
  trusts : http://example.org#John
  trusts : http://example.org#Ryan
  trusts : http://example.org#Mike
  trusts : http://example.org#Matt

As you can see, Pellet entails that Ryan trusts everyone. While this is logically correct given our ontology, it isn’t really practical to chain a relationship such as trusts in this manner. This illustrates the potential limitation to this approach using transitivity – there is no way to constrain how far the transitivity is applied. In other words, Ryan trusts John, and may be comfortable trusting someone John trusts. But that trust will likely diminish as the relationship becomes less and less direct. Does Ryan really trust Mike? After all, it took a chain of Ryan trusts John trusts Matt trusts Andrew trusts Mike in order to entail the fact that Ryan trusts Mike. That’s quite a lot of indirection. Let’s see if we can use property chains to introduce some finer grain control over this situation.

As shown below, in pc_3.ttl we define a new property ex:indirectlyTrusts as the super-property of the property chain of two ex:trusts relationships.

ex:Person rdf:type owl:Class.
ex:trusts rdf:type owl:ObjectProperty.
ex:indirectlyTrusts rdf:type owl:ObjectProperty.

ex:Ryan rdf:type ex:Person;
        ex:trusts ex:John.
ex:John rdf:type ex:Person;
        ex:trusts ex:Matt;
        ex:trusts ex:Ryan.
ex:Matt rdf:type ex:Person;
        ex:trusts ex:Andrew.
ex:Andrew rdf:type ex:Person;
          ex:trusts ex:Mike.
ex:Mike rdf:type ex:Person.

[] rdfs:subPropertyOf ex:indirectlyTrusts;
   owl:propertyChain (
     ex:trusts
     ex:trusts
     ).

Running pc_3.ttl produces the following output for Ryan:

Individual: Ryan
  type : http://example.org#Person
  type : http://www.w3.org/2002/07/owl#Thing
  sameAs : http://example.org#Ryan
  indirectlyTrusts : http://example.org#Ryan
  indirectlyTrusts : http://example.org#Matt
  trusts : http://example.org#John

As you can see, Ryan trusts John and indirectly trusts Matt (and Ryan), and that is the extent to which Ryan has any trust relationship with anyone. Even if we added the indirectly-trusts relationship to our ontology, transitivity wouldn’t be enough to achieve this same result that we just achieved with property chains. This isn’t to say that transitive properties aren’t useful, it’s just to highlight a scenario in which we may need something else to model our relationships.

For the next and final example, we’ll apply property chains to a slightly more complex example, the ontology for which is shown below (from pc_4.ttl):

ex:User rdf:type owl:Class.
ex:System rdf:type owl:Class.
ex:trusts rdf:type owl:ObjectProperty.
ex:authorizes rdf:type owl:ObjectProperty.
ex:grantsReadTo rdf:type owl:ObjectProperty.
ex:grantsWriteTo rdf:type owl:ObjectProperty;
                 rdfs:subPropertyOf ex:grantsReadTo.

[] rdfs:subPropertyOf ex:grantsWriteTo;
   owl:propertyChain (
     ex:trusts
     ex:authorizes
     ).

[] rdfs:subPropertyOf ex:grantsReadTo;
   owl:propertyChain (
     ex:trusts
     ex:authorizes
     ex:trusts
     ex:authorizes
     ).

What we’ve done here is described a very simple authorization protocol. In this protocol there are Systems and Users. Systems authorize users and Users trust Systems. A User decides who to grant read and write access to based on the set of Users who are authorized by the Systems the original user trust. Now, property chains don’t allow you to constrain the resources that are endpoints for the properties in the chain. As such, we can’t actually specify that the (trusts, authorizes) chain is specific to “trusts System” and “authorizes User.” All we can do is specify that any three resources associated by the chain of properties (trusts, authorizes). So, with that said – a resource grants write access to those resources who are authorized by the resources they trust. Read access is granted based on the same property chain, only with an additional step. So, a resource grants read access to those resources who are authorized by resources that are trusted by resources that are authorized by resources that are trusted by them (confused yet?). Anyways, take a look at the rest of the contents of pc_4.ttl:

ex:Ryan rdf:type ex:User;
        ex:trusts ex:System1.
ex:John rdf:type ex:User;
        ex:trusts ex:System1;
        ex:trusts ex:System2.
ex:Matt rdf:type ex:User.
ex:Andrew rdf:type ex:User;
        ex:trusts ex:System3.
ex:Mike rdf:type ex:User;
        ex:trusts ex:System3.

ex:System1 rdf:type ex:System;
           ex:authorizes ex:Ryan;
           ex:authorizes ex:John.

ex:System2 rdf:type ex:System;
           ex:authorizes ex:Matt;
           ex:authorizes ex:Mike;
           ex:authorizes ex:John.

ex:System3 rdf:type ex:System;
           ex:authorizes ex:Andrew;
           ex:authorizes ex:Mike.

Take a look at the output generated describing Ryan when we run this example in the Pellet reasoning application:

Individual: Ryan
  type : http://example.org#User
  type : http://www.w3.org/2002/07/owl#Thing
  sameAs : http://example.org#Ryan
  grantsWriteTo : http://example.org#John
  grantsWriteTo : http://example.org#Ryan
  trusts : http://example.org#System1
  grantsReadTo : http://example.org#John
  grantsReadTo : http://example.org#Ryan
  grantsReadTo : http://example.org#Mike
  grantsReadTo : http://example.org#Matt

As we would expect, Pellet has entailed that Ryan grants write access to John (and Ryan) because Ryan trusts System1 which authorizes John and Ryan. Read access is granted to John, Mike, and Matt. This is because John trusts the system that authorizes Mike and Matt and because ex:grantsReadTo is a sub-property of ex:grantsWriteTo.

Hopefully this article has given you some more insight into the semantics of property chains. Have fun tweaking these examples and building those knowledge models! Excited for more? Make comments, leave feedback, request a tutorial on a specific topic! And above all else – stay tuned for the next article…

Code downloads:  zip, 7z, tar.gz

This article is the first in a short series of articles that expands the code example from Chapter 5 of Semantic Web Programming to include some of the features of OWL 2. The code can be downloaded from here (zip, 7z, tar.gz), including an Eclipse project and all dependencies. This article focuses on how the semantics of qualified cardinality restrictions are interpreted and applied in a reasoner that supports most of OWL 2 semantics (Pellet 2.0 RC6 – see the Pellet documentation for a full list of the semantics supported in each release candidate).

For a more in-depth exploration of OWL and Semantic Web, feel free to reference the book as needed or buy a copy so you can learn about the cool stuff in this article and more

Recall from Chapter 4 in the book that cardinality restrictions are a way to specify the number of statements that describe an individual with a unique value that have a particular property as the predicate of each statement… e.g.  a person has exactly one date of birth or a parent has at least one child. Qualified cardinality restrictions (QCRs) allow you to further describe that set of statements by specifying the number of those statements which should have an individual of a particular class or value of a particular data range as the object of the statement… e.g. a molecule of water has three atoms, exactly two of which are hydrogen atoms and one of which is an oxygen atom – or a person has exactly two parents, one of which is male and the other which is female. Qualified cardinality restrictions can be on both object and datatype properties; however, RC6 of Pellet 2.0 only currently supports them for object properties.

Qualified cardinality restrictions are convenient because they avoid the need to add extra properties to an ontology in order to make cardinality restrictions specific to the range of the statements to which they apply. Without QCRs, specifying that a person has a mother and a father would likely require gender-specific properties like hasMother and hasFather. These predicates may be useful, but they are not necessary – at least when we can use QCRs instead.

For this example, we are reusing the code from Chapter 5′s code project with only a few minor modifications (we changed the way we create the Pellet reasoner-enabled model). The major difference is that we are using the latest version of Pellet (2.0RC6), which supports most of the semantics of the OWL 2 vocabulary. So, let’s get started!

Our goal is to express (in our ontology) the fact that a mammal has two parents, one of which is male and one of which is female. For our purposes, the property hasParent is an object property and male and female are classes. We will extend the class mammal with the axioms for the QCR definition. The excerpt of turtle that expresses these concepts is below (taken from qcr_1.ttl):

ex:Male rdf:type owl:Class.
ex:Female rdf:type owl:Class.

ex:hasParent rdf:type owl:ObjectProperty.
ex:isParentOf rdf:type owl:ObjectProperty;
             owl:inverseOf ex:hasParent.

ex:Mammal rdf:type owl:Class;
          rdfs:subClassOf
          [
            rdf:type owl:Restriction;
            owl:onProperty ex:hasParent;
            owl:cardinality 2
          ];
          rdfs:subClassOf
          [
            rdf:type owl:Restriction;
            owl:qualifiedCardinality 1;
            owl:onProperty ex:hasParent;
            owl:onClass ex:Female
          ];
          rdfs:subClassOf
          [
            rdf:type owl:Restriction;
            owl:qualifiedCardinality 1;
            owl:onProperty ex:hasParent;
            owl:onClass ex:Male
          ].

The class definition for ex:Mammal now contains three restrictions, the first specifies that all mammals have exactlly two statements with ex:hasParent as the predicate and a unique individual as the object, the second specifies that one of the statements with ex:hasParent as the predicate must have an object that is an instance of the class ex:Female and the third is the same only for ex:Male. Now that we have the capacity to describe parents, let’s define a couple of instances of canine and associate them with our example pooch from before: Daisy.

ex:Kujo rdf:type ex:Mammal;
         rdf:type ex:Male;
         ex:name "King Kujo".

ex:Lady rdf:type ex:Canine;
        ex:name "Lady";
        ex:breed ex:GoldenRetriever.

ex:Daisy rdf:type ex:Canine;
         ex:name "Daisy";
         ex:registeredName "Morning Daisy Bathed in Sunshine";
         ex:breed ex:GoldenRetriever;
         ex:hasParent ex:Kujo;
         ex:hasParent ex:Lady.

We’ve described ex:Kujo and ex:Lady and stated that they are the parents of ex:Daisy. Run the program in the project (execute the main method with the parameters qcr_1.ttl TURTLE qcr_out.txt owl) and take a look at the results. You will notice that the inverse property as well as the subproperty and subclass semantics have been applied; however, no entailments have been made as a result of the QCR. You may expect that Pellet should infer that Lady is female because Kujo is a male, and the two of them are the parents of Daisy. This after all, is sort of the goal we are going for in defining this restriction in our ontology. But, we haven’t described the situation completely enough for the reasoner to assert this new fact. For all we (and the reasoner) know, Lady is the same individual as Kujo (recall the no unique names assumption from Chapter 4?), meaning that they could both be male. Also, we haven’t said anything about the relationship between the classes ex:Male and ex:Female. For all we know an individual could be both male and female. Because of these facts, the reasoner cannot make any correct conclusions about Lady despite our QCR on ex:Mammal.

To correct this situation and enable Pellet to make the expected conclusions, we must assert two facts: 1) ex:Kujo and ex:Lady are different individuals and 2) ex:Male and ex:Female are disjoint classes. These atoms are below (and are added in the file qcr_2.ttl):

ex:Male rdf:type owl:Class.
ex:Female rdf:type owl:Class;
          owl:disjointWith ex:Male.

ex:Lady rdf:type ex:Canine;
        ex:name "Lady";
        ex:breed ex:GoldenRetriever;
        owl:differentFrom ex:Kujo.

Both owl:disjointWith and owl:differentFrom are symmetric properties, so they only need to be asserted in one direction. Run the program with the input file qcr_2.ttl and take a look at the results. Voila! Lady is now an instance of the class ex:Female:

Individual: Lady
  type : http://example.org#Female
  type : http://www.w3.org/2002/07/owl#Thing
  type : http://example.org#Canine
  type : http://example.org#Mammal
  sameAs : http://example.org#Lady
  differentFrom : http://example.org#Kujo
  breed : http://example.org#GoldenRetriever
  name : Lady
  isParentOf : http://example.org#Daisy

This worked because we asserted that Lady and Kujo are different individuals, meaning that Lady has to be the other parent of Daisy. Also, we asserted that male and female are disjoint classes, meaning that Kujo cannot be female, and that the only individual who can be the female parent of Daisy is Lady. This latter point is tricky, if male and female were not disjoint, Kujo could be both the female parent as well as the male parent of Daisy, allowing Lady to be neither male nor female while still leaving the restriction satisfied (2 parents, one female parent, one male parent).

Now, let’s play around a bit. As we saw from the previous example, the semantics of our QCR plus the fact that male and female are disjoint classes and Lady and Kujo are different individuals is enough for the reasoner to entail that Lady is female (even though we didn’t explicity state that). So, what happens when there are more than two parents of Daisy? Let’s take a look at how the QCR semantics can be applied in this situation. The file qcr_3.ttl has the following modifications to it:

ex:KingKujo rdf:type ex:Canine;
         rdf:type ex:Male;
         ex:breed ex:GoldenRetriever;
         ex:isParentOf ex:Daisy;
         ex:name "King Kujo of Calvert County".

Notice that all we’ve done is described a new individual ex:KingKujo and stated that he is a parent of ex:Daisy. Run the program with the input qcr_3.ttl and take a look at the output file. This is really interesting stuff! The reasoner combined the inverse-of semantics of ex:isParentOf with the fact that there are two male parents of ex:Daisy to infer that ex:KingKujo has to be the same individual as ex:Kujo. Notice that because the owl:sameAs statement now exists between ex:Kujo and ex:KingKujo, both individuals are described by the union of the statements about each:

Individual: KingKujo
  type : http://www.w3.org/2002/07/owl#Thing
  type : http://example.org#Canine
  type : http://example.org#Mammal
  type : http://example.org#Male
  sameAs : http://example.org#KingKujo
  sameAs : http://example.org#Kujo
  differentFrom : http://example.org#Lady
  breed : http://example.org#GoldenRetriever
  name : King Kujo
  name : King Kujo of Calvert County
  isParentOf : http://example.org#Daisy

Individual: Kujo
  type : http://www.w3.org/2002/07/owl#Thing
  type : http://example.org#Canine
  type : http://example.org#Mammal
  type : http://example.org#Male
  sameAs : http://example.org#KingKujo
  sameAs : http://example.org#Kujo
  differentFrom : http://example.org#Lady
  breed : http://example.org#GoldenRetriever
  name : King Kujo
  name : King Kujo of Calvert County
  isParentOf : http://example.org#Daisy

In this ontology, if ex:Kujo and ex:KingKujo are in fact not the same individual, the KB will have reached an inconsistent state. Two individuals who are different will also be the same. Just to drive this point home, lets see what happens if we explicity state that ex:Kujo and ex:KingKujo are different individuals by adding an owl:differentFrom statement between them (run the program with input file qcr_4.ttl). As you will see, Pellet generates a warning:

Jun 1, 2009 5:15:35 PM
   org.mindswap.pellet.KnowledgeBase consistency
WARNING: Inconsistent ontology.
Reason: Individual http://example.org#Daisy
        has more than 1 values for property
        http://example.org#hasParent violating
        the cardinality restriction

This is to be expected because we knowingly asserted something that is inconsistent with the axioms of our ontology. This warning is an indication that something in our knowledgebase violates the conditions of our ontology. Mike Smith (book tech editor/Clark and Parsia Pellet developer/all round awesome guy) tells me we can’t expect that specific warning will be generated in future release candidates as there are many situations in which an inconsistent ontology may be desirable and it is irritating to have ever instance logged by default. But, the good news is there are alternate ways to check the consistency of an ontology using Jena and Pellet. So, we will still be able to detect these inconsistencies when they occur (reading the documentation for Pellet and Jena to figure out the best way to do this is your homework assignment)

Hopefully this exploration has given you greater insight into the semantics of of qualified cardinality restrictions. We could go on for hours with other examples, but this should provide you with some more building blocks that you can apply to your own experimentation.  Have fun, and stay consistent

Code downloads:  zip, 7z, tar.gz

Author’s note: Thanks to John Hebeler and Mike Dean for their inputs and Mike Smith for the feedback regarding Pellet.

This tutorial outlines a step-by-step, code-based approach to enable you to quickly master the fundamentals in building a semantic Web application. We quickly establish the key concepts and their relationship to application development. Then we programmaticly build the knowledge model, integrate diverse information sources, expose to various reasoners, query the unified value, and then export to various formats and methods using an iterative, collaborative format to get you involved and learning. This takes you through all necessary tools and techniques to quickly get started on your own solution.

For more information see the official SemTech site.

More information can be found here. We hope to see some of you there!