<?xml version="1.0" encoding="UTF-8" ?>




<!--  RSS generated by JIRA 108 at Sun May 26 05:00:55 CEST 2013 -->
<rss version="0.92">





<channel>
    <title>openRDF.org Issue Tracker</title>
    <link>http://www.openrdf.org/issues</link>
    <description>This file is an XML representation of some issues</description>
    <language>en</language>

    
<item>

    







<title>[SES-1094] Add support for JSON-LD format</title>
<link>http://www.openrdf.org/issues/browse/SES-1094</link>

    
        <description>See &lt;a href=&quot;http://json-ld.org/&quot;&gt;http://json-ld.org/&lt;/a&gt;</description>
    
    
        <environment></environment>
    
        <key id="14051">SES-1094</key>
        <summary>Add support for JSON-LD format</summary>
        <type id="5">Sub-task</type>
    
        <priority id="3">Major</priority>
    
        <status id="1">Open</status>
        
        <resolution>Unresolved</resolution>
        
    
        
        <assignee username="jeen">Jeen Broekstra</assignee>
        
    

    
        
        <reporter username="jeen">Jeen Broekstra</reporter>
        
    

        
        <created>Tue, 11 Sep 2012 00:51:09 +0200 (CEST)</created>
    <updated>Tue, 6 Nov 2012 22:44:19 +0100 (CET)</updated>

    
        
        
    

    
        
        
            
            
                
                    <fixVersion>2.7.0</fixVersion>
                
            
        
    

    
        
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
        <comments>
            
            <comment author="pansell" created="Tue, 16 Oct 2012 02:00:33 +0200 (CEST)" level="">There is a partial Java/Sesame implementation of JSON-LD available at: &lt;br/&gt;
&lt;br/&gt;
&lt;a href=&quot;https://github.com/tristan/jsonld-java/tree/master/src/main/java/de/dfki/km/json/jsonld/impl&quot;&gt;https://github.com/tristan/jsonld-java/tree/master/src/main/java/de/dfki/km/json/jsonld/impl&lt;/a&gt;&lt;br/&gt;
&lt;br/&gt;
Edgar Rodriguez has written a Rio wrapper for it:&lt;br/&gt;
&lt;br/&gt;
&lt;a href=&quot;https://github.com/mhgrove/cp-openrdf-utils/tree/master/core/src/com/clarkparsia/openrdf/rio/jsonld&quot;&gt;https://github.com/mhgrove/cp-openrdf-utils/tree/master/core/src/com/clarkparsia/openrdf/rio/jsonld&lt;/a&gt;&lt;br/&gt;
&lt;br/&gt;
There is also another Rio wrapper set which is currently on a branch of my sesametools GitHub repository at:&lt;br/&gt;
&lt;br/&gt;
&lt;a href=&quot;https://github.com/ansell/sesametools/tree/feature/fixjsonld/jsonld/src/main/java/net/fortytwo/sesametools/jsonld&quot;&gt;https://github.com/ansell/sesametools/tree/feature/fixjsonld/jsonld/src/main/java/net/fortytwo/sesametools/jsonld&lt;/a&gt;&lt;br/&gt;
&lt;br/&gt;
One outstanding issue with using jsonld-java is that it needs to be modularised to remove the dependencies on sesame, jena and clerezza from the core module to separate modules.</comment>
            
        </comments>
    
    

    




    
    
    

</item>
    
<item>

    







<title>[SES-1123] Query builder tool</title>
<link>http://www.openrdf.org/issues/browse/SES-1123</link>

    
        <description></description>
    
    
        <environment></environment>
    
        <key id="14221">SES-1123</key>
        <summary>Query builder tool</summary>
        <type id="2">New Feature</type>
    
        <priority id="3">Major</priority>
    
        <status id="1">Open</status>
        
        <resolution>Unresolved</resolution>
        
    
        
        <assignee username="jeen">Jeen Broekstra</assignee>
        
    

    
        
        <reporter username="jeen">Jeen Broekstra</reporter>
        
    

        
        <created>Tue, 6 Nov 2012 21:23:42 +0100 (CET)</created>
    <updated>Tue, 6 Nov 2012 21:23:42 +0100 (CET)</updated>

    
        
        
    

    
        
        
            
            
                
                    <fixVersion>2.7.0</fixVersion>
                
            
        
    

    
        
        
            
            
                
                    <component>SeRQL</component>
                
                    <component>SPARQL</component>
                
            
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
    

    




    
    
    

</item>
    
<item>

    







<title>[SES-1122] System documentation missing block diagram</title>
<link>http://www.openrdf.org/issues/browse/SES-1122</link>

    
        <description>docs/system/figures/block-diagram.png referred to by docs/system/ch02.html#figure-sesame-arch is missing from the downloadable Sesame SDK file</description>
    
    
        <environment>any</environment>
    
        <key id="14220">SES-1122</key>
        <summary>System documentation missing block diagram</summary>
        <type id="1">Bug</type>
    
        <priority id="5">Trivial</priority>
    
        <status id="1">Open</status>
        
        <resolution>Unresolved</resolution>
        
    
        
        <assignee username="arjohn">Arjohn Kampman</assignee>
        
    

    
        
        <reporter username="dwvisser">Dale W. Visser</reporter>
        
    

        
        <created>Tue, 6 Nov 2012 16:22:45 +0100 (CET)</created>
    <updated>Tue, 6 Nov 2012 16:22:45 +0100 (CET)</updated>

    
        
        
            
            
                
                    <version>2.6.10</version>
                
            
        
    

    
        
        
    

    
        
        
            
            
                
                    <component>Documentation</component>
                
            
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
    

    




    
    
    

</item>
    
<item>

    







<title>[SES-1121] Name of variable in query seems to introduce a parse issue</title>
<link>http://www.openrdf.org/issues/browse/SES-1121</link>

    
        <description>Code to reproduce is at [1] as well as the output I&apos;m seeing.  What I&apos;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&apos;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&apos;d expect, the second in which the variable ?c is renamed ?var2, the join is reversed.&lt;br/&gt;
&lt;br/&gt;
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&apos;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.&lt;br/&gt;
&lt;br/&gt;
If you use ARQ (sparql.org) to parse the query, you can see that it produces the same algebra sesame produces when it&apos;s correct.&lt;br/&gt;
&lt;br/&gt;
[1] &lt;a href=&quot;https://gist.github.com/3988683&quot;&gt;https://gist.github.com/3988683&lt;/a&gt;&lt;br/&gt;
</description>
    
    
        <environment></environment>
    
        <key id="14212">SES-1121</key>
        <summary>Name of variable in query seems to introduce a parse issue</summary>
        <type id="1">Bug</type>
    
        <priority id="2">Critical</priority>
    
        <status id="1">Open</status>
        
        <resolution>Unresolved</resolution>
        
    
        
        <assignee username="arjohn">Arjohn Kampman</assignee>
        
    

    
        
        <reporter username="mhgrove">mhgrove@gmail.com</reporter>
        
    

        
        <created>Fri, 2 Nov 2012 21:24:47 +0100 (CET)</created>
    <updated>Fri, 2 Nov 2012 21:24:47 +0100 (CET)</updated>

    
        
        
    

    
        
        
    

    
        
        
            
            
                
                    <component>Query Model</component>
                
            
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
    

    




    
    
    

</item>
    
<item>

    







<title>[SES-1120] SameTerm inlining optimization can alter semantics of a query yielding incorrect results during evaluation</title>
<link>http://www.openrdf.org/issues/browse/SES-1120</link>

    
        <description>the inlining optimization can incorrectly inline a graph variable, for example:&lt;br/&gt;
