Re: Detecting cycles in OWL

> On 13. May 2020, at 09:18, Franconi Enrico <franconi@inf.unibz.it> wrote:
> 
> Hi Jos,
> my observation is related to the use of N3 with RDF(S) (or OWL) semantics. 
> I was just asking how the semantics of special predicates is considered within the f.o. understanding of N3. 
> In f.o., the semantics of the RDF(S) is specified with a reduction into T(s,p,o) atoms.
> cheers


A quick question from the sideline: can T(s,p,o) be understood as some kind of reification?

Thomas


> --e.
> 
>> Il giorno 13 mag 2020, alle ore 01:51, Jos De Roo <josderoo@gmail.com> ha scritto:
>> 
>> Dear Enrico,
>> 
>> You say "triple semantics should always be seen in FO as T(s,p,o) and not p(s,o)"
>> but in EYE we do exactly the opposite i.e. always p(s,o) and only when p is a variable
>> we internally compile it to exopred(p, s, o) and do just in time translation to p(s,o) as
>> can be seen in https://github.com/josd/eye/blob/master/eye.pl .
>> 
>> Kind regards,
>> Jos
>> 
>> -- https://josd.github.io/
>> 
>> 
>> On Tue, May 12, 2020 at 3:23 PM Franconi Enrico <franconi@inf.unibz.it> wrote:
>> Hi,
>> just few very quick comments/questions.
>> Obviously, given the preliminary status of N3, these may or may not have precise answers.
>>  • Is there any reference to a compatibility of N3 with W3C-RIF (necessary, IMHO), the standard about rules by W3C, which also includes profiles (called dialects)?
>>  • I believe that forward vs backward reasoning may make a difference, for example if you employ a "production system" semantics (see [1]), which is probably something N3 may want to consider.
>>  • [I already made this question.] I still would like to see how the N3 rules incorporate RDF(s) semantics, i.e., how they consider the special meaning of rdf:type, rdfs/owl:subclass, rdfs/owl:subproperty, rdfs/owl:domain, range properties with either RDF(s) or OWL semantics. Having an integrated system is known to be non-trivial, and different semantic choices for the integration are possible. This was also discussed somehow in the RIF WG. This point seems to be more complex than the issue of rules + first-order ontology languages studied in the literature, given the non direct connection of RDF with first order: indeed, triple semantics should always be seen in FO as T(s,p,o) and not p(s,o). [Maybe N3 already considered all this...]
>> cheers
>> --e.
>> 
>> [1] Riccardo Rosati and Enrico Franconi. 2012. Generalized ontology-based production systems. In Proceedings of the Thirteenth International Conference on Principles of Knowledge Representation and Reasoning (KR'12). AAAI Press, 435–445.
>> 
>>> Il giorno 12 mag 2020, alle ore 14:25, William Van Woensel <William.Van.Woensel@Dal.Ca> ha scritto:
>>> 
>>> 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 and subsequent W3C Team Submission 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 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
>>> >>>> 
>>> >>>> 
>>> >>>> 
>>> >>> 
>>> >>> 
>>> >>
>> 
>

Received on Wednesday, 13 May 2020 09:35:34 UTC