Re: Detecting cycles in OWL

Hi,

sorry I dropped the ball on this topic. Too many other things came up 
and it would require much more background reading for me to have a 
complete picture.

Before I bow out of this topic, I just wanted to clarify three points 
(collected from various mails here)

a) It's too hard to compare SPARQL and N3 rules while there is no real 
specification of what this new N3 version is supposed to look like. Thus 
any blanket statements that N3 or SPARQL is better for this and that are 
speculative. It is clear though that both languages would have slightly 
different strengths.

b) Rule chaining was mentioned. In SPIN (and SHACL-AF) we are "solving" 
this by allowing user-defined SPARQL functions or, in the case of SPIN 
magic properties, that have another SPARQL query as their body. This is 
a simple "manual" way of implementing computations that require other 
computations to happen first. And yes, this can express recursion. This 
is not part of the SPARQL standard, yet SPARQL explicitly offers an 
extension point to add new functions. I believe there would be a lot of 
value in an established RDF vocabulary to declare new functions (in 
various languages). For SHACL Advanced Features we included sh:Function, 
and they can declaratively either have another SPARQL query as body, or 
(in SHACL-JS) a JavaScript function against some standard API. This 
extensibility is platform independent so that an N3 implementation could 
potentially reuse the same function libraries, avoiding duplicate work 
and overlapping identifiers.

c) The general question to me remains whether there are sufficient 
advantages of starting from scratch, vs working with the SPARQL 
community to define extensions that would allow N3 use cases to be 
covered by SPARQL 1.2. SPARQL is widely implemented and well 
established. I don't think there are fundamental differences that would 
prevent SPARQL to evolve into coverage of the N3 use cases. OWL has 
various profiles. Likewise there could be a SPARQL profile that has 
certain computational guarantees for rule execution.

Holger


On 29/04/2020 23:54, Doerthe Arndt wrote:
> 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
>>>>
>>>>
>>>>
>>>
>>>
>>

Received on Sunday, 10 May 2020 23:55:21 UTC