Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[protege-dev] SWRL Builtins on Protege 4.3

Kristof Taveirne kristof.taveirne at gmail.com
Wed Sep 3 06:53:22 PDT 2014


Hi Martin,

Thanks for your response.
I just installed Protege5 and installed SWRLTab from git to experiment a
bit with that.

I didn't yet come to the issue I was having with my swrl custom built in,
but when I open my .owl file in Protege I now get the following:

Caused by:
org.swrlapi.exceptions.TargetSWRLRuleEngineNotImplementedFeatureException:
owl:DatatypeRestriction is not supported in by Drools OWL 2 RL reasoner
at
org.swrlapi.drools.converters.DroolsOWLDataRangeConverter.convert(DroolsOWLDataRangeConverter.java:129)
at
org.swrlapi.drools.converters.DroolsOWLDataRangeConverter.visit(DroolsOWLDataRangeConverter.java:160)
at
org.swrlapi.drools.converters.DroolsOWLDataRangeConverter.visit(DroolsOWLDataRangeConverter.java:21)
at
uk.ac.manchester.cs.owl.owlapi.OWLDatatypeRestrictionImpl.accept(OWLDatatypeRestrictionImpl.java:154)
...
I don't have this when I create a new file.

Looks like a bug since SWRLTab is disposed after this.

Greetings,
Kristof.



On Tue, Aug 26, 2014 at 8:40 PM, Martin O'Connor <martin at zippyrate.com>
wrote:

>
> Hi Samson,
>
> Yes - the new plugin and APIs will have almost all of the functionality of
> the SWRLTab Protege 3.5 release.
>
> The two exceptions are:
>
> (1) Instead of supporting both a Drools and Jess-based back ends, only
> Drools will be supported. This should have no practical effect since both
> had similar performance characteristics and the none of the SWRLAPI’s
> functionality is dependent on the underlying engine being used.
>
> (2) All Protege 3.5 builtin-libaries are supported except for the abox and
> tbox libraries, which were fragmentary and incomplete in any case. I hope
> to have more comprehensive implementations of these libraries in the near
> future.
>
> Even though the new SWRLAPI now sits on top of the OWLAPI instead of the
> old Protege 3.5 API, the APIs it exposes are almost identical to the old
> ones. Obviously package names and the like will have changed (as will some
> class names) but core entities are almost identical - so porting
> SWRLAPI-based code from Protege 3.5 to Protege 5.0 should not be difficult.
>
> I plan to have a GitHub-based wiki with a full set of documentation
> available for the release. It will be equivalent in scope to the current
> CIM3-based wiki for the Protege 3.5 version of the SWRLTab.
>
> Martin
>
>
> On Aug 26, 2014, at 10:56 AM, Samson Tu <swt at stanford.edu> wrote:
>
> Martin,
>
> Will the new SWRLAPI-based SWRLTab plugin support the SQWRL query language
> and the extensions/built-ins you created for the Protege 3 SWRLTab?
>
> Thanks.
>
> *With best regards,*
> *Samson*
>
> On Aug 26, 2014, at 10:46 AM, Martin O'Connor <martin at zippyrate.com>
> wrote:
>
>
> The GitHub project you referenced is the new OWLAPI-based SWRLAPI, which
> is being used as the basis of the new Protege 5.0-based SWRLTab plugin. I
> am hoping to release this plugin (together with documentation) in the next
> week or so.
>
> The built-in infrastructure in the SWRLAPI is designed for implementing
> built-ins that can be invoked by SWRLAPI-based rule engines. It was not
> designed as a general purpose mechanism for developing SWRL built-ins for
> use in a variety of systems. In general, the interface between a reasoner
> and a SWRL built-in is going to be highly specific to the particular
> reasoner implementation. So I am not sure you will be able to use in the
> way that you intend. The base built-in class that you referred to can not
> be used standalone (for example, built-in libraries are loaded dynamically
> at runtime and built-in invocation is assumed to occur in the context of a
> running SWRAPI-based rule engine).
>
> The new SWRLAPI will come with an Drools-based OWL 2 RL reasoner. (See
> http://ceur-ws.org/Vol-849/paper_31.pdf; the Jess-based reasoner will not
> be supported in the new release.)
>
> Martin
>
> On Aug 26, 2014, at 8:37 AM, Kristof Taveirne <kristof.taveirne at gmail.com>
> wrote:
>
> Hi all,
>
> I'm working on a project where I need to create a custom builtin for SWRL.
>
> We are using the Protege editor to create the OWL file, but in the end the
> OWL file will be loaded into a JENA web app and used by the Pellet reasoner.
>
> So the module I'm making needs to be available on both platforms.
>
> Initially I was working on this:
> http://protege.cim3.net/cgi-bin/wiki.pl?SWRLBuiltInBridge#nid6S5
> I've seen references to this page quite a few times on this mailing list.
> Problem is it handles Protege 3.4.
>
> I looked a bit further and came across this link:
> http://semwebguy.wordpress.com/2011/01/04/how-to-extend-pellet2-2-2s-swrl-built-in-support-with-your-custom-built-in/
>
> Here it describes how I can register my function into Pellet using
> BuiltInRegistry.instance.registerBuiltIn("
> http://mynamespace.com/aggregate#myfunction",
>  new GeneralFunctionBuiltIn(new MyFunction()));
>
> where my MyFunction implements
> the com.clarkparsia.pellet.rules.builtins.GeneralFunction interface.
>
> This should work when I'm using the OWL file in JENA.
> To make it work in Protege 4.3, I created an OSGI bundle that calls the
> registerBuiltIn() method in the bundle's Activator.
>
> Although this might work for the Pellet reasoner in Protege, it doesn't
> make the SWRL rule editor happy.
>
> In order to do that, I would need to extend AbstractSWRLBuiltInLibrary
> and follow the method as described on the wiki page mentioned above. (I
> guess)
>
> So basically it looks like there are 2 methods of implementing my custom
> function: one for Pellet, and one for SWRLTab???
>
> Although this doesn't feel right, I do want to try it out but I can't find
> the jar (OSGI bundle) that has AbstractSWRLBuiltInLibrary except for
> https://github.com/protegeproject/swrlapi.
> I would expect that there is a bundle already exposing the package
> containing this class, but I can't find it. I have no clue in which package
> I should look since it has been moving around in different versions.
>
>
> So ... to make a long story short: I'm stuck. :-)
> I have the feeling that I wanted to undertake something simple, but ended
> up in version hell.
>
> My apologies for long email.
> All pointers to how it should be done are more than welcome!!
>
> Thank you and kind regards,
>
> Kristof.
> _______________________________________________
> protege-dev mailing list
> protege-dev at lists.stanford.edu
> https://mailman.stanford.edu/mailman/listinfo/protege-dev
>
>
> _______________________________________________
> protege-dev mailing list
> protege-dev at lists.stanford.edu
> https://mailman.stanford.edu/mailman/listinfo/protege-dev
>
>
> _______________________________________________
> protege-dev mailing list
> protege-dev at lists.stanford.edu
> https://mailman.stanford.edu/mailman/listinfo/protege-dev
>
>
>
> _______________________________________________
> protege-dev mailing list
> protege-dev at lists.stanford.edu
> https://mailman.stanford.edu/mailman/listinfo/protege-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/protege-dev/attachments/20140903/fc219b76/attachment.html>


More information about the protege-dev mailing list