RE: Detecting cycles in OWL

Hi Holger,



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.


The original draft<https://www.w3.org/DesignIssues/Notation3> and subsequent W3C Team Submission<https://www.w3.org/TeamSubmission/n3/> should give you a pretty good idea of what N3 entails. The current W3C standardization effort does not aim to drastically alter N3—but rather tweak the syntax, resolve certain ambiguities, formalize the semantics and agree upon a core set of builtins.



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.



Of course, it is true that one can use query languages (albeit part of SPIN or SHACL) to mimic aspects of a rule language. These languages were designed with a specific goal in mind, and they are quite good at it (I quite actually like SPIN!). IMO it becomes a bit awkward when trying to extend them beyond their core purpose. The concept of "magic properties" is a suitable example here; they represent useful functionality for defining class behavior in SPIN, but it would be difficult to extend them towards fully-fledged rules. It's not impossible of course. One could expand the SPIN vocabulary to include general rule-based behavior, possibly even supporting explicit universal / existential quantification, embedding rules within other rules, ... But you will, ironically, end up re-inventing other rule languages such as SWRL or N3, and the end result will arguably not be as concise.



This is more of an academic argument, but note that N3 is meant to be a general assertion and logic language; since it is able to represent logical implications, it can be used to represent what more practically oriented people (such as myself) consider IF-THEN rules via modus ponens.



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.


I forgot to raise this before but N3 is not exactly starting from scratch—TBL wrote the draft spec 15 years ago and its current implementations (Cwm, Eye) have been around for well over a decade (see here<http://eulersharp.sourceforge.net/2003/03swap/eye-builtins.html> for the 500+ builtins that Eye currently supports!).


I think you raise a very interesting point about establishing an RDF vocabulary for declaring new functions / builtins (?). Note that N3 builtins are represented as RDF terms and may be placed at any position within a triple, whereas SPARQL builtins are restricted to certain clauses AFAIK (filter or bind clauses, I think?). Nevertheless, I think that this is certainly something that is worth expanding on—thinking about common builtins for dates and timestamps, math, strings, security, URIs, ..





William



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

>>>>

>>>>

>>>>

>>>

>>>

>>