A use case that relies on OWL reasoning

This page has the aim of collecting ideas for finding a use case which is nice, useful, and business-worth to CMS providers/developers and that requires (at least) OWL expressivity and reasoning support i.e. when SPARQL is not enough or much more complex.

It must be clarified that certain OWL construct are used for their expressivity in RDF-based models, and then only syntactically exploited e.g. through SPARQL queries. The aim is to find one or more cases where OWL formal semantics results useful/needed in addition to its syntactic expressivity. Such formal semantics implies certain inferences that can be used for enriching the knowledge base before querying it. Hence, OWL, automatic reasoning, and SPARQL querying, are to be considered three different, complimentary things.

When does a CMS need a reasoner in addition to OWL expressivity?

For example when you cannot obtain the same behavior by using only SPARQL.

Or when you can, but it is more expensive, when the queries you would need are one page long, and you have to write additional complex ad-hoc code that won't be reusable in other contexts.

Below there are few examples that should clarify typical reasoning (basic) services, and hopefully make you identify their potential exploitation for interesting CMS functionalities to support user stories.

1) Transitivity

1.1) Indirect transitivity (or transitive reduction)

2) Instance classification

3) Inheritance

4) Cardinality of property values

5) Data integrity/coherence

1) Transitivity

For example, if a CMS classifies content items based on concepts/topics, if I query for content items about rock music, I would like to see among the results content items about "heavy metal music", even if they are not explicitly tagged with concept "rock music", because heavy metal is included in rock music. Additionally, all content tagged with "death metal" should be included too, because death metal is included in heavy metal.

In order to obtain this behavior I can use, for example, SKOS [1] as follows (in my ontology of concepts):

"heavy metal music" skos:narrowerTransitive "rock music"

"death metal music" skos:narrowerTransitive "heavy metal music"

c1 skos:narrowerTransitive c2 (concept c1 is narrower than c2)

skos:narrowerTransitive is transitive relation btw two concepts

In order to represent that a relation is transitive you need OWL expressivity.

In order to obtain the desired behavior by the content item classifier you need the OWL reasoner.

1.1) Indirect transitivity (or transitive reduction)

It is the case of having a relation that is not transitive itself but that "implies" another one which is transitive.

A typical example used for understanding the situation is that of "components of a car":

You have two relations: one is "direct component of" which is not transitive, the other is "part of" which is transitive.

For example, the turbine is direct component of the engine. The engine is part of the car.

The two relations are associated because if one thing is direct component of another then it is also part of it, and you want to possibly exploit the transitive closure of "part of".

In other words, you want that "the turbine is direct component of the engine" implies that the "turbine is part of the engine" so that when you compute the transitive closure on part of the turbine is included.

It is the case of having a relation that is not transitive itself but that "implies" the validity of another one which is transitive.

A typical example used for understanding the situation is that of describing the "components of a car".

You have two relations: one is "direct component of" which is not transitive, the other is "part of" which is transitive.

For example, the turbine is a direct component of the engine and the engine is part of the car.

From this "knowledge" you might want "the turbine is part of the car" to be automatically inferred, because when you possibly exploit the transitive closure of "part of", you want the turbine to be included.

In fact, the two relations are associated because if one thing is direct component of another then it is also part of it, but not vice versa.

OWL allows to obtain such behavior by expressing that "direct component of" is a sub-property-of "part of", which in turn is a transitive property.

A similar situation is that of distinguishing events that immediately precede/succeed other events from those that just come before or after them e.g. in a programme.

2) Instance classification

Another example is given by what is called "instance classification".

Imagine you want to suggest/allow access to content items to a special type of users of your CMS (you can maybe have many different special types/criteria).

It could be for policy reasons, for advertisement purposes, or for supporting some work e.g. writing reports.

You cannot do that with SPARQL (well, maybe with SPARQL+some complex ad-hoc code, but without exploiting inheritance - you cannot have the same result)

In order to obtain such behavior, you can create that special class of users in you OWL ontology and express its characteristics -> you need at least OWL for representation

The reasoner will classify users belonging to that type according to the definition of the class.

3) Inheritance

Another thing that might be noticed is that SPARQL does not consider/exploit inheritance.

