Implementation of SWRL Rules for Time Ontology

[mdebellis]

I haven't used Github much so I'm not sure if this is really an issue. I just wanted people to know that I've built some SWRL rules to automate the reasoning in the Time Ontology. I also created some sample instants and intervals (based on US military history, that was the quickest way I could think of some examples of events that overlapped, contained, etc.) I'll probably write a short paper on this at some point. I've also added SWRL rules to automate the Temporal Reasoning in the Basic Formal Ontology and once I had done it for BFO it was trivial to copy/paste the test data and rules into the Time ontology. The resulting ontology can be found here: DeBellis Github Time Ontology With SWRL If you have questions or comments please email me at: mdebellissf@gmail.com

[rob-metalinkage]

Will discuss with my OGC colleagues @dr-shorthair and @avillar about setting up formal CI/CT git actions for example validation.

@dr-shorthair already defined SHACL cases we are planning to implement this way.

We are also exploring online playgrounds linking json schema, json-ld and SHACL validation with a plugin for other validators.

If you have an opensource SWRL validation tool chain in mind please drop a comment here.

[dr-shorthair]

@mdebellis thank you.

I created a set of test-cases for the relations in Time Ontology in OWL three years ago, but did not proceed to implement tests in SWRL or SHACL.
The test cases are here: https://github.com/w3c/sdw/tree/gh-pages/time/test-suite

A test suite for the proposed Extensions to the OWL-Time Ontology - entity relations is available here: https://github.com/w3c/sdw/tree/gh-pages/time-entity-relations/test-suite

[mdebellis]

Excellent. I'll try those test cases. I haven't done any rigorous testing so it is quite possible that the current SWRL rules may not cover every possible case. Also, I took one particular approach to modeling instants using the xsd:dateTimeStamp. I did that because it was essentially identical to the way BFO did it and BFO was where I started this. BTW, I talked to someone (can't remember who) a long time ago about using SWRL to implement the temporal relations in the Time ontology. At the time it seemed difficult but when I took another look after doing it in BFO, I realized the same rules should work, just changing the names of the properties. Now that I've done it, I would be interested in promoting it so that people can use it, after I do some more testing of course. Also, the biggest issue I think we'll have with SWRL is that it can be slow. It will work fine for small examples but for realistic data I'm not sure it will scale. Of course it depends on the implementation of SWRL. The only implementations I've used are those in Protege: 1) The implementation using DROOLS. This already has the Allen temporal model because the developers at Stanford used Drools to extend the basic SWRL temporal builtins with functionality more or less equivalent to the Time ontology. Actually, I think significantly less than the Time ontology but still fairly expressive because it implements the Allen model: https://github.com/protegeproject/swrlapi/wiki/ModellingTime 2) Running SWRL using the Pellet reasoner. That's what I've been using. I like this better other things being equal because the Drools engine makes inferences independent of whatever reasoner you are using So the SWRL inferences end up looking like user assertions and don't have the explanation capability you get when you use Pellet to make SWRL inferences. With Pellet SWRL inferences are just one more type of reasoning that the reasoner does... which I think is what they had in mind with the SWRL spec originally. A while ago I was going to write some SPARQL transformation rules to transform SWRL to SPARQL SPIN rules but I saw someone had already done this. After I do some testing I'm going to dig up that paper and see if his approach will work on the rules I wrote. If they do, I think that would be much more efficient than SWRL for medium to large ontologies. I'm also working on some other projects right now so I'll just be working on this as a low priority when I need a break from my main project. But if you have suggestions, feedback, etc. please let me know. Cheers, Michael https://www.michaeldebellis.com/blog

…

On Sun, Sep 10, 2023 at 9:31 PM Simon Cox ***@***.***> wrote: @mdebellis <https://github.com/mdebellis> thank you. I created a set of test-cases three years ago, but did not proceed to implement tests in SWRL or SHACL. The test cases are here: https://github.com/w3c/sdw/tree/gh-pages/time/test-suite — Reply to this email directly, view it on GitHub <#1434 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD7TPBGWFOOKTGKBTTZZAZ3XZ2HYLANCNFSM6AAAAAA4QQKJT4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[rob-metalinkage]

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.

[mdebellis]

Thanks. Didn't know that about SPIN and SHACL. i need to understand SHACL better. I've used it to define basic constraints but not as a way to do this kind of reasoning.

…

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 <#1434 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD7TPBBVIW4PZLIUYFSTSMTXZ7V7HANCNFSM6AAAAAA4QQKJT4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[mdebellis]

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 <#1434 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD7TPBBVIW4PZLIUYFSTSMTXZ7V7HANCNFSM6AAAAAA4QQKJT4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[dr-shorthair]

When we revised the 2006 OWL-Time for the 2017 version, switching to xsd:dateTimeStamp was considered to be a very useful step forward. The reasons are obvious - without timezone information, none of the topological relationships between temporal entities in the same 24 hour period can be determined. Clearly the tools have not kept up, but the requirement is clear. The datatype builds it into the language infrastructure. If the datatype was relaxed to xsd:dateTime then there would need to be external checks.

[mdebellis]

When we revised the 2006 OWL-Time for the 2017 version, switching to xsd:dateTimeStamp was considered to be a very useful step forward. The reasons are obvious - without timezone information, none of the topological relationships between temporal entities in the same 24 hour period can be determined. Clearly the tools have not kept up, but the requirement is clear. The datatype builds it into the language infrastructure. If the datatype was relaxed to xsd:dateTime then there would need to be external checks.

I wanted to think about this for a bit but just for the record I disagree with this decision. First, I agree that it is kind of ridiculous that SWRL doesn't support xsd:dateTimeStamp but even if it did I would still disagree with this decision. The reason is that IMO these vocabularies should be all about reuse. So if you want to do reuse you don't want to impose your design decisions on the users. I don't know what your real world experience with ontologies has been but in my experience I have to deal with all sorts of existing requirements that don't make sense but can't be changed. I.e., it is quite possible that someone may want to use the Time ontology and have to work in a system that uses xsd:dateTime because there is some other database that uses that datatype and the datatype can't be changed without breaking existing code. So is it really rational to say to such people:
"well sucks to be you, you should design your systems better"?? I see the point about time zones and agree they are a good thing but you can still use them with xsd:dateTime, they just aren't mandatory. So you put a warning in the documentation and the ontology that says: make sure you use time zones if you use xsd:dateTime. A while ago I studied some of the design documents around SKOS and one thing I loved that I think many vocabularies (e.g., BFO and in this case the Time ontology) ignore is something that Tom Gruber coined in a short paper called I think "the principle of least ontological commitment" The point was that an ontology language (and in the opinion of the SKOS designers and me also a vocabulary) should try to be as minimal on design decisions as possible. Leave those things to the user, those are their decisions. Reusable assets should be as open and free of such commitments as possible. Anyway, just my opinion.

[dr-shorthair]

Let's continue the datatype discussion in #1435