Re: Detecting cycles in OWL

Dear Holger,

I didn't want to enter the discussion so far because I did not want to 
"hijack" this threat, but I enjoy these discussions too much ;).

> 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.

I fully agree and hope that we learn from each other here :)

> 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. 

N3 is not a subset of SPARQL (in terms of expressiveness). Just like 
SPARQL, N3 has built-ins (see for example the built-ins of Cwm which are 
also implemented in EYE [2]). We are currently discussing in our 
community group [3,4] which built-ins should be part of a possible 
standard. Of course it depends of the choices made in the group, but so 
far it looks  like at least with the built-ins of EYE [5] we can fully 
support SPARQL built-ins. (I am aware that this statement does not prove 
anything, I promise to provide a proof as soon as possible, I am 
currently working on that. Of course finding limits would be interesting 
here as well.)

On the other hand, there are many aspects in which N3 goes beyond 
SPARQL. You can for example derive new rules or act on graphs. In that 
sense N3 is more expressive than SPARQL.

So, in my opinion there is still a lot work to be done to fully 
understand the relation of N3 and SPARQL (or also SPIN) and I am looking 
forward to progressing here.

> Whether engines can do backward or forward chaining is not necessarily 
> a characteristic of the language but can be regarded as an 
> implementation detail. 

Here, I agree with you. However, I like that N3 at least provides the 
option to write the arrows in both directions which can be understood as 
an indication which reasoning could be applied. From the model theoretic 
point of view both arrows have the same meaning, but of course engines 
are free to apply the reasoning mechanisms they want.

> 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).

I don't know SPIN well enough to comment here. Is there a particular 
engine you would recommend to really compare?  It might be good to 
translate  between the languages and test on reasoners to better understand.

>
> 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.

What could be done easily is: we could have an N3-notation for the 
SPARQL functions you can have in the filter. But I guess you would 
prefer to get further? How would you then do it? I really like in N3 and 
SPARQL that they respect the semantics of RDF. I am afraid that by 
representing SPARQL in Turtle we could get issues with that.  But maybe 
that is not what you had in mind?

> 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.

That is an interesting thought. We will have look into these functions 
as we are discussing N3 built-ins at the moment.

Kind regards,
Doerthe


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

[2] https://www.w3.org/2000/10/swap/doc/CwmBuiltins

[3] https://github.com/w3c/N3

[4] https://www.w3.org/community/n3-dev/

[5] http://eulersharp.sourceforge.net/2003/03swap/eye-builtins.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
>>>
>>>
>>>
>>
>>
>
-- 
Dörthe Arndt
Researcher Semantic Web
imec - Ghent University - IDLab | Faculty of Engineering and Architecture | Department of Electronics and Information Systems
Technologiepark-Zwijnaarde 122, 9052 Ghent, Belgium
t: +32 9 331 49 59 | e: doerthe.arndt@ugent.be

Received on Wednesday, 29 April 2020 13:54:50 UTC