N3-rule-based machine reasoning [was: Re: Detecting cycles in OWL]

Hi Holger,

Concerning the depiction of N3 as a subset of SPARQL, the following Venn 
diagram shows rather the opposite.
If this might not be valid anymore (for e.g. SPARQL), could you propose 
an update?

You could have a look at e.g. following N3-rules.
I would be interested in how to implement this in SPARQL (I did not 
+ proof (cf. Semantic Web layer cake graphic), absent in SPARQL (AFAIK)

We can discuss this further also outside this channel (and publish 
possible outcome later).

Kind regards,

On 29.04.20 04:24, Holger Knublauch wrote:
> 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 12:18:20 UTC