&lt;br/&gt;
graph ?g {&lt;br/&gt;
&amp;nbsp;&amp;nbsp;... BGPs, none of which bind ?g ...&lt;br/&gt;
&amp;nbsp;&amp;nbsp;filter (sameTerm(?g, &amp;lt;urn:foo&amp;gt;))&lt;br/&gt;
}&lt;br/&gt;
&lt;br/&gt;
Sesame&apos;s sameTerm inliner will push the value of urn:foo into ?g, which while likely what the user meant, is not correct.  If no BGP&apos;s bind ?g in that graph clause, it&apos;s unbound when the sameTerm filter would normally get eval&apos;ed and thus it should fail and produce no results.&lt;br/&gt;
&lt;br/&gt;
I think this (and &lt;a href=&quot;http://www.openrdf.org/issues/browse/SES-1119&quot; title=&quot;SingletonSet is incorrect wrt to a Graph clause&quot;&gt;SES-1119&lt;/a&gt;) are both related to how the context of the query is represented in the algebra, where it&apos;s pushed into the leaf nodes where it&apos;s needed, the StatementPatterns, which makes it difficult to scope correctly for optimizations like the sameTerm inliner.&lt;br/&gt;
</description>
    
    
        <environment></environment>
    
        <key id="14211">SES-1120</key>
        <summary>SameTerm inlining optimization can alter semantics of a query yielding incorrect results during evaluation</summary>
        <type id="1">Bug</type>
    
        <priority id="3">Major</priority>
    
        <status id="1">Open</status>
        
        <resolution>Unresolved</resolution>
        
    
        
        <assignee username="arjohn">Arjohn Kampman</assignee>
        
    

    
        
        <reporter username="mhgrove">mhgrove@gmail.com</reporter>
        
    

        
        <created>Fri, 2 Nov 2012 21:20:37 +0100 (CET)</created>
    <updated>Fri, 2 Nov 2012 21:20:37 +0100 (CET)</updated>

    
        
        
    

    
        
        
    

    
        
        
            
            
                
                    <component>Query Optimizer</component>
                
            
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
    

    




    
    
    

</item>
    
<item>

    







<title>[SES-1119] SingletonSet is incorrect wrt to a Graph clause</title>
<link>http://www.openrdf.org/issues/browse/SES-1119</link>

    
        <description>If you have a dataset which includes n named graphs (where n &amp;gt;= 1) the query &amp;quot;select ?g where { graph ?g {} }&amp;quot; should produce n results where each ?g in each result is bound to a named graph identifier.  Sesame returns a single empty result because SingletonSet does not have any information about any graph clause it is participating in.&lt;br/&gt;
</description>
    
    
        <environment></environment>
    
        <key id="14210">SES-1119</key>
        <summary>SingletonSet is incorrect wrt to a Graph clause</summary>
        <type id="1">Bug</type>
    
        <priority id="3">Major</priority>
    
        <status id="1">Open</status>
        
        <resolution>Unresolved</resolution>
        
    
        
        <assignee username="arjohn">Arjohn Kampman</assignee>
        
    

    
        
        <reporter username="mhgrove">mhgrove@gmail.com</reporter>
        
    

        
        <created>Fri, 2 Nov 2012 21:18:54 +0100 (CET)</created>
    <updated>Fri, 2 Nov 2012 21:18:54 +0100 (CET)</updated>

    
        
        
    

    
        
        
    

    
        
        
            
            
                
                    <component>Query Model</component>
                
            
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
    

    




    
    
    

</item>
    
<item>

    







<title>[SES-1057] Parameters Not Bound in SERVICE Block</title>
<link>http://www.openrdf.org/issues/browse/SES-1057</link>

    
        <description>If a variable is bound using the setBinding method of the Query object, it is ignored if the variable is used within a SERVICE block. However, if a BINDINGS clause is used, the variable is bound both in and out of the SERVICE block.&lt;br/&gt;
&lt;br/&gt;
SELECT * {SERVICE &amp;lt;&lt;a href=&quot;http://services.data.gov/sparql&quot;&gt;http://services.data.gov/sparql&lt;/a&gt;&amp;gt; {&lt;br/&gt;
&amp;lt;&lt;a href=&quot;http://www.openlinksw.com/virtrdf-data-formats#sinv&quot;&gt;http://www.openlinksw.com/virtrdf-data-formats#sinv&lt;/a&gt;&amp;gt; ?p ?o&lt;br/&gt;
FILTER (?o = $b)&lt;br/&gt;
}&lt;br/&gt;
}&lt;br/&gt;
&lt;br/&gt;
query.setBinding(&amp;quot;b&amp;quot;, con.getValueFactory().createLiteral(&amp;quot;sinv&amp;quot;));&lt;br/&gt;
&lt;br/&gt;
The above produces no results, when &amp;quot;b&amp;quot; is bound using the above method. However, the query below does produce a result. I would expect both results to be identical.&lt;br/&gt;
&lt;br/&gt;
&lt;br/&gt;
SELECT * {SERVICE &amp;lt;&lt;a href=&quot;http://services.data.gov/sparql&quot;&gt;http://services.data.gov/sparql&lt;/a&gt;&amp;gt; {&lt;br/&gt;
&amp;lt;&lt;a href=&quot;http://www.openlinksw.com/virtrdf-data-formats#sinv&quot;&gt;http://www.openlinksw.com/virtrdf-data-formats#sinv&lt;/a&gt;&amp;gt; ?p ?o&lt;br/&gt;
FILTER (?o = $b)&lt;br/&gt;
}&lt;br/&gt;
} BINDINGS $b {&lt;br/&gt;
(&amp;quot;sinv&amp;quot;)&lt;br/&gt;
}&lt;br/&gt;
&lt;br/&gt;
p,o,b&lt;br/&gt;
&lt;a href=&quot;http://www.openlinksw.com/schemas/virtrdf#qmfName,sinv,sinv&quot;&gt;http://www.openlinksw.com/schemas/virtrdf#qmfName,sinv,sinv&lt;/a&gt;&lt;br/&gt;
</description>
    
    
        <environment></environment>
    
        <key id="13800">SES-1057</key>
        <summary>Parameters Not Bound in SERVICE Block</summary>
        <type id="1">Bug</type>
    
        <priority id="3">Major</priority>
    
        <status id="1">Open</status>
        
        <resolution>Unresolved</resolution>
        
    
        
        <assignee username="arjohn">Arjohn Kampman</assignee>
        
    

    
        
        <reporter username="james">James Leigh</reporter>
        
    

        
        <created>Mon, 9 Jul 2012 19:44:17 +0200 (CEST)</created>
    <updated>Thu, 1 Nov 2012 02:40:52 +0100 (CET)</updated>

    
        
        
            
            
                
                    <version>2.6.7</version>
                
            
        
    

    
        
        
            
            
                
                    <fixVersion>2.7.0</fixVersion>
                
            
        
    

    
        
        
            
            
                
                    <component>Query Engine</component>
                
            
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
        <comments>
            
            <comment author="james" created="Wed, 24 Oct 2012 15:20:36 +0200 (CEST)" level="">The following query also works btw.&lt;br/&gt;
&lt;br/&gt;
SELECT * {&lt;br/&gt;
BIND ($b AS ?b2)&lt;br/&gt;
SERVICE &amp;lt;&lt;a href=&quot;http://services.data.gov/sparql&quot;&gt;http://services.data.gov/sparql&lt;/a&gt;&amp;gt; { &lt;br/&gt;
&amp;lt;&lt;a href=&quot;http://www.openlinksw.com/virtrdf-data-formats#sinv&quot;&gt;http://www.openlinksw.com/virtrdf-data-formats#sinv&lt;/a&gt;&amp;gt; ?p ?o &lt;br/&gt;
FILTER (?o = ?b2) &lt;br/&gt;
} &lt;br/&gt;
} &lt;br/&gt;
&lt;br/&gt;
query.setBinding(&amp;quot;b&amp;quot;, con.getValueFactory().createLiteral(&amp;quot;sinv&amp;quot;)); </comment>
            
        </comments>
    
    

    




    
    
    

</item>
    
<item>

    







<title>[SES-1081] SameTerm With BINDING Clause Always Fails</title>
<link>http://www.openrdf.org/issues/browse/SES-1081</link>

    
        <description>The following query always returns an empty result.&lt;br/&gt;
