4 ms·
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
by 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 agoI 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 agoYes, that helps a lot, thanks!
- samuell 12y agoRegardgint 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.