For example, consider that one wants to query the CMS for all content items of a certain project.

The ontology of content items includes the class "ProjectDocument"

which has a sub-class TechnicalReport i.e. it is rdfs:subClassOf ProjectDocument, hence for inheritance, technical reports are project documents.

A SPARQL query selecting all project documents (for a certain project) would ignore technical reports, because SPARQL does not compute inheritance.

Unless the class TechnicalReport is explicitly included in the query.

For exploiting inheritance you need rdfs:subClassOf + a standard reasoner.

4) Cardinality of property values - taken from a blog

For example, in DBPedia, a Band (<http://dbpedia.org/ontology/Band>) has property <http://dbpedia.org/ontology/genre> with no cardinality restrictions (i.e. Band can have any number of genres).

Using sparql one can not extract Bands which has more than x number of genres?

The following SPARQL query is not possible to write and execute:

Select ?band

where

{

?band rdf:type <http://dbpedia.org/ontology/Band> .

?band <http://dbpedia.org/ontology/genre> ?genre .

FILTER (COUNT(?genre) > 3).

}

5) Data integrity/coherence

Another example is the use of OWL + a standard reasoner for consistency checking.

A use case can be (i) that of an administrator checking that values assigned to certain things are valid e.g age within a certain range

another one can be (ii) the need of ensuring that there is a clear distinction btw certain types of content items e.g. user profiles and documents, customer and staff.

In this case you would need

(i) OWL data ranges (OWL 2) + a standard reasoner

(ii) OWL disjointness + a standard reasoner

Finally, once a reasoner is integrated you can have for free:

- inverse relations:

e.g. skos:narrowerTransitive is inverse of skos:broaderTransitive

-> the knowledge base is enriched by including broader relations btw topics, that can be exploited e.g. for browsing

- symmetry of relations:

-> again for enrichment. If two topics overlap e.g. cognitive science overlaps philosophy, also the vice versa is true i.e. philosophy overlaps cognitive science. You want this knowledge stored in you base.

Inverse and symmetry can be induced by SPARQL CONSTRUCT, but once you have a reasoner they are for free if you just define your relation as such!

All the above are simple examples, in my opinion enough for providing nice functionalities with few effort, given that they are useful.

My aim is to make ring some bell to you :) and find something more significative for a business domain you have experience with.

I am eager to know if any of you finds the above useful/inspiring for an interesting use case case.

[1] http://www.w3.org/2009/08/skos-reference/skos.rdf

1) Transitivity

In order to obtain this behavior I can use, for example, SKOS [1] as follows (in my ontology of concepts):

"heavy metal music" skos:narrowerTransitive "rock music"

"death metal music" skos:narrowerTransitive "heavy metal music"

c1 skos:narrowerTransitive c2 (concept c1 is narrower than c2)

skos:narrowerTransitive is transitive relation btw two concepts

In order to represent that a relation is transitive you need OWL expressivity.

In order to obtain the desired behavior by the content item classifier you need the OWL reasoner.

2) Instance classification

Another example is given by what is called "instance classification".

Imagine you want to suggest/allow access to content items to a special type of users of your CMS (you can maybe have many different special types/criteria).

It could be for policy reasons, for advertisement purposes, or for supporting some work e.g. writing reports.

You cannot do that with SPARQL (well, maybe with SPARQL+some complex ad-hoc code, but without exploiting inheritance - you cannot have the same result)

In order to obtain such behavior, you can create that special class of users in you OWL ontology and express its characteristics -> you need at least OWL for representation

The reasoner will classify users belonging to that type according to the definition of the class.

3) Inheritance

Another thing that might be noticed is that SPARQL does not consider/exploit inheritance.

For example, consider that one wants to query the CMS for all content items of a certain project.

The ontology of content items includes the class "ProjectDocument"

which has a sub-class TechnicalReport i.e. it is rdfs:subClassOf ProjectDocument, hence for inheritance, technical reports are project documents.

A SPARQL query selecting all project documents (for a certain project) would ignore technical reports, because SPARQL does not compute inheritance.

Unless the class TechnicalReport is explicitly included in the query.