&lt;br/&gt;
SELECT * { ?s ex:p ?a FILTER sameTerm(?a,?e) } BINDINGS ?e {(ex:A)}</description>
    
    
        <environment></environment>
    
        <key id="13961">SES-1081</key>
        <summary>SameTerm With BINDING Clause Always Fails</summary>
        <type id="1">Bug</type>
    
        <priority id="3">Major</priority>
    
        <status id="1">Open</status>
        
        <resolution>Unresolved</resolution>
        
    
        
        <assignee username="jeen">Jeen Broekstra</assignee>
        
    

    
        
        <reporter username="james">James Leigh</reporter>
        
    

        
        <created>Thu, 16 Aug 2012 02:36:46 +0200 (CEST)</created>
    <updated>Thu, 1 Nov 2012 02:40:52 +0100 (CET)</updated>

    
        
        
            
            
                
                    <version>2.6.8</version>
                
                    <version>2.6.9</version>
                
            
        
    

    
        
        
            
            
                
                    <fixVersion>2.7.0</fixVersion>
                
            
        
    

    
        
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
    

    



    <issuelinks>
    
        <issuelinktype id="10020">
            <name>Related</name>
                
                
                
                
                
                    <inwardlinks description="is related to">
                    
                        <issuelink>
                            <issuekey id="13590">SES-1020</issuekey>
                        </issuelink>
                    
                    </inwardlinks>
                
                
        </issuelinktype>
    
    </issuelinks>


    
    
    

</item>
    
<item>

    







<title>[SES-1118] Query.setMaxQueryTime should have an equivalent in Update operations</title>
<link>http://www.openrdf.org/issues/browse/SES-1118</link>

    
        <description>See &lt;a href=&quot;http://sourceforge.net/mailarchive/message.php?msg_id=30002138&quot;&gt;http://sourceforge.net/mailarchive/message.php?msg_id=30002138&lt;/a&gt;:&lt;br/&gt;
&lt;br/&gt;
&amp;quot;In the Sesame API, the Query interface has&lt;br/&gt;
setMaxQueryTime()/getMaxQueryTime() methods. Is there any particular reason&lt;br/&gt;
why this isn&apos;t on Operation, so that it applies to Updates as well? The&lt;br/&gt;
&apos;WHERE&apos; part of an INSERT or DELETE query for example, is much like any&lt;br/&gt;
other query, so being able to stop these from running forever seems as&lt;br/&gt;
important as it is for queries.&amp;quot;</description>
    
    
        <environment></environment>
    
        <key id="14200">SES-1118</key>
        <summary>Query.setMaxQueryTime should have an equivalent in Update operations</summary>
        <type id="4">Improvement</type>
    
        <priority id="2">Critical</priority>
    
        <status id="1">Open</status>
        
        <resolution>Unresolved</resolution>
        
    
        
        <assignee username="jeen">Jeen Broekstra</assignee>
        
    

    
        
        <reporter username="jans">Jan Stette</reporter>
        
    

        
        <created>Tue, 30 Oct 2012 22:53:53 +0100 (CET)</created>
    <updated>Tue, 30 Oct 2012 23:23:47 +0100 (CET)</updated>

    
        
        
    

    
        
        
            
            
                
                    <fixVersion>2.7.0</fixVersion>
                
            
        
    

    
        
        
            
            
                
                    <component>Query Engine</component>
                
                    <component>Query Model</component>
                
                    <component>Repository API</component>
                
            
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
        <comments>
            
            <comment author="jeen" created="Tue, 30 Oct 2012 23:23:47 +0100 (CET)" level="">Implementing a timeout for updates is slightly more complex than it is for queries. Query timeouts are handled at the Repository level, by wrapping the result iteration in a TimeLimitIteration. This approach does not work for updates, because their execution is completely handled at the SAIL level (except for LOAD operations). &lt;br/&gt;
&lt;br/&gt;
the max execution time parameter will therefore have to trickle down all the way to the sail, where a timer needs to be set on the operation.</comment>
            
        </comments>
    
    

    




    
    
    

</item>
    
<item>

    







<title>[SES-1117] ServiceRegistry uses class restricted by Google App Engine</title>
<link>http://www.openrdf.org/issues/browse/SES-1117</link>

    
        <description>ServiceRegistry uses the javax.imageio.spi.ServiceRegistry class. However, this class is restricted in the Google App Engine, which prohibits calls like repoConn.prepareTupleQuery(QueryLanguage.SPARQL, sparqlString); in code deployed there. The following note is already in the file:&lt;br/&gt;
&lt;br/&gt;
// Note: Using javax.imageio.spi.ServiceRegistry as it publicly exposes&lt;br/&gt;
		// the sun.misc.Service functionality. Starting from Java 6, this&lt;br/&gt;
		// functionality is also available java.util.ServiceLoader&lt;br/&gt;
		Iterator&amp;lt;S&amp;gt; services = javax.imageio.spi.ServiceRegistry.lookupProviders(serviceClass, serviceClass.getClassLoader());&lt;br/&gt;
&lt;br/&gt;
Proposal: Changing this code to the non-restricted java.util.ServiceLoader in future releases as mentioned in the comment.</description>
    
    
        <environment>aduna-commons-lang-2.9.0.jar</environment>
    
        <key id="14190">SES-1117</key>
        <summary>ServiceRegistry uses class restricted by Google App Engine</summary>
        <type id="1">Bug</type>
    
        <priority id="3">Major</priority>
    
        <status id="1">Open</status>
        
        <resolution>Unresolved</resolution>
        
    
        
        <assignee username="arjohn">Arjohn Kampman</assignee>
        
    

    
        
        <reporter username="hannes">Hannes Muehleisen</reporter>
        
    

        
        <created>Sat, 27 Oct 2012 18:26:30 +0200 (CEST)</created>
    <updated>Sat, 27 Oct 2012 18:28:47 +0200 (CEST)</updated>

    
        
        
    

    
        
        
    

    
        
        
            
            
                
                    <component>Repository API</component>
                
            
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
        <comments>
            
            <comment author="hannes" created="Sat, 27 Oct 2012 18:28:47 +0200 (CEST)" level="">Workaround:&lt;br/&gt;
&lt;br/&gt;
Extend SailTupleQuery;&lt;br/&gt;
&lt;br/&gt;
private static class STQ extends SailTupleQuery {&lt;br/&gt;
		protected STQ(ParsedTupleQuery tupleQuery,&lt;br/&gt;
				SailRepositoryConnection sailConnection) {&lt;br/&gt;
			super(tupleQuery, sailConnection);&lt;br/&gt;
		}&lt;br/&gt;
	}&lt;br/&gt;
&lt;br/&gt;
Now use the following code (instead of repoConn.prepareTupleQuery(QueryLanguage.SPARQL, sparqlString); ):&lt;br/&gt;
&lt;br/&gt;
SailTupleQuery stq = new STQ((ParsedTupleQuery) new SPARQLParser().parseQuery(spargel, &amp;quot;ex:&amp;quot;),(SailRepositoryConnection) repoConn);</comment>
            
        </comments>
    
    

    




    
    
    

</item>
    
<item>

    







<title>[SES-1072] Allow users to save and retrieve SPARQL and SeRQL queries in the Workbench</title>
<link>http://www.openrdf.org/issues/browse/SES-1072</link>

    
        <description>At least one commercial RDF repository has the capability to save and retrieve SPARQL queries within its web interface. This would also be a very useful feature for OpenRDF Workbench. Currently, I have to use cut-and-paste with a text editor or the Sesame Windows Client to save queries. However, the capability to share these queries with co-workers directly on the workbench is still very desirable.&lt;br/&gt;
