Jena Inferencing

[Andriy Sokolov]

Hallo!

I try to use Jena (OWL_DL_MEM_RULE_INF) + Pellet (incl. DL)
inferencing to check circles that could be
in a ontology, produced through a particular property P that has types
owl:TransitiveProperty and owl:IrreflexiveProperty. Jena
does generate new P's. My problem is, that it
generates also for a property P2 with range xsd:unsignedInt additional
ranges such xsd:desimal, short and so on, so I become an inconsistency
warning from Pellet. How do I avoid this new ranges?
I chain this 2 inference machines and use a loop. Without loop new P
and P2 both will not be generated.

Thanks,
Andriy

[Andriy Sokolov]

I become such a message from Pellet:

Explanation for the inconsistent ontology:
Axioms:
( P2 rdfs:range xsd:unsignedLong )

( P2 rdfs:range xsd:decimal )

( P2 rdfs:range xsd:short )

( P2 rdfs:range xsd:unsignedInt )

( P2 rdfs:range rdfs:Resource )

( P2 rdfs:range xsd:long )

( P2 rdfs:range xsd:unsignedShort )

( P2 rdfs:range xsd:nonNegativeInteger )

( P2 rdfs:range xsd:integer )

( Instance_1 P2 10000 )

( P2 rdfs:range xsd:int )

[Scott Henninger]

Andriy; Standard RDFS/OWL engines do not allow you to suppress rules.
You get what the inference engine gives you. One suggestion is to use
TopSPIN inferences. Import TopBraid/SPIN/owlrl-all.rdf to run all OWL
2 inferences. This implements the OWL 2 RL standard. Configure the
inference engine to run TopSPIN. Then run inferences.

If some of the OWL RL rules are not needed, then import owlrl.rdf.
Each OWL 2 RL rule is defined as a SPIN template in owlrl.rdf, using
the name defined in the OWL 2 standard. Use the template to add each
rule to owl:Thing (recommended, but can be added to any class
definition). Use the "Create from SPIN template wizard" from
spin:rule to choose the OWL 2 rule you want to use in the model.

In addition to this flexibility, you can easily add new rules for
inferencing by creating SPIN rules. This allows one to run OWL
inferences + rules in a single format and in a single inference step.

Future versions of Composer will have built-in rule sets for common
profiles, such as RDFS, RDFS+, SKOS, etc.

-- Scott

[Rita Marnau]

Hi everyone,

