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-discussion] [Pellet-users] Big performance difference with SWRL when resolvingOWL imports

Serge Libotte slibotte at gmail.com
Wed Dec 12 01:05:46 PST 2007


Thanks,

I was using 3.4. I know it's not USING the rules (this is why I used Java
code to make the test) but I needed an editor.

Can someone show me what to change in the source in order to use an OWL atom
list in place of the RDF flavor?

Regards,

Serge.


2007/12/12, Tania Tudorache <tudorache at stanford.edu>:
>
> Serge,
>
> This is the wrong list to post a Protege-OWL related question. Please
> use in future the protege-owl mailing list.
>
> I also wonder what Protege version did you use to do the tests? Protege
> 3 or Protege 4?
>
> The latest beta of Protege 3.4 does not use the SWRL rules for the
> reasoning. We hope to have this available very soon.
>
> The reason why SWRLTab breaks with dl-safe.owl is that the file does not
> follow the SWRL specification when building the atom lists: it uses rdf
> lists instead of atom lists. If you have more questions about this,
> please post them on the Protege-OWL mailing list.
>
> Cheers,
> Tania
>
>
>
> Serge Libotte wrote:
> > Funny, I just tried this.
> > The perf is globally a bit better:
> >
> > StopWatch '': running time (millis) = 1562
> > -----------------------------------------
> > ms     %     Task name
> > -----------------------------------------
> > 01078  069%  Owl Loading
> > 00000  000%  get order1
> > 00000  000%  get hasPart
> > 00297  019%  get needs
> > 00187  012%  get NeededRes
> >
> > On the top of that, Protégé doesn't complain about anything (which
> > sounds normal to me since any specific XML editor is supposed to know
> > the NS it should manipulate)
> >
> > I wonder why Protégé breaks in opening the SWRL tab with
> > http://owldl.com/ontologies/dl-safe.owl
> >
> > 2007/12/7, raphael.coulonvaux at belgacom.be
> > <mailto:raphael.coulonvaux at belgacom.be>
> > <raphael.coulonvaux at belgacom.be <mailto:raphael.coulonvaux at belgacom.be
> >>:
> >
> >     Suppress the include.
> >
> >
> >
> ------------------------------------------------------------------------
> >     *From:* pellet-users-bounces at lists.owldl.com
> >     <mailto:pellet-users-bounces at lists.owldl.com>
> >     [mailto:pellet-users-bounces at lists.owldl.com
> >     <mailto:pellet-users-bounces at lists.owldl.com>] *On Behalf Of
> >     *Serge Libotte
> >     *Sent:* 07 December 2007 10:29
> >     *To:* pellet-users at lists.owldl.com
> >     <mailto:pellet-users at lists.owldl.com>
> >     *Subject:* [Pellet-users] Big performance difference with SWRL
> >     when resolvingOWL imports
> >
> >     Dears,
> >
> >     I've made a very small ontology using Protégé. (see attached)
> >     In it, I've defined two rules.
> >     When doing that, Protégé wants to import some other namespaces
> >     definitions, as you know.
> >
> >     Then I wrote a simple java code to test expected results and they
> >     are as expected. Nice!
> >
> >     owl loaded...
> >     Order_1 has hasPart(s):Spec_1, CFS_1, Offer_1
> >     Order_1 has needs(s):Res_1
> >     NeededRes instances: Res_1
> >
> >
> >     But...
> >
> >     The application throws a lot of messages telling it cannot parse
> >     the imported owl (normal since I prevent it to access the internet)
> >     I then copied the imported owl locally and added some
> >     SimpleURIMapper to resolve NS to those one.
> >
> >     The results are the same but the performance is bad: it takes 10
> >     times longer to retreive result of the rules (see below)
> >
> >     StopWatch 'no mappers': running time (millis) = 1890
> >     -----------------------------------------
> >     ms     %     Task name
> >     -----------------------------------------
> >     01359  072%  Owl Loading
> >     00000  000%  get order1
> >     00000  000%  get hasPart
> >     00328  017%  get needs
> >     00203  011%  get NeededRes
> >
> >     StopWatch 'with mappers': running time (millis) = 16812
> >     -----------------------------------------
> >     ms     %     Task name
> >     -----------------------------------------
> >     01156  007%  Owl Loading
> >     00000  000%  get order1
> >     00000  000%  get hasPart
> >     08422  050%  get needs
> >     07234  043%  get NeededRes
> >
> >     Since results are the same I wonder:
> >     1) is it necessary to import those NS?
> >     2) how to work in Protégé without all those imports?
> >     3) How to keep imports and avoid error messages while keeping good
> >     performances?
> >     4) What makes the rules going so slow (ontology size?)
> >
> >     Thanks for helping,
> >
> >     Serge.
> >
> >
> >     _______________________________________________
> >     Pellet-users mailing list
> >     Pellet-users at lists.owldl.com <mailto:Pellet-users at lists.owldl.com>
> >     http://lists.owldl.com/mailman/listinfo/pellet-users
> >     _______________________________________________
> >
> >     Sponsored by Clark & Parsia, LLC http://clarkparsia.com/
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > protege-discussion mailing list
> > protege-discussion at lists.stanford.edu
> > https://mailman.stanford.edu/mailman/listinfo/protege-discussion
> >
> > Instructions for unsubscribing:
> http://protege.stanford.edu/doc/faq.html#01a.03
> >
>
> _______________________________________________
> protege-discussion mailing list
> protege-discussion at lists.stanford.edu
> https://mailman.stanford.edu/mailman/listinfo/protege-discussion
>
> Instructions for unsubscribing:
> http://protege.stanford.edu/doc/faq.html#01a.03
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/protege-discussion/attachments/20071212/390b569e/attachment.html>


More information about the protege-discussion mailing list