You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stanbol.apache.org by Enrico Daga <en...@gmail.com> on 2011/08/30 16:12:36 UTC
What's going on with reasoners (STANBOL-185)
Hallo,
this is to share the developments of the last three weeks around
STANBOL-185 (Support for Jena-based reasoning services).
Initial problem was:
1) No support for Jena
2) Hermit LGPL dependency (so no default reasoner with the current
implementation that can be distributed with Stanbol)
3) No extendibility for off the shelf reasoning services
All three points are addressed by the current version in
branches/jena-reasoners (even if lot of things can improved).
What have been implemented?
* A /serviceapi for ReasoningServices, using SCR, and a REST endpoint
which automatically publish all available services (in /web)
* Base OWLApi and Jena abstract services
* Jena RDFS,OWL,OWLMini reasoning services
* HermiT reasoning service (this will be moved out of Stanbol, finally)
At the end of this e-mail I include the content of the README.txt
file, for your convenience, which includes some of ideas and proposal
for improvements.
I would really appreciate if the community can have a look at it, and
provide some feedback.
I did my best to make this api as flexible and efficient as possible,
but I know more work must still be done in this direction (some ideas
are below).
I am going to verify the integritycheck demo with respect to this
implementation, while it is working, I will move the code in /trunk.
Thank you all
Enrico
-------------------------------------
Description
=============
* A serviceapi for ReasoningServices, using SCR
* Base OWLApi and Jena abstract services
* Jena RDFS,OWL,OWLMini reasoning services
* HermiT reasoning service
* A common REST endpoint at /reasoners with the following preloaded services:
** /rdfs
** /owl
** /owlmini
** /owl2
each can be accessed with one of three tasks: check,enrich,classify,
for example:
/reasoners/owl/check (the Jena owl service with task classify)
or
/reasoners/owl2/classify (the hermit service with task classify)
Tasks description:
* check : is the input consistent? 200 =true, 204 =false
* classify : return only rdf:type inferences
* enrich : return all inferences
This is how the endpoint behave:
GET (same if POST and Content-type: application/x-www-form-urlencoded)
params:
* url // Loads the input from url
* target // (optional) If given, save output in the store (TcManager)
and does not return the stream
for example:
$ curl "http://localhost:8080/reasoners/owl2/classify?url=http://xmlns.com/foaf/0.1/"
POST [Content-type: multipart/form-data]
* file // Loads from the input stream
* target // (optional) If given, save output in the store
(TcManager) and does not return the stream
Other parameters can be sent, to support inputs from Ontonet and Rules:
These additional parameters can be sent:
* scope // the ID of an Ontonet scope
* session // The ID of an Ontonet session
* recipe // The ID of a recipe from the Rules module (only with
OWLApi based services)s
Supported output formats:
Supported return formats are all classic RDF types (n3,turtle,rdf+xml)
and HTML. For HTML the returned statements are provided in Turtle
(Jena) or OWL Manchester syntax (OWLApi), wrapped in the stanbol
layout. It would be nice to have all in the latter, which is very much
readable (todo).
Todo
=============
* Support for return types json and json-ld (need to write jersey writers)
* The front service actually returns only inferred statements. It is
useful also to have the complete set of input+inferred statements
* Support for long-term operations. This is crucial for reasoning
tasks, since it can take some time with large graphs. This is needed
in general for Stanbol, something like "Stanbol Jobs".
* Decouple input preparation from the rest endpoint resource, creating
something like an InputProvider SCR api; each InputProvider is bound
to a set of additional parameters.
This have several benefits:
** Remove of additional optional parameters, bound to specific input
sources from the default rest api (ex, session, scope, recipe)
** Remove dependencies to ontonet, rules and other modules which are
not needed for standard usage. They could be implemented as
InputProvider/s, bound to specific parameters.
** Allow the addition of other input sources (for example 'graph',
'entity' or 'site')
* Implement a Custom Jena ReasoningService, to use a Jena rules file
or a stanbol recipe (when implemented the toJena() functionality in
the rules module) from configuration. This could be done as multiple
SCR instance, as it is now for entityhub sites, for example.
* Provide a validation report in case of task CHECK (validity check).
* Implement a progress monitor, relying on the jena and owlapi apis,
which have this feature, for debugging purpose
* Implement a benchmark endpoint, relying on OWL manchester syntax, to
setup benchmark tests in the style of the one made for the enhancer
* Implementing owllink client reasoning service
* Implement additional data preparation steps, for example to
implement a "consistent refactoring" task. For example, giving a
parameter 'refactor=<recipe-id>' the service could refactor the graph
before execute the task.
* Implement off the shelf reasoning services (for example, targeted to
resolve only owl:sameAs links)
General issues
=============
The main problem is performance, which decrease while the input data
grows, in some cases dramatically. This could be faced (IMHO), in two
directions:
* Improve input preparation. In particular, the preparation of input
form ontonet scope/session needs to stream the ontologies, in cases of
more input (url provided) twice!, and this have some drawback on
performance.
* Support long-term operations, to start the process from the REST
call and then ping it's process through a dedicated endpoint
Notes (to be known)
=============
Differences between Jena and OWLApi services:
* CHECK have different meaning with respect to the reasoning service
implementation
Examples
=============
#
# Basic GET calls to the reasoning services.
# Send a URL and the service will return the inferred triples
#
# Classify the FOAF ontology, getting it from the web using the Jena
OWL reasoner, result in turtle
curl -v -H "Accept: application/turtle"
"http://localhost:8080/reasoners/owl/classify?url=http://xmlns.com/foaf/0.1/"
# Classify the FOAF ontology, getting it from the web using the Jena
OWL reasoner, result in n3
curl -v -H "Accept: text/n3"
"http://localhost:8080/reasoners/owl/classify?url=http://xmlns.com/foaf/0.1/"
# Enrich the FOAF ontology, getting it from the web using the Jena
RDFS reasoner, result in rdf/xml
curl -v -H "Accept: application/rdf+xml"
"http://localhost:8080/reasoners/owl/classify?url=http://xmlns.com/foaf/0.1/"
# Check consistency of the FOAF ontology, getting it from the web
using the Jena OWL reasoner, result in turtle
curl -v "http://localhost:8080/reasoners/owl/check?url=http://xmlns.com/foaf/0.1/"
# Check consistency of the FOAF ontology, getting it from the web
using the Hermit OWL2 reasoner, result in turtle
curl -v "http://localhost:8080/reasoners/owl2/check?url=http://xmlns.com/foaf/0.1/"
# Trying with an ontology network (large ontology composed by a set of
little ontologies connected through owl:import statements)
curl -v "http://localhost:8080/reasoners/owl2/check?url=http://www.cnr.it/ontology/cnr/cnr.owl"
# or
curl -v "http://localhost:8080/reasoners/owl2/enrich?url=http://www.cnr.it/ontology/cnr/cnr.owl"
#
# POST calls (send a file)
#
# Send the foaf.rdf file to a reasoning service and see the output
# (get it with
curl -H "Accept: application/rdf+xml" http://xmlns.com/foaf/0.1/ > foaf.rdf
# )
curl -X POST -H "Content-type: multipart/form-data" -H "Accept:
text/turtle" -F file=@foaf.rdf
"http://localhost:8080/reasoners/rdfs/enrich"
# Save output in the triple store instead of return
# >> Add the "target" parameter, with the graph identifier
curl "http://localhost:8080/reasoners/owl/classify?url=http://xmlns.com/foaf/0.1/&target=example-foaf-inferred"
# or, posting a file
curl -X POST -H "Content-type: multipart/form-data" -F file=@foaf.rdf
-F target=example-rdfs-inferences
"http://localhost:8080/reasoners/rdfs/enrich"
--
Enrico Daga
--
http://www.enridaga.net
skype: enri-pan
Re: What's going on with reasoners (STANBOL-185)
Posted by Sebastian Schaffert <se...@salzburgresearch.at>.
Hi Valentina,
nice to hear from you in this context also ;-)
Am 31.08.2011 um 17:46 schrieb valentina presutti:
> Dear Sebastian, all,
>
> I fully agree on your statement :) and thanks for the further elaboration, I find it useful.
> However, this is true when you deal with the Semantic Web Scale: personally I find useless trying "to clean" data based on consistency checking
> even because this would mean to promote one universal foundational model as the "right" one, which is ridiculous (imo).
+1 ;-)
It is more than ridiculous, it is also impossible.
>
> In the context of IKS, and more in general in the context of application that reuse Web data in a local context
> consistency checking might be useful as a feature, for example for checking if the data you would want to reuse can run well with your domain-ontology.
And - in a practical sense - what do you do if the answer is "no"? ;-)
I of course understand that there are scenarios for consistency checking, especially in ontology alignment and reuse. The question is how they are relevant in the context of IKS and especially in the context of Apache Stanbol. Depending on the answer we have to find the right way to deal with reasoning in Stanbol.
>
> I think that also in this last case there is something that can be debated: how can we use consistency checking in a clever way? For example,
> a reasoner that is able to identify what's the problem and show it to you by explaining it is already something useful.
> It would be even better the reasoner is also able to suggest possible changes in the data you want to reuse (possibly based on some configuration) while keeping the link with the original sources.
The LMF reasoner, if extended slightly, can provide some useful functionalities here. The extension that would be needed are "consistency rules" that derive inconsistency, e.g.:
(X rdf:type C), (X rdf:type D), (C owl:disjointWith D) -> false.
The reason maintenance component contained in the reasoner could then show you the reasons for all inconsistencies that are contained in the model.
>
> I mean, consistency checking can be a useful feature if it is tailored to specific use cases, while I agree it is almost non-sense as a web scale problem.
Ok, so let me reformulate my "goals" question a bit:
How would a user of Stanbol benefit from a consistency checking reasoner BEYOND what he can already get by developing in Protegé (where he would develop the model anyways) and using one of the DL reasoners there. Should Stanbol aim at being a tool for developing ontologies and data models?
Greetings,
Sebastian
>
> Val
>
> On Aug 31, 2011, at 5:18 PM, Sebastian Schaffert wrote:
>
>> Dear all,
>>
>> I wanted to elaborate a bit on the topic of consistency checking because I have a strong opinion on this. And maybe it helps to give understanding why I consider it only mildly interesting in practical applications ... ;-)
>>
>> I wrote:
>>
>>>
>>> schema validation
>>> -----------------
>>>
>>> This is what you call "check" and 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. ;-)
>>
>>
>> Ok, this was my statement. Back to consistency checking ... :)
>>
>> 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
>>
>>
>>
>>
>> Sebastian
>> --
>> | Dr. Sebastian Schaffert sebastian.schaffert@salzburgresearch.at
>> | Salzburg Research Forschungsgesellschaft http://www.salzburgresearch.at
>> | Head of Knowledge and Media Technologies Group +43 662 2288 423
>> | Jakob-Haringer Strasse 5/II
>> | A-5020 Salzburg
>>
>
Sebastian
--
| Dr. Sebastian Schaffert sebastian.schaffert@salzburgresearch.at
| Salzburg Research Forschungsgesellschaft http://www.salzburgresearch.at
| Head of Knowledge and Media Technologies Group +43 662 2288 423
| Jakob-Haringer Strasse 5/II
| A-5020 Salzburg
Re: What's going on with reasoners (STANBOL-185)
Posted by Enrico Daga <en...@gmail.com>.
Dear Sebastian, all,
I give here only a quick response, since I'm on holiday (and will be
almost away from the e-mail until the 21th of September).
I agree with all your points, and I am very happy to join efforts
about the implementation of reasoning capabilities in Stanbol.
As I also pointed out in the previous e-mail, there are different ways
of implementing this, I started from web rest services, but long term
operations, also triple store changes lookup based, are all things
that must be implemented.
Regarding the unique API, this is actually what I started to implement
(even if the flexibility is actually limited, but I have some ideas
about how to improve and extend it, I am happy to have suggestions
about this). IMHO the criteria should be to support all reasoning
kinds, then let the users choose the one that better fits their needs.
If this common API must be done before implementing concrete use
cases, I would say NO, just start and do things incrementally, would
be the best option, IMHO.
But, as I said, I cannot start a deep discussion now, I will at the
end of this month, for sure.
Nice to have your work here on Stanbol!!!
Bests,
Enrico
On 31 August 2011 17:46, valentina presutti <va...@cnr.it> wrote:
> Dear Sebastian, all,
>
> I fully agree on your statement :) and thanks for the further elaboration, I find it useful.
> However, this is true when you deal with the Semantic Web Scale: personally I find useless trying "to clean" data based on consistency checking
> even because this would mean to promote one universal foundational model as the "right" one, which is ridiculous (imo).
>
> In the context of IKS, and more in general in the context of application that reuse Web data in a local context
> consistency checking might be useful as a feature, for example for checking if the data you would want to reuse can run well with your domain-ontology.
>
> I think that also in this last case there is something that can be debated: how can we use consistency checking in a clever way? For example,
> a reasoner that is able to identify what's the problem and show it to you by explaining it is already something useful.
> It would be even better the reasoner is also able to suggest possible changes in the data you want to reuse (possibly based on some configuration) while keeping the link with the original sources.
>
> I mean, consistency checking can be a useful feature if it is tailored to specific use cases, while I agree it is almost non-sense as a web scale problem.
>
> Val
>
> On Aug 31, 2011, at 5:18 PM, Sebastian Schaffert wrote:
>
>> Dear all,
>>
>> I wanted to elaborate a bit on the topic of consistency checking because I have a strong opinion on this. And maybe it helps to give understanding why I consider it only mildly interesting in practical applications ... ;-)
>>
>> I wrote:
>>
>>>
>>> schema validation
>>> -----------------
>>>
>>> This is what you call "check" and 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. ;-)
>>
>>
>> Ok, this was my statement. Back to consistency checking ... :)
>>
>> 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
>>
>>
>>
>>
>> Sebastian
>> --
>> | Dr. Sebastian Schaffert sebastian.schaffert@salzburgresearch.at
>> | Salzburg Research Forschungsgesellschaft http://www.salzburgresearch.at
>> | Head of Knowledge and Media Technologies Group +43 662 2288 423
>> | Jakob-Haringer Strasse 5/II
>> | A-5020 Salzburg
>>
>
>
--
Enrico Daga
--
http://www.enridaga.net
skype: enri-pan
Re: What's going on with reasoners (STANBOL-185)
Posted by valentina presutti <va...@cnr.it>.
Dear Sebastian, all,
I fully agree on your statement :) and thanks for the further elaboration, I find it useful.
However, this is true when you deal with the Semantic Web Scale: personally I find useless trying "to clean" data based on consistency checking
even because this would mean to promote one universal foundational model as the "right" one, which is ridiculous (imo).
In the context of IKS, and more in general in the context of application that reuse Web data in a local context
consistency checking might be useful as a feature, for example for checking if the data you would want to reuse can run well with your domain-ontology.
I think that also in this last case there is something that can be debated: how can we use consistency checking in a clever way? For example,
a reasoner that is able to identify what's the problem and show it to you by explaining it is already something useful.
It would be even better the reasoner is also able to suggest possible changes in the data you want to reuse (possibly based on some configuration) while keeping the link with the original sources.
I mean, consistency checking can be a useful feature if it is tailored to specific use cases, while I agree it is almost non-sense as a web scale problem.
Val
On Aug 31, 2011, at 5:18 PM, Sebastian Schaffert wrote:
> Dear all,
>
> I wanted to elaborate a bit on the topic of consistency checking because I have a strong opinion on this. And maybe it helps to give understanding why I consider it only mildly interesting in practical applications ... ;-)
>
> I wrote:
>
>>
>> schema validation
>> -----------------
>>
>> This is what you call "check" and 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. ;-)
>
>
> Ok, this was my statement. Back to consistency checking ... :)
>
> 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
>
>
>
>
> Sebastian
> --
> | Dr. Sebastian Schaffert sebastian.schaffert@salzburgresearch.at
> | Salzburg Research Forschungsgesellschaft http://www.salzburgresearch.at
> | Head of Knowledge and Media Technologies Group +43 662 2288 423
> | Jakob-Haringer Strasse 5/II
> | A-5020 Salzburg
>
Re: What's going on with reasoners (STANBOL-185)
Posted by Sebastian Schaffert <se...@salzburgresearch.at>.
Dear all,
I wanted to elaborate a bit on the topic of consistency checking because I have a strong opinion on this. And maybe it helps to give understanding why I consider it only mildly interesting in practical applications ... ;-)
I wrote:
>
> schema validation
> -----------------
>
> This is what you call "check" and 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. ;-)
Ok, this was my statement. Back to consistency checking ... :)
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
Sebastian
--
| Dr. Sebastian Schaffert sebastian.schaffert@salzburgresearch.at
| Salzburg Research Forschungsgesellschaft http://www.salzburgresearch.at
| Head of Knowledge and Media Technologies Group +43 662 2288 423
| Jakob-Haringer Strasse 5/II
| A-5020 Salzburg
Re: What's going on with reasoners (STANBOL-185)
Posted by Sebastian Schaffert <se...@salzburgresearch.at>.
Dear Enrico and all,
I had several discussions with Alessandro on the topic of reasoning already, and use the opportunity to summarise my points and also our conclusions for consideration here on the mailinglist.
A bit on my background: I have had a pretty deep experience in the reasoning and logics domain during my PhD (where I developed a rule-based reasoner for the Web) and as one of the main persons responsible for the FP6 project REWERSE (reasoning on the web with rules and semantics), even though I am nowadays more concerned with Linked Data and Social Semantic Web. Recently, I have implemented the reasoner of the Linked Media Framework, described here:
http://code.google.com/p/kiwi/wiki/Reasoning
1. Goal of Reasoning in Stanbol
===============================
The first thing that needs to be clarified is: why does Apache Stanbol need reasoning and what will it be used for?! Please give me concrete use cases and examples ;-)
Depending in these goals, the actual kind of reasoning needs to be decided on. Possible kinds of reasoning:
schema validation
-----------------
This is what you call "check" and 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. ;-)
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 (what you call "enrichment" below).
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.
You call this kind of reasoning "enrichment", but this is in fact in my opinion not really correct. This kind of reasoning does not really "enrich" existing information, it just explicitly materializes implicitly present knowledge that is already there.
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.
2. Reasoning API
================
Since reasoing can have so many distinctive goals, I am not sure whether it is possible or wise to develop a single reasoning API for Stanbol. It simply depends on what you want to achieve. For example:
- consistency checking will probably be in a (in-memory) session, i.e. you send your model and you want to know whether it is consistent in itself or with the existing models, but you won't store the model before it is considered finished
- instance checking and rule-based reasoning will probably operate on a more-or-less persistent representation of the data in the triple store, because conceptually it means that implicit knowledge is applied to the data to explicitly materialize it;
- reasoners are customizable, in rule-based reasoning you are even able to upload and evaluate your own rule sets on the data; your API would need to be very generic to cover this
My two cents to the reasoning discussion ;-)
Greetings,
Sebastian
--
| Dr. Sebastian Schaffert sebastian.schaffert@salzburgresearch.at
| Salzburg Research Forschungsgesellschaft http://www.salzburgresearch.at
| Head of Knowledge and Media Technologies Group +43 662 2288 423
| Jakob-Haringer Strasse 5/II
| A-5020 Salzburg
Am 30.08.2011 um 16:12 schrieb Enrico Daga:
> Hallo,
> this is to share the developments of the last three weeks around
> STANBOL-185 (Support for Jena-based reasoning services).
>
> Initial problem was:
> 1) No support for Jena
> 2) Hermit LGPL dependency (so no default reasoner with the current
> implementation that can be distributed with Stanbol)
> 3) No extendibility for off the shelf reasoning services
>
> All three points are addressed by the current version in
> branches/jena-reasoners (even if lot of things can improved).
>
> What have been implemented?
> * A /serviceapi for ReasoningServices, using SCR, and a REST endpoint
> which automatically publish all available services (in /web)
> * Base OWLApi and Jena abstract services
> * Jena RDFS,OWL,OWLMini reasoning services
> * HermiT reasoning service (this will be moved out of Stanbol, finally)
>
> At the end of this e-mail I include the content of the README.txt
> file, for your convenience, which includes some of ideas and proposal
> for improvements.
> I would really appreciate if the community can have a look at it, and
> provide some feedback.
>
> I did my best to make this api as flexible and efficient as possible,
> but I know more work must still be done in this direction (some ideas
> are below).
>
> I am going to verify the integritycheck demo with respect to this
> implementation, while it is working, I will move the code in /trunk.
>
> Thank you all
>
> Enrico
>
> -------------------------------------
>
> Description
> =============
>
> * A serviceapi for ReasoningServices, using SCR
> * Base OWLApi and Jena abstract services
> * Jena RDFS,OWL,OWLMini reasoning services
> * HermiT reasoning service
>
> * A common REST endpoint at /reasoners with the following preloaded services:
> ** /rdfs
> ** /owl
> ** /owlmini
> ** /owl2
>
> each can be accessed with one of three tasks: check,enrich,classify,
> for example:
>
> /reasoners/owl/check (the Jena owl service with task classify)
> or
> /reasoners/owl2/classify (the hermit service with task classify)
>
> Tasks description:
> * check : is the input consistent? 200 =true, 204 =false
> * classify : return only rdf:type inferences
> * enrich : return all inferences
>
> This is how the endpoint behave:
>
> GET (same if POST and Content-type: application/x-www-form-urlencoded)
> params:
> * url // Loads the input from url
> * target // (optional) If given, save output in the store (TcManager)
> and does not return the stream
>
> for example:
> $ curl "http://localhost:8080/reasoners/owl2/classify?url=http://xmlns.com/foaf/0.1/"
>
> POST [Content-type: multipart/form-data]
> * file // Loads from the input stream
> * target // (optional) If given, save output in the store
> (TcManager) and does not return the stream
>
> Other parameters can be sent, to support inputs from Ontonet and Rules:
> These additional parameters can be sent:
> * scope // the ID of an Ontonet scope
> * session // The ID of an Ontonet session
> * recipe // The ID of a recipe from the Rules module (only with
> OWLApi based services)s
>
> Supported output formats:
> Supported return formats are all classic RDF types (n3,turtle,rdf+xml)
> and HTML. For HTML the returned statements are provided in Turtle
> (Jena) or OWL Manchester syntax (OWLApi), wrapped in the stanbol
> layout. It would be nice to have all in the latter, which is very much
> readable (todo).
>
> Todo
> =============
> * Support for return types json and json-ld (need to write jersey writers)
> * The front service actually returns only inferred statements. It is
> useful also to have the complete set of input+inferred statements
> * Support for long-term operations. This is crucial for reasoning
> tasks, since it can take some time with large graphs. This is needed
> in general for Stanbol, something like "Stanbol Jobs".
> * Decouple input preparation from the rest endpoint resource, creating
> something like an InputProvider SCR api; each InputProvider is bound
> to a set of additional parameters.
> This have several benefits:
> ** Remove of additional optional parameters, bound to specific input
> sources from the default rest api (ex, session, scope, recipe)
> ** Remove dependencies to ontonet, rules and other modules which are
> not needed for standard usage. They could be implemented as
> InputProvider/s, bound to specific parameters.
> ** Allow the addition of other input sources (for example 'graph',
> 'entity' or 'site')
> * Implement a Custom Jena ReasoningService, to use a Jena rules file
> or a stanbol recipe (when implemented the toJena() functionality in
> the rules module) from configuration. This could be done as multiple
> SCR instance, as it is now for entityhub sites, for example.
> * Provide a validation report in case of task CHECK (validity check).
> * Implement a progress monitor, relying on the jena and owlapi apis,
> which have this feature, for debugging purpose
> * Implement a benchmark endpoint, relying on OWL manchester syntax, to
> setup benchmark tests in the style of the one made for the enhancer
> * Implementing owllink client reasoning service
> * Implement additional data preparation steps, for example to
> implement a "consistent refactoring" task. For example, giving a
> parameter 'refactor=<recipe-id>' the service could refactor the graph
> before execute the task.
> * Implement off the shelf reasoning services (for example, targeted to
> resolve only owl:sameAs links)
>
> General issues
> =============
> The main problem is performance, which decrease while the input data
> grows, in some cases dramatically. This could be faced (IMHO), in two
> directions:
> * Improve input preparation. In particular, the preparation of input
> form ontonet scope/session needs to stream the ontologies, in cases of
> more input (url provided) twice!, and this have some drawback on
> performance.
> * Support long-term operations, to start the process from the REST
> call and then ping it's process through a dedicated endpoint
>
> Notes (to be known)
> =============
> Differences between Jena and OWLApi services:
> * CHECK have different meaning with respect to the reasoning service
> implementation
>
>
>
> Examples
> =============
> #
> # Basic GET calls to the reasoning services.
> # Send a URL and the service will return the inferred triples
> #
> # Classify the FOAF ontology, getting it from the web using the Jena
> OWL reasoner, result in turtle
> curl -v -H "Accept: application/turtle"
> "http://localhost:8080/reasoners/owl/classify?url=http://xmlns.com/foaf/0.1/"
>
> # Classify the FOAF ontology, getting it from the web using the Jena
> OWL reasoner, result in n3
> curl -v -H "Accept: text/n3"
> "http://localhost:8080/reasoners/owl/classify?url=http://xmlns.com/foaf/0.1/"
>
> # Enrich the FOAF ontology, getting it from the web using the Jena
> RDFS reasoner, result in rdf/xml
> curl -v -H "Accept: application/rdf+xml"
> "http://localhost:8080/reasoners/owl/classify?url=http://xmlns.com/foaf/0.1/"
>
> # Check consistency of the FOAF ontology, getting it from the web
> using the Jena OWL reasoner, result in turtle
> curl -v "http://localhost:8080/reasoners/owl/check?url=http://xmlns.com/foaf/0.1/"
>
> # Check consistency of the FOAF ontology, getting it from the web
> using the Hermit OWL2 reasoner, result in turtle
> curl -v "http://localhost:8080/reasoners/owl2/check?url=http://xmlns.com/foaf/0.1/"
>
> # Trying with an ontology network (large ontology composed by a set of
> little ontologies connected through owl:import statements)
> curl -v "http://localhost:8080/reasoners/owl2/check?url=http://www.cnr.it/ontology/cnr/cnr.owl"
> # or
> curl -v "http://localhost:8080/reasoners/owl2/enrich?url=http://www.cnr.it/ontology/cnr/cnr.owl"
>
> #
> # POST calls (send a file)
> #
> # Send the foaf.rdf file to a reasoning service and see the output
> # (get it with
> curl -H "Accept: application/rdf+xml" http://xmlns.com/foaf/0.1/ > foaf.rdf
> # )
> curl -X POST -H "Content-type: multipart/form-data" -H "Accept:
> text/turtle" -F file=@foaf.rdf
> "http://localhost:8080/reasoners/rdfs/enrich"
>
> # Save output in the triple store instead of return
> # >> Add the "target" parameter, with the graph identifier
> curl "http://localhost:8080/reasoners/owl/classify?url=http://xmlns.com/foaf/0.1/&target=example-foaf-inferred"
> # or, posting a file
> curl -X POST -H "Content-type: multipart/form-data" -F file=@foaf.rdf
> -F target=example-rdfs-inferences
> "http://localhost:8080/reasoners/rdfs/enrich"
>
>
>
> --
> Enrico Daga
>
> --
> http://www.enridaga.net
> skype: enri-pan