For exploiting inheritance you need rdfs:subClassOf + a standard reasoner.

4) Data integrity/coherence

Another example is the use of OWL + a standard reasoner for consistency checking.

A use case can be (i) that of an administrator checking that values assigned to certain things are valid e.g age within a certain range

another one can be (ii) the need of ensuring that there is a clear distinction btw certain types of content items e.g. user profiles and documents, customer and staff.

In this case you would need

(i) OWL data ranges (OWL 2) + a standard reasoner

(ii) OWL disjointness + a standard reasoner

Finally, once a reasoner is integrated you can have for free:

- inverse relations:

e.g. skos:narrowerTransitive is inverse of skos:broaderTransitive

-> the knowledge base is enriched by including broader relations btw topics, that can be exploited e.g. for browsing

- symmetry of relations:

Inverse and symmetry can be induced by SPARQL CONSTRUCT, but once you have a reasoner they are for free if you just define your relation as such!

All the above are simple examples, in my opinion enough for providing nice functionalities with few effort, given that they are useful.

My aim is to make ring some bell to you :) and find something more significative for a business domain you have experience with.

I am eager to know if any of you finds the above useful/inspiring for an interesting use case case.

[1] http://www.w3.org/2009/08/skos-reference/skos.rdf

1) Transitivity

In order to obtain this behavior I can use, for example, SKOS [1] as follows (in my ontology of concepts):

"heavy metal music" skos:narrowerTransitive "rock music"

"death metal music" skos:narrowerTransitive "heavy metal music"

c1 skos:narrowerTransitive c2 (concept c1 is narrower than c2)

skos:narrowerTransitive is transitive relation btw two concepts

In order to represent that a relation is transitive you need OWL expressivity.

In order to obtain the desired behavior by the content item classifier you need the OWL reasoner.

2) Instance classification

Another example is given by what is called "instance classification".

Imagine you want to suggest/allow access to content items to a special type of users of your CMS (you can maybe have many different special types/criteria).

It could be for policy reasons, for advertisement purposes, or for supporting some work e.g. writing reports.

You cannot do that with SPARQL (well, maybe with SPARQL+some complex ad-hoc code, but without exploiting inheritance - you cannot have the same result)

In order to obtain such behavior, you can create that special class of users in you OWL ontology and express its characteristics -> you need at least OWL for representation

The reasoner will classify users belonging to that type according to the definition of the class.

3) Inheritance

Another thing that might be noticed is that SPARQL does not consider/exploit inheritance.

For example, consider that one wants to query the CMS for all content items of a certain project.

The ontology of content items includes the class "ProjectDocument"

which has a sub-class TechnicalReport i.e. it is rdfs:subClassOf ProjectDocument, hence for inheritance, technical reports are project documents.

A SPARQL query selecting all project documents (for a certain project) would ignore technical reports, because SPARQL does not compute inheritance.

Unless the class TechnicalReport is explicitly included in the query.

For exploiting inheritance you need rdfs:subClassOf + a standard reasoner.

4) Data integrity/coherence

Another example is the use of OWL + a standard reasoner for consistency checking.

A use case can be (i) that of an administrator checking that values assigned to certain things are valid e.g age within a certain range

another one can be (ii) the need of ensuring that there is a clear distinction btw certain types of content items e.g. user profiles and documents, customer and staff.

In this case you would need

(i) OWL data ranges (OWL 2) + a standard reasoner

(ii) OWL disjointness + a standard reasoner

Finally, once a reasoner is integrated you can have for free:

- inverse relations:

e.g. skos:narrowerTransitive is inverse of skos:broaderTransitive

-> the knowledge base is enriched by including broader relations btw topics, that can be exploited e.g. for browsing

- symmetry of relations:

Inverse and symmetry can be induced by SPARQL CONSTRUCT, but once you have a reasoner they are for free if you just define your relation as such!

All the above are simple examples, in my opinion enough for providing nice functionalities with few effort, given that they are useful.

My aim is to make ring some bell to you :) and find something more significative for a business domain you have experience with.

I am eager to know if any of you finds the above useful/inspiring for an interesting use case case.

[1] http://www.w3.org/2009/08/skos-reference/skos.rdf