openRDF.org Issue Tracker

[SES-1121] Name of variable in query seems to introduce a parse issue

Fri, 2 Nov 2012 21:24:47 +0100 (CET)

Code to reproduce is at [1] as well as the output I'm seeing. What I'm seeing is for two queries which are exactly the same except for name of a variable in the object position of a triple pattern produce different algebra representations; the order of the joins are reversed. Unfortunately, because they're optional joins, the alternate ordering has different semantics than the correct representation, so it seems that depending on the name of a var, I can get an incorrect algebra and thus incorrect results. The first query parses correctly producing the algebra I'd expect, the second in which the variable ?c is renamed ?var2, the join is reversed.

The parse order is correct from what I can tell, the predicate has a bound value in both triple patterns, and in both cases, the predicate of the first triple pattern is named const-1, which afaiu, means it was parsed first. So I'm not sure at what point they get switched and the join ends up wrong, but it seems to happen every single time on my machine.

If you use ARQ (sparql.org) to parse the query, you can see that it produces the same algebra sesame produces when it's correct.

[1] https://gist.github.com/3988683

[SES-1118] Query.setMaxQueryTime should have an equivalent in Update operations

Tue, 30 Oct 2012 23:23:47 +0100 (CET)

See http://sourceforge.net/mailarchive/message.php?msg_id=30002138:

"In the Sesame API, the Query interface has
setMaxQueryTime()/getMaxQueryTime() methods. Is there any particular reason
why this isn't on Operation, so that it applies to Updates as well? The
'WHERE' part of an INSERT or DELETE query for example, is much like any
other query, so being able to stop these from running forever seems as
important as it is for queries."

[SES-1083] Possible corruption of values.dat on unexpected shutdown

Thu, 23 Aug 2012 15:39:14 +0200 (CEST)

The ValueStore's on-disk file values.dat become corrupted when an unexpected JVM shutdown takes place during a file write operation. In contrast to the TripleStore's indexes (which have a transaction replay/rollback recovery mechanism), such a corruption is currently impossible to recover from.

See discussion on sesame mailinglist for several pointers (including an interesting paper on B-tree validation) on possible fixes for this problem: http://sourceforge.net/mailarchive/forum.php?thread_name=CAJX_tMScSiii5-VTGtwfu5GQS3nffejT%2BDn%2BzQJLRPcC4fge9w%40mail.gmail.com&forum_name=sesame-general

[SES-1066] Support background parsing/concurrent reading of query results

Duplicate — Fri, 28 Sep 2012 01:07:29 +0200 (CEST)

Currently, when doing a query or export, HTTPRepository builds up the entire result in memory before giving an iterator back to the user. This is non-scalable.

We should look at implementing a background-parsing strategy similar to what SPARQLRepository supports.

On a more general level we can probably merge a lot of the functionalities of HTTPRepository and SPARQLRepository. One radical approach would be to completely get rid of Sesame's XML transaction format, and instead just work with SPARQL Updates.

[SES-959] RDF/XML parser fails on relative URIs in rdf:datatype for empty nodes

Related — Tue, 13 Mar 2012 15:22:05 +0100 (CET)

Similar to ~~SES-679~~, Rio fails to parse relative URIs for datatypes when the nodes are empty:

{code:xml}
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://example.com/#">
    <Foo>
        <bar rdf:datatype="hello"></bar>
    </Foo>
</rdf:RDF>
{code}

{noformat}
org.openrdf.rio.RDFParseException: Not a valid (absolute) URI: hello [line 1, column 132]
{noformat}

[SES-894] Enable 2PC for SailConnections

Sun, 4 Dec 2011 23:40:00 +0100 (CET)

Sesame is a great DB in and of itself, but it is not an island unto itself. On the project I am on for instance, we are combining Sesame with other, transactional resources -- and it would be really useful if a distributed transaction could span a Sesame Sail Connection. Right now we have to do all sorts of workarounds to reach eventual consistency of the system.