&lt;br/&gt;
One immediate question to be answered for any implementation of this: where to save the queries: in the repository folder? in the SYSTEM repository?</description>
    
    
        <environment></environment>
    
        <key id="13921">SES-1072</key>
        <summary>Allow users to save and retrieve SPARQL and SeRQL queries in the Workbench</summary>
        <type id="2">New Feature</type>
    
        <priority id="3">Major</priority>
    
        <status id="3">In Progress</status>
        
        <resolution>Unresolved</resolution>
        
    
        
        <assignee username="dwvisser">Dale W. Visser</assignee>
        
    

    
        
        <reporter username="dwvisser">Dale W. Visser</reporter>
        
    

        
        <created>Tue, 7 Aug 2012 23:20:47 +0200 (CEST)</created>
    <updated>Wed, 24 Oct 2012 21:48:41 +0200 (CEST)</updated>

    
        
        
            
            
                
                    <version>2.6.8</version>
                
            
        
    

    
        
        
            
            
                
                    <fixVersion>2.7.0</fixVersion>
                
            
        
    

    
        
        
            
            
                
                    <component>SeRQL</component>
                
                    <component>SPARQL</component>
                
                    <component>Web interface</component>
                
            
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
        <comments>
            
            <comment author="dwvisser" created="Fri, 19 Oct 2012 19:58:58 +0200 (CEST)" level="">Planning to implement the storage of queries using a single entity table in Java DB, accessed via Java Persistence Architecture API. This introduces a dependency on Java DB, which is not distributed by default with OpenJDK. See attached plan document.</comment>
            
            <comment author="dwvisser" created="Fri, 19 Oct 2012 20:06:01 +0200 (CEST)" level="">My initial thoughts on the design of the implementation for this feature.</comment>
            
            <comment author="dwvisser" created="Tue, 23 Oct 2012 14:32:53 +0200 (CEST)" level="">Updated design, based on feedback</comment>
            
            <comment author="dwvisser" created="Tue, 23 Oct 2012 14:43:53 +0200 (CEST)" level="">Slight update to previous design document.</comment>
            
            <comment author="drewp" created="Wed, 24 Oct 2012 20:31:14 +0200 (CEST)" level="">What&apos;s motivating the new non-rdf database, as opposed to using SYSTEM or a new workbench repo? I suspect it&apos;s just something like the security feature. It would be unfortunate for people to get the (completely wrong) idea that RDF is good for some things, but if you need security you should use SQL, since, you know, &amp;quot;even sesame does that, and they chose to do it despite already having a running RDF store&amp;quot;.&lt;br/&gt;
&lt;br/&gt;
Other ideas that may address the problem (assuming it was security):&lt;br/&gt;
Store the non-anonymous queries in NT files near the normal data store files, so they aren&apos;t readable by standard sesame means. (And we don&apos;t care about read/write speed for this tiny data.)&lt;br/&gt;
Make a new &apos;workbench&apos; repo and arrange for it to have special security constraints.&lt;br/&gt;
Don&apos;t attempt private queries at all, just &apos;hidden&apos; (&apos;personal&apos;?) ones, so it&apos;s ok if I use sesame to view and edit the whole contents of the saved-query dataset.&lt;br/&gt;
</comment>
            
            <comment author="dwvisser" created="Wed, 24 Oct 2012 21:48:23 +0200 (CEST)" level="">Updated design document. Rigid thinking on my part motivated the JavaDB choice, not realizing I didn&apos;t *have* to use the repository server that Workbench was providing an explicit interface to.&lt;br/&gt;
&lt;br/&gt;
See also the RDF Schema document that goes along with this update.</comment>
            
        </comments>
    
    

    




    
    
    

</item>
    
<item>

    







<title>[SES-1116] Sesame&apos;s query API should protect against SPARQL/SeRQL Injection attacks</title>
<link>http://www.openrdf.org/issues/browse/SES-1116</link>

    
        <description>SPARQL/SeRQL/RDQL can be subject to injection attacks just like SQL. See &lt;a href=&quot;http://www.slideshare.net/Morelab/sparqlrdqlsparul-injection&quot;&gt;http://www.slideshare.net/Morelab/sparqlrdqlsparul-injection&lt;/a&gt; for details.&lt;br/&gt;
&lt;br/&gt;
It would be good to provide an API call similar to java.sql.Connection.prepareStatement(...) that can sanitize parameters provided to a query template.</description>
    
    
        <environment>any</environment>
    
        <key id="14180">SES-1116</key>
        <summary>Sesame&apos;s query API should protect against SPARQL/SeRQL Injection attacks</summary>
        <type id="2">New Feature</type>
    
        <priority id="4">Minor</priority>
    
        <status id="1">Open</status>
        
        <resolution>Unresolved</resolution>
        
    
        
        <assignee username="arjohn">Arjohn Kampman</assignee>
        
    

    
        
        <reporter username="dwvisser">Dale W. Visser</reporter>
        
    

        
        <created>Wed, 24 Oct 2012 17:10:33 +0200 (CEST)</created>
    <updated>Wed, 24 Oct 2012 21:44:29 +0200 (CEST)</updated>

    
        
        
            
            
                
                    <version>2.6.9</version>
                
            
        
    

    
        
        
    

    
        
        
            
            
                
                    <component>SeRQL</component>
                
            
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
        <comments>
            
            <comment author="drewp" created="Wed, 24 Oct 2012 20:25:19 +0200 (CEST)" level="">Is this not already present in &lt;br/&gt;
&lt;a href=&quot;http://www.openrdf.org/doc/sesame2/api/org/openrdf/repository/sparql/query/SPARQLQuery.html#setBinding(java.lang.String,&quot;&gt;http://www.openrdf.org/doc/sesame2/api/org/openrdf/repository/sparql/query/SPARQLQuery.html#setBinding(java.lang.String,&lt;/a&gt; org.openrdf.model.Value)&lt;br/&gt;
and&lt;br/&gt;
&lt;a href=&quot;http://www.openrdf.org/doc/sesame2/system/ch08.html#d0e247&quot;&gt;http://www.openrdf.org/doc/sesame2/system/ch08.html#d0e247&lt;/a&gt; (the &apos;$&amp;lt;varname&amp;gt;&apos; feature)&lt;br/&gt;
?&lt;br/&gt;
</comment>
            
            <comment author="dwvisser" created="Wed, 24 Oct 2012 21:44:29 +0200 (CEST)" level="">Drew&apos;s comment is correct. At least for the SPARQL case, this appears to be covered. I&apos;m reducing the scope of the bug to SeRQL, and downgrading the priority to Minor, since those that need safe parameterization of queries have the SPARQL option.</comment>
            
        </comments>
    
    

    




    
    
    

</item>
    
<item>

    







<title>[SES-1111] Improve transaction handling in SailConnection</title>
<link>http://www.openrdf.org/issues/browse/SES-1111</link>

    
        <description>This task will involve several extensions to the sail api, including a new begin() method to indicate a transaction has started.</description>
    
    
        <environment></environment>
    
        <key id="14150">SES-1111</key>
        <summary>Improve transaction handling in SailConnection</summary>
        <type id="2">New Feature</type>
    
        <priority id="1">Blocker</priority>
    
        <status id="3">In Progress</status>
        
        <resolution>Unresolved</resolution>
        
    
        
        <assignee username="jeen">Jeen Broekstra</assignee>
        
    

    
        
        <reporter username="jeen">Jeen Broekstra</reporter>
        
    

        
        <created>Wed, 10 Oct 2012 08:18:07 +0200 (CEST)</created>
    <updated>Tue, 23 Oct 2012 08:09:55 +0200 (CEST)</updated>

    
        
        
    

    
        
        
            
            
                
                    <fixVersion>2.7.0</fixVersion>
                
            
        
    

    
        
        
            
            
                
                    <component>Sail API</component>
                
            
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
        <comments>
            
            <comment author="james" created="Wed, 10 Oct 2012 15:05:39 +0200 (CEST)" level="">This makes a lot of sense since the SailConnection already has a way to signal the end of a transaction with commit(), but currently no way to signal the beginning of a transaction. Current implementations that use a store lock when there are uncommitted changes could ignore this signal, but it would be valuable to stores that support multiple concurrent write transactions.</comment>
            
        </comments>
    
    

    




    
    
    

</item>
    
<item>

    







