Re: Detecting cycles in OWL

Ok this part of the thread may be morphing into a discussion of N3 rules 
in particular. I didn't mean to start a "fight" here and of course there 
are reasons for the design of each language, and people will defend 
that. It's good to have diversity. It's also good to have discussions 
that go across language boundaries.

Correct me if I am completely wrong and I have not extensively studied 
N3 rules. But judging by examples at [1] to me the expressiveness of N3 
Rules looks like a subset of SPARQL. Whether engines can do backward or 
forward chaining is not necessarily a characteristic of the language but 
can be regarded as an implementation detail. Of course, if you select a 
simple-enough subset of SPARQL then chaining becomes feasible too. In 
fact SPIN did have magic properties that were a simple form of backward 
chaining. (Aside, many scenarios of rules are rather for 
transformations/mappings, and no sophisticated chaining is needed apart 
from running rules in a dedicated order).

So one thought is whether N3 rules could be redefined by embedding a 
subset of SPARQL syntax into Core N3 (Turtle). The benefits of reusing 
the SPARQL syntax are the numerous existing engine implementations, 
editing tools and learning material for SPARQL.

As a historic note, OWL was intentionally limited to a subset of its 
potential design space because that subset of logic had desirable 
computational complexity and supported particular algorithms. However, 
with the benefit of hindsight, I believe many people agree that the 
subset that was chosen for OWL excluded too many real-world use cases. 
Designing N3 to reflect particular algorithmic possibilities may carry 
similar risks.

You also highlight use cases such as temporal reasoning across calendar 
formats etc. The SPARQL standard defines some but not all necessary 
functions, but there are collections of extension functions such as 
GeoSPARQL and most implementations include extension points to add more 
functions. I do wonder whether N3 could simply reuse the same, already 
existing infrastructure.

Holger

[1] http://eulergui.sourceforge.net/rules-examples.html


On 29/04/2020 10:59, Hans wrote:

> Hi Holger,
>
> I tend to disagree.
> In my experience SPARQL is less powerful than N3-rule-based machine 
> reasoning (also depending on the reasoner of course :).
> Every query is a kind of 'dead end rule', whereas N3-rules can pass 
> the conclusion to other rules during a same reasoning session.
> A handy combination of forward and backward rules is possible.
> To try to make out of SPARQL a full-blown rule system is not that 
> senseful, because it is not designed for that purpose IMHO.
> A strong real world use case for N3-rule-based machine reasoning is 
> temporal reasoning, implying e.g. unification of different calendars 
> (Gregorian, Julian, proleptic Julian and other, with all the quirks) 
> with usage of Julian Day Number, AFAIK beyond the capability of SPARQL.
> This case uses e.g. a cascade of backward rules triggered from within 
> other rules.
> It is at the end comparing apples with lemons I think.
>
> Kind regards,
> Hans
>
> On 29.04.20 01:53, Holger Knublauch wrote:
>> On 28/04/2020 20:32, Mikael Pesonen wrote:
>>
>>> Thanks!
>>>
>>> It seems that OWL reasoning has quite limited real world use: 
>>> checking consistency of model and data, and deducting new facts for 
>>> search etc.
>>
>> The lack of expressiveness of OWL has long been a problem for us and 
>> many (if not most) of our customers. Even if you can express 
>> something in OWL, it often becomes convoluted and non-intuitive. With 
>> SPARQL (CONSTRUCT/INSERT) you can do so much more, including the use 
>> cases that OWL was supposed to solve. SPIN and later SHACL were 
>> partially created to declaratively link SPARQL queries with the 
>> domain ontologies.
>>
>> On N3 rules (mentioned in this thread), I wonder whether this 
>> shouldn't simply reuse SPARQL, esp for the built-ins. Why reinvent 
>> the wheel?
>>
>> Holger
>>
>>
>>
>
>

Received on Wednesday, 29 April 2020 02:25:16 UTC