I realize it's a tall order, but if at all possible please open the current API to 2PC compliance by adding a prepare() method signature and make the out-of-the-box Sail implementations 2PC compliant...

Thanks!

[SES-888] Sesame SPARQL engine misinterprets half-unbounded path length expressions

Thu, 24 Nov 2011 11:40:35 +0100 (CET)

0. Same tree as in ~~SES-886~~ .
1. Try the following query:

PREFIX test: <http://www.testerie.test.com/nodes#>
select ?node ?name
where {
?node test:hasParent{2} test:B .
?node test:name ?name .

}

RESULT:

==============================================
node = http://www.testerie.test.com/nodes#K
name = KKK
==============================================
node = http://www.testerie.test.com/nodes#J
name = JJJ

That's okay.

2. Now try this one:

PREFIX test: <http://www.testerie.test.com/nodes#>
select ?node ?name
where {
?node test:hasParent{0,2} test:B .
?node test:name ?name .

}

RESULT:

==============================================
node = http://www.testerie.test.com/nodes#B
name = BBB
==============================================
node = http://www.testerie.test.com/nodes#F
name = FFF
==============================================
node = http://www.testerie.test.com/nodes#E
name = EEE
==============================================
node = http://www.testerie.test.com/nodes#K
name = KKK
==============================================
node = http://www.testerie.test.com/nodes#J
name = JJJ

Again, okay.

3. This one:

PREFIX test: <http://www.testerie.test.com/nodes#>
select ?node ?name
where {
?node test:hasParent{,2} test:B .
?node test:name ?name .

}

EXPECTED RESULT: Same as under 2.
ACTUAL RESULT:
==============================================
node = http://www.testerie.test.com/nodes#K
name = KKK
==============================================
node = http://www.testerie.test.com/nodes#J
name = JJJ

4. And this one:

PREFIX test: <http://www.testerie.test.com/nodes#>
select ?node ?name
where {
?node test:hasParent{0,} test:B .
?node test:name ?name .

}

EXPECTED RESULT: Same as under 2.
ACTUAL RESULT:
==============================================
node = http://www.testerie.test.com/nodes#B
name = BBB

Seems like the parser is misinterpreting the one-way unbounded notation.

Note: I'm creating this one as critical rather than minor because the answer is actually wrong.

[SES-676] No factory available for query language SPARQL

Mon, 3 Aug 2009 10:24:24 +0200 (CEST)

I have an application which is compiled and put in a JAR. I launch the application from this JAR. This application works if I don't use BigOWLIM and Sesame. Now, if I use BigOWLIM, i launch my application JAR by link in the classpath the BigOWLIM and Sesame JAR. At this time, I get the following exception when my application want to evaluate a query :

org.openrdf.query.UnsupportedQueryLanguageException: No factory available for query language SPARQL

If i unzip the Sesame JAR, there is the META-INF/services and it associated files.

I finally found a temporary solution : I link the unzipped sesame JAR folder in my application classpath and it works.

So, is there a problem with the provides Sesame JAR ? I have tried with the lastest version of Sesame and the problem is the same.

[SES-649] URI interface does not follow the URI (IRI) specification

Wed, 10 Dec 2008 10:16:05 +0100 (CET)

This is a problem when you are getting data from different sources which use different ways of formatting their URIs (all of them correct).
For example: http://demo.com#abc and HTTP://demo.com#abc are equal.

I could live with an option where we can say "strict" uri compliance (+normalization i.e. all lowercase for example) in exchange for a bit of performance loss during upload into the repository.

See http://www.ietf.org/rfc/rfc3987.txt

Quick summary is (for IRI or URI)
- schema (ftp: of http:of mailto:...) is case insensitive
- host name (following schema + '//', and occasionally after '@'
[mailto://user@host/) is case insensitive
- the rest is case sensitive