- From: Michael DeBellis via GitHub <sysbot+gh@w3.org>
- Date: Wed, 13 Sep 2023 14:10:51 +0000
- To: public-sdwig@w3.org
FYI, there is an issue with using SWRL. It seems that the SWRL spec doesn't support xsd:dateTimeStamp only xsd:dateTime. I used xsd:dateTime for computing the ordering of temporal instants on BFO because they didn't have a data property for the actual time of the Instant so I created one and used xsd:dateTime. That works fine. But when I ported the SWRL rules to the Time ontology, I changed them to use the inXSDDateTimeStamp data property. What confuses me is that it's one of those things where it isn't even breaking consistently. When I ported the rules from BFO to Time I also copied over test data I had created in terms of sample Instants and Interfals. What's odd is that (except for one instant which I hadn't noticed until this morning) that all seemed to work fine and the rules worked making the comparisons on xsd:dateTimeStamp. That's this ontology: https://github.com/mdebellis/Time-Ontology-With-SWRL-Rules However, when I loaded the test data specifically for the Time ontology it didn't work at all. I ran Pellet (that's the reasoner I use in Protege for SWRL) and it just hung, saying "Reasoner initializing" I asked the Protege User Support Group for help and Martin (I think he's the main developer for the SWRLTab) said that the SWRL Spec: https://www.w3.org/submissions/SWRL/ only support xsd:dateTime not xsd:dateTimeStamp. I'm including his reply below. The error he mentions was because I used a rule engine called Drools to see if I could get more info on why Pellet was just hanging. There are two SWRL implementations in Protege, one works by just running the Pellet reasoner, which is what I prefer because doing it that way makes SWRL inferences part of the reasoner inferences so you get the explanation capabilities for a SWRL rule as you would any other reasoner inference. The Drools rules engine is what Martin and others have used for their extensions to the SWRL spec to implement the full Allen model. Drools just does inferences independent of the Reasoner so the inferences look like user assertions which is the main reason I prefer using Pellet. But I tried using Drools when Pellet was just hanging (just to see if I could understand what the problem was) and got an error that I now think was caused because the SWRL builtins don't support comparing two xsd:dateTimeStamps only xsd:dateTime (although oddly it worked for my test data). Do you think it would be possible to change the range of the property: inXSDDateTimeStamp to 'xsd:dateTime or xsd:dateTimeStamp' or to add a new property called inXSDDateTime? Otherwise, I don't think SWRL will work to implement the reasoning about the Allen relations between Intervals based on the dateTime of their Instants. Should I create a change request for a property that supports xsd:dateTime? Let me know if you have any suggestions, it's almost working and I'm pretty confident it will all work except for the problem with SWRL and xsd:dateTimeStamp. Let me know what you suggest. Here is Martin's reply to my question: -------------------- Begin Included Message --------------------------------------- Michael, I think I found the source of the issue in the SWRLAPI. The core SWRL built-ins implemented by the SWRLAPI do not support the xsd:dateTimeStamp datatype. The core built-ins work with temporal types xsd:time, xsd:date, xsd:dateTime and xsd:duration only. Hence, the datatype error thrown by the built-in. This, I think, reflects the SWRL specification, which does not mention this type [1]: swrlb:greaterThan (from XQuery op:numeric-greater-than, op:compare, op:yearMonthDuration-greater-than, op:dayTimeDuration-greater-than, op:dateTime-greater-than, op:date-greater-than, op:time-greater-than) (I also noticed that the core swrlb:greaterThan and swrlb:lessThan SWRLAPI built-ins do not handle temporal types correctly; the swrlb:equal built-in does. I will generate a new release (2.1.1) shortly that will address this omission.) I do not know if Pellet correctly handles the xsd:dateTimeStamp datatype. Martin [1] http://www.daml.org/2004/04/swrl/builtins.html On Mon, Sep 11, 2023 at 10:17 PM Rob Atkinson ***@***.***> wrote: > The SPIN community seems to have migrated to SHACL as an approach, and the > OGC has git actions toolkits we can set up to validate examples using > pySHACL. This doesnt mean we cant use other rules languages, but we'd need > a git action as an example to integrate this into our workflows. > Alternatively can SHACL be used? > > NB Reasoning/entailment preprocessing is feasible - SHACL-AF can be used > for this. > > — > Reply to this email directly, view it on GitHub > <https://github.com/w3c/sdw/issues/1434#issuecomment-1714987122>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AD7TPBBVIW4PZLIUYFSTSMTXZ7V7HANCNFSM6AAAAAA4QQKJT4> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> > -- GitHub Notification of comment by mdebellis Please view or discuss this issue at https://github.com/w3c/sdw/issues/1434#issuecomment-1717713317 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 13 September 2023 14:10:54 UTC