Sep 01 2011
Goals of Reasoning for the Semantic Web in Practice
I recently summarised the different means of reasoning on the Semantic Web in a discussion on the Apache Stanbol mailinglist. I thought I might also share my views publicly in my blog
I think that large parts of the Semantic Web community lost track of the actual (practical) goals of reasoning. Please think of actual, practical use cases. The actual kind of reasoning employed is then derived from this goal – not the other way round. In the following, I summarise the three different possible approaches to reasoning:
schema validation
This is the typical reasoning applied in the Semantic Web domain. I always found its usefulness very limited and therefore this is only mildly interesting to me. How often will you really need to check whether a model is consistent? Usually only during development, if at all. Even worse: when operating on the World Wide Web you will *inevitably* have inconsistencies, so it is better to simply live with them and not care too much about consistent schemas, it will only drive you crazy (see below).
For schema validation, you will probably use some of the existing OWL and description logics reasoners like Hermit, FaCT, Racer, … but be aware that they are all rather complex and inefficient when dealing with bigger datasets, as you identified as a problem yourself.
instance classification
Instance classification means, informmaly, to figure out the type of a resource based on the existance of a schema or ontology for the data. Now this is at least *a bit* more interesting than schema validation, because it provides you with actual new information that you can make use of. It allows you to treat a Blog Post as a Document, a Meeting as a Location, etc. On the other hand, every programmer can implement you this kind of reasoning in a couple of hours in Java without any need of a reasoner.
For instance classification you can in the most simple case use an RDFS reasoner (very efficient). OWL reasoners are obviously also capable of this, but usually in practice not much better than RDFS reasoners so it is not worth the added complexity. Instance classification can furthermore be considered a specific case of implicit/rule-based knowledge.
implicit/rule-based knowledge
In this case, you extend your factual, static knowledge base (i.e. triples) by rules that represent implicit knowledge (e.g. “if a meeting M is located in a place P and P has coordinates X and Y, then M also has coordinates X and Y). This kind of reasoning is the classical way of representing knowledge in knowledge based systems and adds, in my opinion, real additional value to the information, because much human knowledge is actually rule-based. I consider this kind of reasoning the most interesting in an information system. Rule-based reasoners can cover instance classification as a special case and with a few extensions even most parts of consistency checking.
Rule-based reasoning is currently still a bit esoteric in the Semantic Web domain (Jena only uses it for implementing RDFS/OWL reasoning), as the reasoning topic has been “hijacked” by the Description Logics people. I often criticised this because of its impracticality, but noone would really listen
There is the RuleML initiative which resulted in the specification of SWRL, but SWRL is seen as an extension of DL reasoning and thus suffers from the inefficiency of these reasoners. Outside the Semantic Web, the most successful rule-based reasoning system is probably Prolog and Datalog, both highly efficient systems but unfortunately not really present in the Java and RDF world.
Inside the “Linked Media Framework”, which we intend to integrate with Apache Stanbol, I have implemented a Datalog-style rule-based reasoner over RDF triples that can be evaluated very efficiently (see the link I sent above for the specification). Even though this reasoner has a quite restricted expressivity, it is still sufficient to cover many useful scenarios.
On the usefulness of consistency checking for the Semantic Web
1. Why do logics people care about consistency?
The whole topic of consistency checking is rooted in classical logics. It is founded in the “ex falsum quodlibet” rule of first order predicate logic, which basically says “if you have an inconsistency in your model, you can derive everything”. Maybe you still know the rule from your logics lectures
“false => A” is equivalent to “not false or A” is equivalent to “true”, regardless of A.
For example, in a strictly classical model sense, if you have a knowledge base saying “the car is red” and “the car is green” and “green is not red”, then you could derive that “the moon is made of green cheese and inhabited by small fur balls constantly discussing about how to best cook spaghetti”. Which is of course completey stupid, but completely valid in classical logic.
In a model in classical logics, this is a severe problem, because it means that you cannot derive anything useful at all even if you have just a small inconsistency.
2. Why is inconsistency irrelevant in many cases?
Inconsistency is only a problem in the ideal world of classical logics. Real-world implementations will never have the same kind of problems described above, how should they get the idea that the moon is made of green cheese based on the facts that the car is green and red at the same time? Software implementations are maybe constructive, but based on existing facts and not making up facts out of the blue sky.
The worst case that can happen is that the software will show some error behaviour. Instead of trying to enforce consistency (which in many cases you cannot), one challenge is to isolate the error as much as possible and keep it from spreading. Another challenge is to explain to the user why some unexpected behaviour takes place and how she can prevent it from happening.
The rule-based reasoner implemented in the LMF is completely ignorant to inconsistencies. It does not care at all about them. If you say the car is red and the car is green, then it will maybe derive that it should be tagged with “green” and with “red”. The error spreads maybe a bit, but the reasoner will never claim that the moon is made of green cheese. But maybe you were even right that the car is red and green at the same time (striped car)?
The rule-based reasoner implemented in the LMF will also display you explanations why it has inferred certain knowledge. If the car is tagged with red and tagged with green and you as the user wonder how this could be, you can hover the mouse over the tag and the reasoner will explain you that this is because someone said the car is green and someone said the car is red.
3. Why is dealing with inconsistency even desirable?
The world is full of inconsistencies. And the Web in particular. Neglecting this is the number one problem of the Semantic Web DL community. Accepting this is the number one success factor of the Linked Data initiative. Why is the Web so full of inconsistencies?
- people can have differing opinions about the world: you say “it is cold”, I say “it is warm”, and we are both right
- different cultural conceptions: Spanish has one word for “snow”, Icelandic has 16 different words for “snow”
- uncertainties: most circumstances do not fit into the ideal world of logics because of unknown or uncertain knowledge; a document might be concerned with a topic only to 30%, or the Stanbol entity recognition might only have a confidence of “15%” that “San Juan” is a person, “30%” that it is a city, … ; if you say “all ravens are black”, this is entirely based on observation and not on fact, there might be a white raven somewhere, you just don’t know it







