- From: Michael DeBellis via GitHub <sysbot+gh@w3.org>
- Date: Mon, 11 Sep 2023 20:57:00 +0000
- To: public-sdwig@w3.org
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 > <https://github.com/w3c/sdw/issues/1434#issuecomment-1713145787>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AD7TPBGWFOOKTGKBTTZZAZ3XZ2HYLANCNFSM6AAAAAA4QQKJT4> > . > 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-1714567832 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 11 September 2023 20:57:02 UTC