Implementation of SWRL Rules for Time Ontology #1434
Comments
|
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. |
|
@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. 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 |
|
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:
***@***.***>
|
|
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. |
|
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:
***@***.***>
|
|
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:
***@***.***>
|
|
When we revised the 2006 OWL-Time for the 2017 version, switching to |
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: |
|
Let's continue the datatype discussion in #1435 |
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
The text was updated successfully, but these errors were encountered: