3 ms·

For anyone interested, I did my Masters thesis on SWI-prolog as a Semantic querying tool, integrating it with the Eclipse RCP platform (Bioclipse.net in particu

by samuell 12y ago

For anyone interested, I did my Masters thesis on SWI-prolog as a Semantic querying tool, integrating it with the Eclipse RCP platform (Bioclipse.net in particular), and compared its querying performance with Java based Jena SPARQL parser for some typical tasks in cheminformatics. The title was "SWI-Prolog as a Semantic Web Tool for semantic querying in Bioclipse: Integration and performance benchmarking", and it is available for download here: https://www.researchgate.net/publication/50313589_SWI-Prolog_as_a_Semantic_Web_Tool_for_semantic_querying_in_Bioclipse_Integration_and_performance_benchmarking https://www.researchgate.net/publication/50313589_SWI-Prolog... In this particular task, SWI-Prolog totally knocked out Jena, and it was also more amenable to some heuristic optimiziations, where we the running time really became infinitesimal in comparison to other tools.

samuell 12y ago
E.g, just have a look at the graph in the top here, you can hardly see the dotted green line for prolog, creeping in the bottom of the graph: http://saml.rilspace.org/prolog-query-much-faster-when-mimicking-sparql http://saml.rilspace.org/prolog-query-much-faster-when-mimic...
craigching 12y ago
Read through the paper quickly, seems like a nice representation and solution of the problem. I have a couple of questions if you wouldn't mind. You say this in the paper: > It is an interesting observation that writing the Prolog query on the simpler form (Figure 18) made it amenable to heuristic optimization by sorting the values searched for, while this was not possible in the longer Prolog program I'm afraid I didn't read carefully and will go back, but could you clarify this a bit? I didn't understand about the longer vs. the shorter prolog code. Would this optimization be required always get better performance than Jena or Pellet? And then this: > Additionally, a drawback of SWI-Prolog speci?cally, against Jena and Pellet, is that since it is not written in Java, it is not as portable (i.e. the same code can not easily be executed) to di?erent platforms such as Mac, Windows, Linux etc. Instead the source code has to be compiled separately for each platform. This also has the result that the SWI-Prolog Bioclipse integration plugin will not be as portable as Bioclipse itself. Really, though, Bioclipse is dependent on the portabilty of Eclipse which probably doesn't support any more platforms than SWI Prolog (and most probably fewer than SWI Prolog), so I wouldn't really see that as a limitation. I would think you could provide the binaries in the distribution itself.
- samuell 12y ago
  I might not have used the optimal wording there. The important difference between the two prolog implementations is that the "longer" version is implemented by (recursive) iteration over a list of [peak] values (and comparing it to a reference list), whereas in the shorter one, the reference values are specified as separate conditions in the prolog rule, combined with logical AND. The separate conditions enables "shortcut" of the match-testing, in a way that the recursive list-parsing did not: As soon as one of the conditions is not met, the current spectrum will be rejected and the backtracking will go on with the next item, while with the recursive list-parsing version each item of the list of values will be compared to the reference [value-]list regardless of whether the current spectra has already been rejected or not. The "shorter" prolog version, with separate conditions, thus enables to order the conditions according so that statistically rare peak values come first (thus, "heuristically"), so that a spectrum can be rejected as soon as possible. Being a heuristic solution, the performance would of course depend on the prior knowledge of the values in the data. But as can be seen from figure 15, both prolog versions beat Jena and Pellet by a large margin, though the "shorter" version did so well that it is even hard to notice an increase of the running time linear to the number of triples in the triplestore, in the diagram. Hope that made it a tad clearer!
  - craigching 12y ago
    Yes, that helps a lot, thanks!
- samuell 12y ago
  Regardgint the portability, I tend to agree. To the end user, it is indeed possible to provide a portable solution. It requires more work on the developer side, to include multiple binaries and setting up the required Eclipse plugins/fragments to support that.

by samuell 12y ago

samuell 12y ago

E.g, just have a look at the graph in the top here, you can hardly see the dotted green line for prolog, creeping in the bottom of the graph: http://saml.rilspace.org/prolog-query-much-faster-when-mimicking-sparql http://saml.rilspace.org/prolog-query-much-faster-when-mimic...

craigching 12y ago

Read through the paper quickly, seems like a nice representation and solution of the problem. I have a couple of questions if you wouldn't mind. You say this in the paper: > It is an interesting observation that writing the Prolog query on the simpler form (Figure 18) made it amenable to heuristic optimization by sorting the values searched for, while this was not possible in the longer Prolog program I'm afraid I didn't read carefully and will go back, but could you clarify this a bit? I didn't understand about the longer vs. the shorter prolog code. Would this optimization be required always get better performance than Jena or Pellet? And then this: > Additionally, a drawback of SWI-Prolog speci?cally, against Jena and Pellet, is that since it is not written in Java, it is not as portable (i.e. the same code can not easily be executed) to di?erent platforms such as Mac, Windows, Linux etc. Instead the source code has to be compiled separately for each platform. This also has the result that the SWI-Prolog Bioclipse integration plugin will not be as portable as Bioclipse itself. Really, though, Bioclipse is dependent on the portabilty of Eclipse which probably doesn't support any more platforms than SWI Prolog (and most probably fewer than SWI Prolog), so I wouldn't really see that as a limitation. I would think you could provide the binaries in the distribution itself.

samuell 12y ago
I might not have used the optimal wording there. The important difference between the two prolog implementations is that the "longer" version is implemented by (recursive) iteration over a list of [peak] values (and comparing it to a reference list), whereas in the shorter one, the reference values are specified as separate conditions in the prolog rule, combined with logical AND. The separate conditions enables "shortcut" of the match-testing, in a way that the recursive list-parsing did not: As soon as one of the conditions is not met, the current spectrum will be rejected and the backtracking will go on with the next item, while with the recursive list-parsing version each item of the list of values will be compared to the reference [value-]list regardless of whether the current spectra has already been rejected or not. The "shorter" prolog version, with separate conditions, thus enables to order the conditions according so that statistically rare peak values come first (thus, "heuristically"), so that a spectrum can be rejected as soon as possible. Being a heuristic solution, the performance would of course depend on the prior knowledge of the values in the data. But as can be seen from figure 15, both prolog versions beat Jena and Pellet by a large margin, though the "shorter" version did so well that it is even hard to notice an increase of the running time linear to the number of triples in the triplestore, in the diagram. Hope that made it a tad clearer!
- craigching 12y ago
  Yes, that helps a lot, thanks!
samuell 12y ago
Regardgint the portability, I tend to agree. To the end user, it is indeed possible to provide a portable solution. It requires more work on the developer side, to include multiple binaries and setting up the required Eclipse plugins/fragments to support that.