21–30 of 32 posts
How does the closed world assumption of Prolog (if it's not explicitly specified it is assumed false) mesh with the open world assumption (if it is not explicitly specified it is unknown) of RDF?
OWA exists only on paper. Practically all implementations assume CWA.
SPARQL which is the standard query language for RDF is based on Prolog. So why go back to Prolog?
Is semantic web tech being reliably employed to solve any big problems? (RDF, RDFa, OWL, SPARQL, triple stores, graph dbs...?) Is it fast?
Earlier quoted context omitted.
There are a lot of non-developer types who need to deal with metadata and for whom the mechanics of websites are irrelevant, e.g. scientific researchers or art historians or statisticians. Librarians invented metadata not computer scientists.
I'm pretty sure philosophers invented metadata, even though they did not give it that name. The question how to distinguish between the properties an object has and what properties we attach to it, is sort of central in epistemology. Higher category theorists sometimes distinguish between stuff, structure and property http://nlab.mathforge.org/nlab/show/stuff,+structure,+proper... , which makes the definition of forg…
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…
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 di…
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!
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…
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 di…
SPARQL which is the standard query language for RDF is based on Prolog. So why go back to Prolog?
SPARQL is similar to non-recursive Datalogˆnot, but that's a subset of full Prolog. SPARQL is a query language, not a full-on programming language as Prolog is.
If anyone knows a way to do something similar in SPARQL, I'm highly interested to know.
Earlier quoted context omitted.
SPARQL is similar to non-recursive Datalogˆnot, but that's a subset of full Prolog. SPARQL is a query language, not a full-on programming language as Prolog is.
True. Most notably I badly miss the ability to encapsulate queries in named "functions". That is one of the things I really like in prolog, since it enables to quickly raise one's level of abstraction, by building up a "language" of facts and rules. If anyone knows a way to do something similar in SPARQL, I'm highly interested to know.
Earlier quoted context omitted.
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 di…
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 "sho…
Earlier quoted context omitted.
It is not at all fast. I don't even think it's computationally possible for SPARQL to be fast.
SPARQL is PSPACE-complete. Worst case complexity and "fast in practice" aren't really the same thing at all. I suspect average case complexity for SPARQL is much better, which is backed up by several reasonably peformant implementations.
Also, if your data store is "fast in practice" but has worst cases that are PSPACE-complete, how do you prevent worst-case queries from DOSing it?