<title>[SES-945] Update Turtle parser to current W3C Working draft</title>
<link>http://www.openrdf.org/issues/browse/SES-945</link>

    
        <description>The Rio turtle parser and writer are currently based on the 2006 version of the Turtle format as defined by Dave Beckett (see &lt;a href=&quot;http://www.dajobe.org/2004/01/turtle/&quot;&gt;http://www.dajobe.org/2004/01/turtle/&lt;/a&gt; ). &lt;br/&gt;
&lt;br/&gt;
However, W3C is officially standardizing Turtle, currently it&apos;s a working draft (see &lt;a href=&quot;http://www.w3.org/TR/turtle/&quot;&gt;http://www.w3.org/TR/turtle/&lt;/a&gt; ). Our Turtle parser should be updated to reflect this updated spec. &lt;br/&gt;
&lt;br/&gt;
A partial was already done to address one specific incompatibility (see &lt;a href=&quot;http://www.openrdf.org/issues/browse/SES-935&quot; title=&quot;Update Turtle parser to allow numbers as lname-start-char in QNames&quot;&gt;&lt;strike&gt;SES-935&lt;/strike&gt;&lt;/a&gt; ), but we need to review the spec and the parser/writer in more detail to flush out any incompatibilities.</description>
    
    
        <environment></environment>
    
        <key id="13221">SES-945</key>
        <summary>Update Turtle parser to current W3C Working draft</summary>
        <type id="4">Improvement</type>
    
        <priority id="3">Major</priority>
    
        <status id="1">Open</status>
        
        <resolution>Unresolved</resolution>
        
    
        
        <assignee username="jeen">Jeen Broekstra</assignee>
        
    

    
        
        <reporter username="jeen">Jeen Broekstra</reporter>
        
    

        
        <created>Sun, 4 Mar 2012 23:44:37 +0100 (CET)</created>
    <updated>Tue, 23 Oct 2012 02:45:58 +0200 (CEST)</updated>

    
        
        
    

    
        
        
            
            
                
                    <fixVersion>2.7.0</fixVersion>
                
            
        
    

    
        
        
            
            
                
                    <component>Rio</component>
                
            
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
        <comments>
            
            <comment author="pansell" created="Tue, 23 Oct 2012 02:43:57 +0200 (CEST)" level="">I am doing some work on this as part of &lt;a href=&quot;http://www.openrdf.org/issues/browse/RIO-80&quot; title=&quot;TurtleParser does not support bare unlabelled blank node from latest Turtle Working Draft&quot;&gt;RIO-80&lt;/a&gt; , where the Working Draft allows unlabelled blank nodes in a previously invalid context.&lt;br/&gt;
&lt;br/&gt;
I am also updating the test suite to include new tests since the last time we synchronised with Dave Beckett&apos;s test suite from the Raptor codebase &lt;a href=&quot;https://github.com/dajobe/raptor/blob/master/tests/turtle&quot;&gt;https://github.com/dajobe/raptor/blob/master/tests/turtle&lt;/a&gt;&lt;br/&gt;
&lt;br/&gt;
Andy Seabourne is working on a separate Turtle test suite for Jena. &lt;a href=&quot;https://svn.apache.org/repos/asf/jena/Experimental/riot-reader/testing/RIOT/Lang/&quot;&gt;https://svn.apache.org/repos/asf/jena/Experimental/riot-reader/testing/RIOT/Lang/&lt;/a&gt; </comment>
            
            <comment author="pansell" created="Tue, 23 Oct 2012 02:45:58 +0200 (CEST)" level="">&lt;a href=&quot;http://www.openrdf.org/issues/browse/RIO-80&quot; title=&quot;TurtleParser does not support bare unlabelled blank node from latest Turtle Working Draft&quot;&gt;RIO-80&lt;/a&gt; details a case where the Sesame Turtle parser cannot parse output from the OWLAPI Turtle writer that is valid as of the latest Working Draft</comment>
            
        </comments>
    
    

    



    <issuelinks>
    
        <issuelinktype id="10002">
            <name>Dependency</name>
                
                
                    <outwardlinks description="depends on">
                    
                        <issuelink>
                            <issuekey id="13802">RIO-80</issuekey>
                        </issuelink>
                    
                    </outwardlinks>
                
                
                
                
                
        </issuelinktype>
    
        <issuelinktype id="10030">
            <name>Followup</name>
                
                
                    <outwardlinks description="is followup of">
                    
                        <issuelink>
                            <issuekey id="13160">SES-935</issuekey>
                        </issuelink>
                    
                    </outwardlinks>
                
                
                
                
                
        </issuelinktype>
    
    </issuelinks>


    
    
    

</item>
    
<item>

    







<title>[SES-875] Deploy sesame to maven-central (via sonatype) instead of repo.aduna-software.org</title>
<link>http://www.openrdf.org/issues/browse/SES-875</link>

    
        <description>Requested by many users with projects that depend on Sesame. This will make it possible for them to deploy to maven-central also.</description>
    
    
        <environment></environment>
    
        <key id="12791">SES-875</key>
        <summary>Deploy sesame to maven-central (via sonatype) instead of repo.aduna-software.org</summary>
        <type id="3">Task</type>
    
        <priority id="3">Major</priority>
    
        <status id="1">Open</status>
        
        <resolution>Unresolved</resolution>
        
    
        
        <assignee username="arjohn">Arjohn Kampman</assignee>
        
    

    
        
        <reporter username="arjohn">Arjohn Kampman</reporter>
        
    

        
        <created>Thu, 3 Nov 2011 09:39:43 +0100 (CET)</created>
    <updated>Tue, 16 Oct 2012 06:27:12 +0200 (CEST)</updated>

    
        
        
    

    
        
        
            
            
                
                    <fixVersion>2.7.0</fixVersion>
                
            
        
    

    
        
        
    

    
    
        <due></due>
    
    
        <votes>1</votes>
    
    

    
    
        <comments>
            
            <comment author="pansell" created="Tue, 16 Oct 2012 06:27:12 +0200 (CEST)" level="">What changes are necessary to deploy to sonatype? &lt;br/&gt;
&lt;br/&gt;
According to the guide : &lt;a href=&quot;https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide&quot;&gt;https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide&lt;/a&gt;&lt;br/&gt;
&lt;br/&gt;
* Cannot have any repository elements: We will not once we are deploying to maven central?&lt;br/&gt;
* Must have developer information in pom.xml files : Should be easy enough to add, but it is not there right now&lt;br/&gt;
* Will need to sign artifacts using GPG: How are releases currently performed? If they are done using maven-release-plugin it may be easier.&lt;br/&gt;
* If we need to deploy using Ant then it should not be too difficult according to the guide: See Section 7c. Deploy Snapshots and Stage Releases with Ant&lt;br/&gt;
* Not sure whether it is necessary to inherit from the sonatype oss-parent, but it doesn&apos;t seem like it would be as long as we configure the necessary plugins ourselves.&lt;br/&gt;
* Already have SCM URL and Connection information&lt;br/&gt;
* Already have License information&lt;br/&gt;
* Already have URL, Description and Name elements&lt;br/&gt;
* Already have -sources.jar and -javadoc.jar artifacts&lt;br/&gt;
&lt;br/&gt;
It may also be possible to deploy to both sonatype and repo.aduna-software.org, although I am not sure how that would work with maven-release-plugin.</comment>
            
        </comments>
    
    

    



    <issuelinks>
    
        <issuelinktype id="10002">
            <name>Dependency</name>
                
                
                    <outwardlinks description="depends on">
                    
                        <issuelink>
                            <issuekey id="12790">SES-874</issuekey>
                        </issuelink>
                    
                    </outwardlinks>
                
                
                
                
                
        </issuelinktype>
    
    </issuelinks>


    
    
    

</item>
    
<item>

    







<title>[SES-719] Unable to use the workbench when the repository is password-protected on the server</title>
<link>http://www.openrdf.org/issues/browse/SES-719</link>

    
        <description>I have deployed openrdf-workbench and openrdf-sesame both on a tomcat server using basic auth password protection. I get prompted for userid and password to show the workbench or the openrdf-sesame start page, that works fine.&lt;br/&gt;
&lt;br/&gt;
However when I try to work with the openrdf-sesame component in the openrdf-workbench, the URL is not accepted and the error message &amp;quot;Invalid server URL&amp;quot; is always shown. &lt;br/&gt;
&lt;br/&gt;
I tried these four versions of the URL (the workbench is on &lt;a href=&quot;http://my.server.com:8080/openrdf-workbench)&quot;&gt;http://my.server.com:8080/openrdf-workbench)&lt;/a&gt;&lt;br/&gt;
* &lt;a href=&quot;http://my.server.com:8080/openrdf-sesame&quot;&gt;http://my.server.com:8080/openrdf-sesame&lt;/a&gt;&lt;br/&gt;
* &lt;a href=&quot;http://user&quot;&gt;http://user&lt;/a&gt;:&lt;a href=&apos;mailto:pass@my.server.com&apos;&gt;pass@my.server.com&lt;/a&gt;:8080/openrdf-sesame&lt;br/&gt;
* &lt;a href=&quot;http://localhost:8080/openrdf-sesame&quot;&gt;http://localhost:8080/openrdf-sesame&lt;/a&gt;&lt;br/&gt;
* &lt;a href=&quot;http://use&quot;&gt;http://use&lt;/a&gt;:&lt;a href=&apos;mailto:pass@localhost&apos;&gt;pass@localhost&lt;/a&gt;:8080/openrdf-sesame&lt;br/&gt;
&lt;br/&gt;
The logs show the error message: &amp;quot;java.io.IOException: Server returned HTTP response code: 401 for URL:  &amp;lt;theURL&amp;gt;&amp;quot; for all those.&lt;br/&gt;
If there is a way to do this correctly I could not find it in the documentation.&lt;br/&gt;
&lt;br/&gt;
</description>
    
    
        <environment></environment>
    
        <key id="11740">SES-719</key>
        <summary>Unable to use the workbench when the repository is password-protected on the server</summary>
        <type id="1">Bug</type>
    
        <priority id="3">Major</priority>
    
        <status id="3">In Progress</status>
        
        <resolution>Unresolved</resolution>
        
    
        
        <assignee username="dwvisser">Dale W. Visser</assignee>
        
    

    
        
        <reporter username="johann_p">Johann Petrak</reporter>
        
    

        
        <created>Tue, 10 Aug 2010 18:07:21 +0200 (CEST)</created>
    <updated>Mon, 15 Oct 2012 17:58:15 +0200 (CEST)</updated>

    
        
        
            
            
                
                    <version>2.3.2</version>
                
            
        
    

    
        
        
            
            
                
                    <fixVersion>2.7.0</fixVersion>
                
            
        
    

    
        
        
            
            
                
                    <component>Web interface</component>
                
            
        
    

    
    
        <due></due>
    
    
        <votes>1</votes>
    
    

    
    
        <comments>
            
            <comment author="a903888" created="Tue, 3 Jan 2012 17:54:21 +0100 (CET)" level="">As workaround I succesfully did the following:&lt;br/&gt;
&lt;br/&gt;
- Install somewhere (preferibly on your local pc for a better security) an apache http web server (e.g. installing it from Xampp)&lt;br/&gt;
&lt;br/&gt;
- Configure the following Proxy rule replacing the encoded string with the user-id+password combination used for the basic authentication, and the &lt;a href=&quot;http://myserver&quot;&gt;http://myserver&lt;/a&gt;... with the URL of the actual installation&lt;br/&gt;
of the protected openrdf-sesame.war&lt;br/&gt;
(see &lt;a href=&quot;http://en.wikipedia.org/wiki/Basic_access_authentication&quot;&gt;http://en.wikipedia.org/wiki/Basic_access_authentication&lt;/a&gt; for a description of the encoding mechanism).&lt;br/&gt;
e.g.:&lt;br/&gt;
&amp;lt;Location /openrdf-sesame&amp;gt;&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;RewriteEngine on&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;RequestHeader append Authorization &amp;quot;Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==&amp;quot;&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;ProxyPass &lt;a href=&quot;http://myserver:8080/openrdf-sesame&quot;&gt;http://myserver:8080/openrdf-sesame&lt;/a&gt;&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;ProxyPassReverse &lt;a href=&quot;http://myserver:8080/openrdf-sesame&quot;&gt;http://myserver:8080/openrdf-sesame&lt;/a&gt;&lt;br/&gt;
&amp;lt;/Location&amp;gt;&lt;br/&gt;
&lt;br/&gt;
- unpack openrdf-workbench and change the init-param &amp;quot;default-server&amp;quot; pointing to the proxied url above described (in the example we assume a default apache installation listening on the port 80)&lt;br/&gt;
&amp;nbsp;		&amp;lt;init-param&amp;gt;&lt;br/&gt;
			&amp;lt;param-name&amp;gt;default-server&amp;lt;/param-name&amp;gt;&lt;br/&gt;
			&amp;lt;param-value&amp;gt;&lt;a href=&quot;http://localhost/openrdf-sesame&amp;lt;/param-value&quot;&gt;http://localhost/openrdf-sesame&amp;amp;lt;/param-value&lt;/a&gt;&amp;gt;&lt;br/&gt;
		&amp;lt;/init-param&amp;gt;&lt;br/&gt;
&lt;br/&gt;
- deploy the modified version of openrdf-workbench on a local app-server instance&lt;br/&gt;
&lt;br/&gt;
&lt;br/&gt;
</comment>
            
            <comment author="dwvisser" created="Mon, 15 Oct 2012 17:58:15 +0200 (CEST)" level="">Initial version of fix checked in (revision 11981). Not all unauthorized actions are being handled smoothly yet. I will probably do the simplest thing, and attempt to redirect to the log in screen whenever there is insufficient authorization.</comment>
            
        </comments>
    
    

    



    <issuelinks>
    
        <issuelinktype id="10002">
            <name>Dependency</name>
                
                
                
                
                
                    <inwardlinks description="is a dependency for">
                    
                        <issuelink>
                            <issuekey id="13720">SES-1048</issuekey>
                        </issuelink>
                    
                    </inwardlinks>
                
                
        </issuelinktype>
    
    </issuelinks>


    
    
    

</item>
    
<item>

    







<title>[SES-1114] Workbench needs JavaScript for correct functioning. Pages should include &lt;noscript&gt; tags.</title>
<link>http://www.openrdf.org/issues/browse/SES-1114</link>

    
        <description>Since the workbench needs JavaScript for proper functioning, pages should include a &amp;lt;noscript&amp;gt; tag with appropriate CSS styling applied to display a message to users that have JavaScript disabled. (e.g., NoScript users in Firefox and ScriptNo users in Chrome)</description>
    
    
        <environment>any</environment>
    
        <key id="14160">SES-1114</key>
        <summary>Workbench needs JavaScript for correct functioning. Pages should include &lt;noscript&gt; tags.</summary>
        <type id="1">Bug</type>
    
        <priority id="3">Major</priority>
    
        <status id="1">Open</status>
        
        <resolution>Unresolved</resolution>
        
    
        
        <assignee username="dwvisser">Dale W. Visser</assignee>
        
    

    
        
        <reporter username="dwvisser">Dale W. Visser</reporter>
        
    

        
        <created>Sat, 13 Oct 2012 16:20:07 +0200 (CEST)</created>
    <updated>Sat, 13 Oct 2012 16:20:07 +0200 (CEST)</updated>

    
        
        
            
            
                
                    <version>2.6.9</version>
                
            
        
    

    
        
        
            
            
                
                    <fixVersion>2.7.0</fixVersion>
                
            
        
    

    
        
        
            
            
                
                    <component>Web interface</component>
                
            
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
    

    




    
    
    

</item>
    
<item>

    







<title>[SES-1112] Improve transaction handling in RepositoryConnection</title>
<link>http://www.openrdf.org/issues/browse/SES-1112</link>

    
        <description>This involves several new methods in the API, including begin() to indicate the start of a transaction.</description>
    
    
        <environment></environment>
    
        <key id="14151">SES-1112</key>
        <summary>Improve transaction handling in RepositoryConnection</summary>
        <type id="2">New Feature</type>
    
        <priority id="1">Blocker</priority>
    
        <status id="1">Open</status>
        
        <resolution>Unresolved</resolution>
        
    
        
        <assignee username="jeen">Jeen Broekstra</assignee>
        
    

    
        
        <reporter username="jeen">Jeen Broekstra</reporter>
        
    

        
        <created>Wed, 10 Oct 2012 08:19:15 +0200 (CEST)</created>
    <updated>Thu, 11 Oct 2012 04:41:17 +0200 (CEST)</updated>

    
        
        
    

    
        
        
            
            
                
                    <fixVersion>2.7.0</fixVersion>
                
            
        
    

    
        
        
            
            
                
                    <component>Repository API</component>
                
            
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
        <comments>
            
            <comment author="james" created="Wed, 10 Oct 2012 14:51:34 +0200 (CEST)" level="">Many Java developers are familiar with &lt;a href=&quot;http://docs.oracle.com/javaee/5/api/javax/persistence/EntityTransaction.html&quot;&gt;http://docs.oracle.com/javaee/5/api/javax/persistence/EntityTransaction.html&lt;/a&gt; , which uses begin() to start a transaction and commit() to end it. However, since the commit() method of the RepositoryConnection not only ends a transaction, but also starts another one, it might be confusing to introduce a begin() method without changing the behaviour of commit (or introducing other methods to end the transaction).&lt;br/&gt;
&lt;br/&gt;
The RepositoryConnection already has a way to start a transcation setAutoCommit(false) and a way to end it setAutoCommit(true), it is a little counter intuitive, but any new methods (to begin/end transactions) would just duplicate this existing functionality.</comment>
            
            <comment author="jeen" created="Wed, 10 Oct 2012 22:41:18 +0200 (CEST)" level="">This is true, but I think the point is to actually make the API more intuitive (and also more in line with the underlying SAIL API, where a begin() will also be introduced). &lt;br/&gt;
&lt;br/&gt;
setAutoCommit will be marked deprecated. </comment>
            
            <comment author="jeen" created="Wed, 10 Oct 2012 22:42:52 +0200 (CEST)" level="">By the way, saying that commit() starts a new transaction is a funny way to look at it. In my opinion, a new transaction doesn&apos;t start until the first actual operation _after_ commit has been called. </comment>
            
            <comment author="jeen" created="Thu, 11 Oct 2012 04:41:17 +0200 (CEST)" level="">Thinking about it a bit more, I think I understand what you meant: in the current situation, if autocommit is set to false, and you call commit, the transaction up to then is committed but the connection remains in non-autocommit mode, so effectively a new transaction is started immediately. &lt;br/&gt;
&lt;br/&gt;
In the new situation, this will be different, as commit() will end the transaction, therefore automatically resetting the connection to autocommit mode, until begin() is called again. &lt;br/&gt;
&lt;br/&gt;
It&apos;s a good point to take into account, and we certainly need to document this carefully.</comment>
            
        </comments>
    
    

    




    
    
    

</item>
    
<item>

    







<title>[SES-1113] Add convenience methods for easy conversion or results to Java collections</title>
<link>http://www.openrdf.org/issues/browse/SES-1113</link>

    
        <description>New: &lt;br/&gt;
&lt;br/&gt;
CloseableIteration.addTo(Collection)&lt;br/&gt;
CloseableIteration.asList()&lt;br/&gt;
CloseableIteration.asSet()&lt;br/&gt;
GraphQueryResult.asGraph()&lt;br/&gt;
</description>
    
    
        <environment></environment>
    
        <key id="14152">SES-1113</key>
        <summary>Add convenience methods for easy conversion or results to Java collections</summary>
        <type id="4">Improvement</type>
    
        <priority id="3">Major</priority>
    
        <status id="1">Open</status>
        
        <resolution>Unresolved</resolution>
        
    
        
        <assignee username="jeen">Jeen Broekstra</assignee>
        
    

    
        
        <reporter username="jeen">Jeen Broekstra</reporter>
        
    

        
        <created>Wed, 10 Oct 2012 08:20:43 +0200 (CEST)</created>
    <updated>Wed, 10 Oct 2012 08:20:43 +0200 (CEST)</updated>

    
        
        
    

    
        
        
            
            
                
                    <fixVersion>2.7.0</fixVersion>
                
            
        
    

    
        
        
            
            
                
                    <component>Query Engine</component>
                
                    <component>Repository API</component>
                
            
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
    

    




    
    
    

</item>
    
<item>

    







<title>[SES-1110] SPARQL query with ORDER BY in Workbench returns query.xml with results attribute ordered set to &apos;false&apos;</title>
<link>http://www.openrdf.org/issues/browse/SES-1110</link>

    
        <description>In attempting to reproduce &lt;a href=&quot;http://www.openrdf.org/issues/browse/SES-1109&quot; title=&quot;SPARQL 1.1 HAVING when used with aggrateions fails with &amp;quot;Node is not a child node&amp;quot;&quot;&gt;&lt;strike&gt;SES-1109&lt;/strike&gt;&lt;/a&gt;, I noticed that, even though the query produced ordered results correctly, there is an attribute on the results node, &apos;ordered&apos;, set to &apos;false&apos;. There is no such attribute specified at &lt;a href=&quot;http://www.w3.org/TR/rdf-sparql-XMLres/&quot;&gt;http://www.w3.org/TR/rdf-sparql-XMLres/&lt;/a&gt;&lt;br/&gt;
&lt;br/&gt;
See &lt;a href=&quot;http://www.openrdf.org/issues/browse/SES-1109&quot; title=&quot;SPARQL 1.1 HAVING when used with aggrateions fails with &amp;quot;Node is not a child node&amp;quot;&quot;&gt;&lt;strike&gt;SES-1109&lt;/strike&gt;&lt;/a&gt; for full details on steps taken, and for the XML result.</description>
    
    
        <environment>Ubuntu 12.04 LTS, Tomcat 7</environment>
    
        <key id="14141">SES-1110</key>
        <summary>SPARQL query with ORDER BY in Workbench returns query.xml with results attribute ordered set to &apos;false&apos;</summary>
        <type id="1">Bug</type>
    
        <priority id="5">Trivial</priority>
    
        <status id="1">Open</status>
        
        <resolution>Unresolved</resolution>
        
    
        
        <assignee username="jeen">Jeen Broekstra</assignee>
        
    

    
        
        <reporter username="dwvisser">Dale W. Visser</reporter>
        
    

        
        <created>Mon, 1 Oct 2012 18:14:34 +0200 (CEST)</created>
    <updated>Mon, 1 Oct 2012 21:51:20 +0200 (CEST)</updated>

    
        
        
            
            
                
                    <version>2.6.9</version>
                
            
        
    

    
        
        
    

    
        
        
            
            
                
                    <component>SPARQL</component>
                
                    <component>Web interface</component>
                
            
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
    

    




    
    
    

</item>
    
<item>

    







<title>[SES-1085] Support execution of SPARQL updates in SPARQLRepository</title>
<link>http://www.openrdf.org/issues/browse/SES-1085</link>

    
        <description></description>
    
    
        <environment></environment>
    
        <key id="14000">SES-1085</key>
        <summary>Support execution of SPARQL updates in SPARQLRepository</summary>
        <type id="4">Improvement</type>
    
        <priority id="3">Major</priority>
    
        <status id="3">In Progress</status>
        
        <resolution>Unresolved</resolution>
        
    
        
        <assignee username="jeen">Jeen Broekstra</assignee>
        
    

    
        
        <reporter username="jeen">Jeen Broekstra</reporter>
        
    

        
        <created>Fri, 24 Aug 2012 16:44:38 +0200 (CEST)</created>
    <updated>Fri, 28 Sep 2012 01:39:44 +0200 (CEST)</updated>

    
        
        
    

    
        
        
            
            
                
                    <fixVersion>2.7.0</fixVersion>
                
            
        
    

    
        
        
            
            
                
                    <component>SPARQL</component>
                
            
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
    

    




    
    
    

</item>
    
<item>

    







<title>[SES-1066] Support background parsing/concurrent reading of query results</title>
<link>http://www.openrdf.org/issues/browse/SES-1066</link>

    
        <description>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. &lt;br/&gt;
&lt;br/&gt;
We should look at implementing a background-parsing strategy similar to what SPARQLRepository supports.&lt;br/&gt;
&lt;br/&gt;
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&apos;s XML transaction format, and instead just work with SPARQL Updates. </description>
    
    
        <environment></environment>
    
        <key id="13870">SES-1066</key>
        <summary>Support background parsing/concurrent reading of query results</summary>
        <type id="4">Improvement</type>
    
        <priority id="2">Critical</priority>
    
        <status id="1">Open</status>
        
        <resolution>Unresolved</resolution>
        
    
        
        <assignee username="jeen">Jeen Broekstra</assignee>
        
    

    
        
        <reporter username="jeen">Jeen Broekstra</reporter>
        
    

        
        <created>Wed, 25 Jul 2012 22:47:18 +0200 (CEST)</created>
    <updated>Fri, 28 Sep 2012 01:07:29 +0200 (CEST)</updated>

    
        
        
    

    
        
        
            
            
                
                    <fixVersion>2.7.0</fixVersion>
                
            
        
    

    
        
        
            
            
                
                    <component>HTTPRepository</component>
                
            
        
    

    
    
        <due></due>
    
    
        <votes>1</votes>
    
    

    
    
        <comments>
            
            <comment author="jeen" created="Fri, 28 Sep 2012 01:07:29 +0200 (CEST)" level="">checked in implementation of background result parsing in revision 11972. Initial tests greenline. Need to take closer look at thread handling, making sure stuff is properly closed and no memory leaks are introduced.</comment>
            
        </comments>
    
    

    



    <issuelinks>
    
        <issuelinktype id="10000">
            <name>Duplicate</name>
                
                
                
                
                
                    <inwardlinks description="is duplicated by">
                    
                        <issuelink>
                            <issuekey id="13910">SES-1070</issuekey>
                        </issuelink>
                    
                    </inwardlinks>
                
                
        </issuelinktype>
    
    </issuelinks>


    
    
    

</item>
    
<item>

    







<title>[SES-1106] Workbench Query page on Internet Explorer 9 only works in &quot;compatibility mode&quot;</title>
<link>http://www.openrdf.org/issues/browse/SES-1106</link>

    
        <description>Trying to use the Query page in Workbench doesn&apos;t work &amp;quot;out of the box&amp;quot; in Internet Explorer 9. It is necessary to place the browser in &amp;quot;compatibility mode&amp;quot; by clicking on the icon on the right-hand side of the address box.&lt;br/&gt;
&lt;br/&gt;
In version 2.6.9, the query box fails to pre-populate with the  query namespaces.  When you invoke compatibility mode, it populates with a bunch of HTML debris in addition to the namespace text for *both* query languages.&lt;br/&gt;
&lt;br/&gt;
In my local version which includes trunk Revision 11970 and my fix for &lt;a href=&quot;http://www.openrdf.org/issues/browse/SES-1105&quot; title=&quot;Query Page javascript broken on Internet Explorer 9&quot;&gt;&lt;strike&gt;SES-1105&lt;/strike&gt;&lt;/a&gt;, the query form doesn&apos;t even show. When you invoke compatibility mode, it works correctly, except that the pre-populated query namespace text doesn&apos;t have carriage returns in the &amp;quot;right&amp;quot; places like it does in Chrome and Firefox.</description>
    
    
        <environment>Internet Explorer 9 and Workbench</environment>
    
        <key id="14121">SES-1106</key>
        <summary>Workbench Query page on Internet Explorer 9 only works in &quot;compatibility mode&quot;</summary>
        <type id="1">Bug</type>
    
        <priority id="4">Minor</priority>
    
        <status id="1">Open</status>
        
        <resolution>Unresolved</resolution>
        
    
        
        <assignee username="arjohn">Arjohn Kampman</assignee>
        
    

    
        
        <reporter username="dwvisser">Dale W. Visser</reporter>
        
    

        
        <created>Fri, 21 Sep 2012 19:41:41 +0200 (CEST)</created>
    <updated>Fri, 21 Sep 2012 19:41:41 +0200 (CEST)</updated>

    
        
        
            
            
                
                    <version>2.6.9</version>
                
            
        
    

    
        
        
    

    
        
        
            
            
                
                    <component>Web interface</component>
                
            
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
    

    




    
    
    

</item>
    
<item>

    







<title>[SES-1103] UnsupportedRDFormatException in transaction mode</title>
<link>http://www.openrdf.org/issues/browse/SES-1103</link>

    
        <description>When I turn on transaction mode (con.setAutoCommit(false);), I always get UnsupportedRDFFormatException when trying to add new files.  It does not matter if I have turtle or ntriple or ... files.&lt;br/&gt;
&lt;br/&gt;
I add files using method add(File file, String baseURI, RDFFormat dataFormat, Resource... contexts).&lt;br/&gt;
&lt;br/&gt;
When not using transaction mode everything works fine.</description>
    
    
        <environment></environment>
    
        <key id="14110">SES-1103</key>
        <summary>UnsupportedRDFormatException in transaction mode</summary>
        <type id="1">Bug</type>
    
        <priority id="3">Major</priority>
    
        <status id="1">Open</status>
        
        <resolution>Unresolved</resolution>
        
    
        
        <assignee username="jeen">Jeen Broekstra</assignee>
        
    

    
        
        <reporter username="katja.pfeifer">Katja Pfeifer</reporter>
        
    

        
        <created>Thu, 20 Sep 2012 15:19:06 +0200 (CEST)</created>
    <updated>Thu, 20 Sep 2012 22:47:53 +0200 (CEST)</updated>

    
        
        
            
            
                
                    <version>2.6.9</version>
                
            
        
    

    
        
        
    

    
        
        
            
            
                
                    <component>Rio</component>
                
            
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
    

    




    
    
    

</item>
    
<item>

    







<title>[SES-1104] Proxy environment variables hard to be set from shells</title>
<link>http://www.openrdf.org/issues/browse/SES-1104</link>

    
        <description>Hi,&lt;br/&gt;
&lt;br/&gt;
because of the . in the variable names (see: see: &lt;a href=&quot;http://www.openrdf.org/issues/browse/SES-929&quot;&gt;http://www.openrdf.org/issues/browse/SES-929&lt;/a&gt;&lt;br/&gt;
) I currently run into issues on Unix. Bash won&apos;t support setting environment variables that contain dots, see: &lt;br/&gt;
&lt;a href=&quot;http://www.linuxquestions.org/questions/linux-general-1/is-it-possible-to-set-an-environment-variable-name-containing-a-period-in-bash-724256/&quot;&gt;http://www.linuxquestions.org/questions/linux-general-1/is-it-possible-to-set-an-environment-variable-name-containing-a-period-in-bash-724256/&lt;/a&gt; and &lt;a href=&quot;http://stackoverflow.com/questions/2821043/allowed-characters-in-linux-environment-variable-names&quot;&gt;http://stackoverflow.com/questions/2821043/allowed-characters-in-linux-environment-variable-names&lt;/a&gt;&lt;br/&gt;
&lt;br/&gt;
Would it be possible for you to rename the variables, e.g. using an underscore: http_proxyHost, ...&lt;br/&gt;
&lt;br/&gt;
Another solution I see to enable better cross-platform support would be to not use environment variables but system properties instead.&lt;br/&gt;
&lt;br/&gt;
</description>
    
    
        <environment>Unix, Bash shell</environment>
    
        <key id="14111">SES-1104</key>
        <summary>Proxy environment variables hard to be set from shells</summary>
        <type id="4">Improvement</type>
    
        <priority id="3">Major</priority>
    
        <status id="1">Open</status>
        
        <resolution>Unresolved</resolution>
        
    
        
        <assignee username="arjohn">Arjohn Kampman</assignee>
        
    

    
        
        <reporter username="robert.rieger">Robert Rieger</reporter>
        
    

        
        <created>Thu, 20 Sep 2012 16:57:39 +0200 (CEST)</created>
    <updated>Thu, 20 Sep 2012 16:57:39 +0200 (CEST)</updated>

    
        
        
            
            
                
                    <version>2.6.9</version>
                
            
        
    

    
        
        
    

    
        
        
            
            
                
                    <component>HTTPRepository</component>
                
                    <component>SPARQL</component>
                
            
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
    

    




    
    
    

</item>
    
</channel>
</rss>  