for my thesis I compare different technologies to realize constraint checking for ontologies.
I am currently interested between the difference between SPARQL and SWRL/SQWRL.
In the FAQ (http://spinrdf.org/faq.html) it is said that " SPIN is more expressive than SWRL, because SPARQL has various features such as UNIONs and FILTER expressions"

In the Protege Mailinglist, the opposite is affirmed.
(https://mailman.stanford.edu/pipermail/protege-owl/2009-September/012148.html)
"SPARQL can be used to query OWL ontologies if they are serialized as  RDF triples but has no understanding of the semantics associated with those triples."
Martin O'Connor gives an example that can be expressed in SQWRL but not in SPARQL.

Now, I am lost. Is there a good reference for the comparison between SPARQL/SWRL/SQWRL ?
Have you an example for the statement, that SPARQL is more expressive than SWRL ?

Thanks a lot.

Rita

[Irene Polikoff]

Rita,

 

Martin’s response in the e-mail thread you pointed out is as follows:

 

> Hi Martin,

> 

> can you give me an example in pseudo? what is a common swrl query 

> that cant be done by sparql?

 

Assume the following structure:

 

Class A

Class B subclassof A

Individual z type B

 

SPARQL:  ?i rdf:type A   returns nothing

SQWRL:   A(?i) => sqwrl:select(?i)  return z

 

That is because SPARQL works only on the literal RDF representation 

and doesn't do any inference.

 

Martin’s statement is not about an ability to express a rule in SPIN versus SWRL, but rather about an ability to use SPARQL to get the desired results from the example query. The rule that helps to produce the desired result is equally simple in either SPARQL or SWRL. It says that if :i a :B and :B rdfs:subClassOf :A, then :i a :A. This is one of the rules implementing RDFS inferencing.  

 

But, in any case, Martin’s statement is incorrect. You can test this out yourself. Simply run a SPARQL query with currently configured inferences. There is a special icon in the SPARQL view of TBC (next to Execute SPARQL icon).

 

The method of achieving these results with SPIN is pretty much the same as it is with SQWRL. When executing SQWRL query, first SWRL inference rules are taken into account/executed. This is why running SQWRL requires a rule engine, currently Jess.

 

If you study SPARQL syntax and SWRL syntax, I believe, you should be able to come up with the CONSTRUCT queries not directly expressible in SWRL. By “not directly” I mean that you will need to add a lot of extra classes to your ontology just to achieve some of the same results in SWRL.

 

Having said this, in my view, the strongest advantages of SPIN are:

 

Skills: It is SPARQL, developers will need to know SPARQL to work with the RDF data. Expressing rules in SPARQL means they do not need to learn an additional rule language.

Supported platforms: It is SPARQL, all RDF databases support SPARQL natively. Expressing rules in SPARQL means that there is no need to add an additional rule engine into the application architecture. It also means that rules can be executed by the database directly, no need to load the data into Jess (or some other rule engine) for execution.

Community: SWRL has some community around it because it used to be on a standards track and there was no other standard compliant alternative for rules in RDF. SWRL is no longer on a standard track. With this, its use will continue to diminish over time. SPARQL, on the other hand, has a strong and growing community of users.

 

Regards,

 

Irene

--
You received this message because you are subscribed to the Google
Group "TopBraid Suite Users", the topics of which include TopBraid Composer,
TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN.
To post to this group, send email to
topbrai...@googlegroups.com
To unsubscribe from this group, send email to
topbraid-user...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/topbraid-users?hl=en

[Scott Henninger]

Rita; I'm not aware of any comparisons of SPARQL and SWRL. You might
check W3C sources. Please note that SWRL never made it past a W3C's
submission (http://www.w3.org/Submission/SWRL/) and is a consideration
of the current RIF working group. SWRL is not a W3C recommendation.
Composer does support SWRL - see > Developing Ontologies > Semantic
Web Standards > SWRL.

There are not any queries "that can be expressed in SQWRL but not in
SPARQL". The main difference is that SWRL is designed to understand
OWL semantics. This can easily be replicated in SPARQL by running the
query over triples inferred by an RDFS or OWL reasoner. In addition,
SPARQL queries can be created to make the inferences.

I don't know about the example you cite, but let's take this one:

Class A
Class B subclassof A
Individual z type B

... and you want to get that the type of Z is both A and B. This can
be done with SPARQL:

Method 1: Run inferences and query. In Composer, turn on "Use
Currently Configured Inferences" in the SPARQL view and execute the
query:
SELECT *
WHERE {?i rdf:type A}

Method 2: Run a query to find all individuals subsumed by A :
SELECT *
WHERE {?cls rdfs:subClassOf* unnamed2:ClassA .
?i rdf:type ?cls}

An advantage here is that inferences do not need to be executed. The
query computes the subclass "inference" from the data.

In general SPARQL will be more expressive because it is a query
language, not an inference language for RDFS/OWL. Since RDFS and OWL
are a small part of the possible data structures one may want to use,
any general query language will be more general. SWRL does allow for
triple patterns, but lacks other features for querying triples, such
as OPTIONAL, FILTER, UNION, etc. SPARQL 1.1 adds more, such as
aggregates and updating the data.

-- Scott

On Jun 2, 11:21 am, Rita Marnau <r...@informatik.uni-kiel.de> wrote:
> Hi everyone,
>
> for my thesis I compare different technologies to realize constraint
> checking for ontologies.
> I am currently interested between the difference between SPARQL and
> SWRL/SQWRL.
> In the FAQ (http://spinrdf.org/faq.html) it is said that " SPIN is more
> expressive than SWRL, because SPARQL has various features such as UNIONs
> and FILTER expressions"
>
> In the Protege Mailinglist, the opposite is affirmed.

> (https://mailman.stanford.edu/pipermail/protege-owl/2009-September/012...)

> "SPARQL can be used to query OWL ontologies if they are serialized as  

> RDF triples but has no understanding of the semantics associated/ /with
> those triples/."
> /Martin O'Connor gives an example that can be expressed in SQWRL but not

[Andriy Sokolov]

Thanks Scott, ill try it out!

Best regards,
Andriy

[Holger Knublauch]

On Jun 3, 2010, at 2:21 AM, Rita Marnau wrote:

Hi everyone,

for my thesis I compare different technologies to realize constraint checking for ontologies.
I am currently interested between the difference between SPARQL and SWRL/SQWRL.
In the FAQ (http://spinrdf.org/faq.html) it is said that " SPIN is more expressive than SWRL, because SPARQL has various features such as UNIONs and FILTER expressions"

In the Protege Mailinglist, the opposite is affirmed.
(https://mailman.stanford.edu/pipermail/protege-owl/2009-September/012148.html)
"SPARQL can be used to query OWL ontologies if they are serialized as  RDF triples but has no understanding of the semantics associated with those triples."
Martin O'Connor gives an example that can be expressed in SQWRL but not in SPARQL.

Hi Rita,

in addition to the details provided by Irene and Scott, you may want to ask the Protege people again, pointing to our responses if needed. The false statement that SPARQL cannot be used with OWL semantics is being repeated again and again, and is often stated to defend the need for SWRL. SWRL is really unnecessary nowadays, and will hopefully disappear over time. SPARQL is a W3C standard syntax that is more expressive and better supported by native RDF stores.

Also note that SPARQL 1.1 will contain property path expressions such as rdfs:subClassOf* that will allow you to directly simulate many aspects of OWL reasoning, even without stacking SPARQL on top of an OWL inference engine.

Finally, a huge advantage of SPIN is that it supports user-defined SPARQL functions and magic properties, that greatly extend the expressivity of SPIN over normal SPARQL, including recursive rules.

Regards,

Holger

[Rita Marnau]

Wow. I am very impressed about the support here.

The false statement that SPARQL cannot be used with OWL semantics is being repeated again and again, and is often stated to defend the need for SWRL

That is what I've found exactly in the Protege Mailing List. I think you are right.
When you look at the actual layer cake of the semantic web, there is no swrl at all. [1]
I am curious if we will see SPIN one day around there.

The second argument of M. Connor was, that SPARQL has no sound semantics [2].

"What's worse, SPARQL does not even have formally sound semantics
in terms of RDF. [..] there
are no guarantees about the soundness of results returned by a SPARQL
query even on an RDF ontology."

I there a de facto standard for the SPARQL semantics, used by each reasoners?
 Or do you just trust in the reasoners you choosed?

Thanks again. You really help me! :) 

 Rita

[1]http://www.w3c.it/talks/2009/athena/images/layerCake.png
[2]https://mailman.stanford.edu/pipermail/protege-owl/2007-April/001776.html

[Holger Knublauch]

Hi Rita,

On Jun 4, 2010, at 2:24 AM, Rita Marnau wrote:

The second argument of M. Connor was, that SPARQL has no sound semantics [2].

"What's worse, SPARQL does not even have formally sound semantics
in terms of RDF. [..] there
are no guarantees about the soundness of results returned by a SPARQL
query even on an RDF ontology."

I there a de facto standard for the SPARQL semantics, used by each reasoners?
 Or do you just trust in the reasoners you choosed?

I believe he might be referring to the treatment of blank nodes in RDF versus SPARQL. This is a general issue with RDF and it looks like it will be addressed by W3C in the future. See for example

http://www.w3.org/2009/12/rdf-ws/papers/ws05
http://www.w3.org/2009/12/rdf-ws/papers/ws23

With regards to SPARQL, this is however only a theoretical problem, because the SPARQL engines that I know about all implement the semantics that blank nodes are simply nodes without a URI, and this is consistent with what most people expect in practice. So in a sense, SPARQL already implements the "right" semantics, while the underlying problem will likely be addressed on the RDF layer in the future.

Having said this, I would welcome real-world scenarios where the "lack of guarantees about the soundness" of SPARQL is affecting anyone. I have never ever had such a case. Maybe Martin knows more. Note that his message you have quoted is three years old. The community has moved on. There are dozens of SPARQL implementations, and one SQWRL implementation.

Regards,

Holger

[Scott Henninger]

Rita, in addition, a direct answer to:

<<I there a de facto standard for the SPARQL semantics, used by each
reasoners? >>

...is found in the W3C Recommendation at http://www.w3.org/TR/rdf-sparql-query/

And the SPARQL 1.1 Working Draft, updated 2 days ago, is at
http://www.w3.org/TR/sparql11-query/

-- Scott

http://www.w3.org/TR/sparql11-query/

On Jun 3, 10:44 pm, Holger Knublauch <hol...@topquadrant.com> wrote:
> Hi Rita,
>
> On Jun 4, 2010, at 2:24 AM, Rita Marnau wrote:
>
> > The second argument of M. Connor was, that SPARQL has no sound semantics [2].
>
> > "What's worse, SPARQL does not even have formally sound semantics
> > in terms of RDF. [..] there
> > are no guarantees about the soundness of results returned by a SPARQL
> > query even on an RDF ontology."
>
> > I there a de facto standard for the SPARQL semantics, used by each reasoners?
> >  Or do you just trust in the reasoners you choosed?
>
> I believe he might be referring to the treatment of blank nodes in RDF versus SPARQL. This is a general issue with RDF and it looks like it will be addressed by W3C in the future. See for example
>

> http://www.w3.org/2009/12/rdf-ws/papers/ws05http://www.w3.org/2009/12/rdf-ws/papers/ws23