Mulgara Project: Issueshttps://code.mulgara.org/https://code.mulgara.org/favicon.ico?15861924492009-10-20T08:30:52ZMulgara Project
Redmine Mulgara - Bug #208 (New): Subqueries not supported via RESThttps://code.mulgara.org/issues/2082009-10-20T08:30:52ZEric Kobrin -ekobrin-mulgara@velocitude.com
<p>When making a TQL REST request containing subqueries, <code>StreamedSparqlJSONAnswer</code> throws an exception due to addBinding() not supporting @TransactionalAnswer@s.</p> Mulgara - Bug #204 (New): TQL Causing Mulgara to hang (regression from 2.0.9 to 2.1.3)https://code.mulgara.org/issues/2042009-09-16T23:13:52ZDragisa Krsmanovic -dkrsmanovic@plos.org
<p>This particular query <em>never</em> returns in Mulgara 2.1.3</p>
<p>In Mulgara 2.0.9 it, correctly, returns with no results under one minute.</p>
<p>Same database was used for testing.</p>
<pre>
select $art $oqltmp1_1 $score0 from <local:///topazproject#prefix>
where $art <rdf:type> <http://rdf.topazproject.org/RDF/Article> in <local:///topazproject#filter:graph=ri>
and $art <http://purl.org/dc/terms/bibliographicCitation> $oqltmp2_2 in <local:///topazproject#filter:graph=ri>
and $oqltmp2_2 <http://rdf.plos.org/RDF/hasEditorList> $oqltmp2_3 in <local:///topazproject#filter:graph=ri>
and $oqltmp2_4 <mulgara:prefix> <rdf:_> in <local:///topazproject#prefix>
and $oqltmp2_3 $oqltmp2_4 $oqltmp2_1 in <local:///topazproject#filter:graph=ri>
and $oqltmp2_1 <mulgara:search> $oqltmp2_7fs in <local:///topazproject#lucene>
and $oqltmp2_7fs <http://xmlns.com/foaf/0.1/name> '"niyaz ahmed"' in <local:///topazproject#lucene>
and $oqltmp2_7fs <mulgara:score> $score0 in <local:///topazproject#lucene>
and $art <http://prismstandard.org/namespaces/1.2/basic/eIssn> $oqltmp1_1 in <local:///topazproject#filter:graph=ri>;
</pre> Mulgara - Bug #202 (New): SPARQL queries with non-ascii chars failhttps://code.mulgara.org/issues/2022009-09-06T14:49:10ZGregg -gar@foo.bar
<p>I'm able to successfully load UTF-8 data with non-ascii characters, both in URIs and in literals (Mulgara 2.1.3). SPARQL queries against the data succeed so long as such non-ascii values match variables. However, if the query itself contains non-ascii chars it fails.</p>
<p>For example, if my data includes something like<br /><pre>
eg:Foo a eg:Füß
</pre><br />then a query like<br /><pre>
SELECT ?z WHERE { <eg:Foo> a ?z .}
</pre><br />will succeed, but one like<br /><pre>
SELECT ?x WHERE { ?x a <eg:füß> . }
</pre></p>
<p>will fail.</p>
<p>This is a show-stopper for me, since I need non-ascii Unicode in both my data and my queries.</p> Mulgara - Bug #199 (New): TQL Load data encodinghttps://code.mulgara.org/issues/1992009-09-06T14:14:16ZGregg -gar@foo.bar
<pre>
To see this, take any ascii file, save it in emacs with latin-1 encoding, try to load it, get the error message. Then save it as utf-8 and it loads fine.
Ideally one should be able to specify any input encoding, but at a minimum I would suggest support for any form of Unicode, the (16?) ISO Latin encodings, one or two of the standard Japanese encodings, maybe a Chinese and Russian (KOI-8?).
I'm not sure how one would specify this; it should probably be specified in an HTTP header. I looked at the "SPARQL 2":http://www.w3.org/TR/sparql-features/#sparql-update new features draft and the "SPARUL":http://www.w3.org/Submission/2008/SUBM-SPARQL-Update-20080715/ stuff but I don't see any mention of charset stuff.</pre> Mulgara - Bug #197 (New): SPARQL results char encodinghttps://code.mulgara.org/issues/1972009-09-01T19:59:32ZGregg -gar@foo.bar
<p>The SPARQL Protocol definition says that for the HTTP binding "the whttp:outputSerialization is application/sparql-results+xml with UTF-8 encoding, application/rdf+xml with<br />UTF-8 encoding." (<a href="http://www.w3.org/TR/rdf-sparql-protocol/#query-bindings-http" class="external">Section 2.2</a>) That's for XML results; I haven't found the equivalent requirement for JSON output, but for my application in any case full utf-8 support for json and xml is essential.</p>
<p>As a general matter (principle of least surprise), I think the expected behavior would be "encoding-in equals encoding-out", so if I populate a graph with utf-8 data, query results should be utf-8, no matter the output serialization. Alternatively, one could argue that the standard HTTP 1.1 Accept-Charset header should govern; since it is an HTTP binding, HTTP rules should apply.</p>
<p>The SPARQL Protocol definition doesn't explicitly address character encoding for the SOAP binding, but since SOAP is an HTTP protocol it should probably do utf-8 or honor the Accept-Charset header.</p> Mulgara - Bug #195 (New): Server IO Exceptionhttps://code.mulgara.org/issues/1952009-08-29T16:45:42ZGregg -gar@foo.bar
<p>I'm see the server dump a stack frame when I run a query using curl. I'm trying to query the system graph, on a freshly installed server with no loaded graphs. I don't know if I'm doing this right, but I don't think the server should barf. The curl file is:<br /><pre>
--url = "http://localhost:8080/sparql/"
--include
--header "Accept: application/sparql-results+xml"
--get
--data-urlencode "query=select ?x ?y ?z where {?x ?y ?z}"
--data-urlencode "default-graph-uri=http://localhost:8080/#"
</pre></p>
<p>mulgara.log says:<br /><pre>
2009-08-29 11:37:56,505 WARN [btpool0-17 - /sparql/?query=select%20%3Fx%20%3Fy%20%3Fz%20where%20%7B%3Fx%20%3Fy%20%3Fz%7D&default-graph-uri=http%3A%2F%2Flocalhost%3A8080%2F%23] http.HttpContent - Ignoring bad parameters in ' charset=iso-8859-1' from the content type for http://localhost:8080/#
2009-08-29 11:37:56,512 WARN [btpool0-17 - /sparql/?query=select%20%3Fx%20%3Fy%20%3Fz%20where%20%7B%3Fx%20%3Fy%20%3Fz%7D&default-graph-uri=http%3A%2F%2Flocalhost%3A8080%2F%23] http.HttpContent - Ignoring bad parameters in ' charset=iso-8859-1' from the content type for http://localhost:8080/#
2009-08-29 11:37:56,863 WARN [Thread-46] rdfxml.Parser - Recoverable error, line 1, column 122: {E213} Server returned HTTP response code: 503 for URL: http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd
java.io.IOException: Server returned HTTP response code: 503 for URL: http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd
at com.hp.hpl.jena.rdf.arp.impl.XMLHandler.generalError(XMLHandler.java:197)
at com.hp.hpl.jena.rdf.arp.impl.RDFXMLParser.parse(RDFXMLParser.java:113)
at com.hp.hpl.jena.rdf.arp.ARP.load(ARP.java:143)
at org.mulgara.content.rdfxml.Parser.run(Parser.java:297)
Caused by: java.io.IOException: Server returned HTTP response code: 503 for URL: http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1305)
at org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(Unknown Source)
at org.apache.xerces.impl.XMLEntityManager.startEntity(Unknown Source)
at org.apache.xerces.impl.XMLEntityManager.startDTDEntity(Unknown Source)
at org.apache.xerces.impl.XMLDTDScannerImpl.setInputSource(Unknown Source)
at org.apache.xerces.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at com.hp.hpl.jena.rdf.arp.impl.RDFXMLParser.parse(RDFXMLParser.java:106)
... 2 more
</pre></p> Mulgara - Bug #191 (New): Search is slow when Lucene writes to diskhttps://code.mulgara.org/issues/1912009-08-13T22:22:01ZPaula Gearon
<p>Often, if a search is exceptionally slow, much of that time is wasted when Lucene decides that its results need to be sorted. If the quantity of data to be sorted does not fit into memory, then Lucene swaps it out to disk, radically slowing what would otherwise be a fast set of comparisons.</p>
<p>Most of this sorting is useless and can occur anywhere in the search process (e.g., when combining two datasets in the midst of a larger query, or sorting the entire result set before returning it).</p>
<p>Tuning Lucene (telling it to sort only when necessary) and/or changing the OQL used in searches may vastly improve response times in some cases.</p>
<p>Example: on a full corpus, enable date searching (currently disabled in <a class="wiki-page new" href="https://code.mulgara.org/projects/mulgara/wiki/SearchAction">SearchAction</a>.java lines 155 to 164 due to excessive query slowness) and search PLoS One for:</p>
<p>gene AND date:[2008-05-16 TO 2009-01-26]</p> Mulgara - Bug #190 (New): tql swallows uri fragmentshttps://code.mulgara.org/issues/1902009-08-13T22:03:23ZPaula Gearon
<p>eg. In the following query result, the #all is missing<br /><pre>
itql> select $o from <local:///topazproject#grants> where $s $p $o
and $o <mulgara:is> <topaz:permissions#all>;
variables: {"o"}
cnt = 1
o
-------------------
<topaz:permissions>
</pre></p> Mulgara - Bug #188 (New): Zipped N3 files not recognized when loadinghttps://code.mulgara.org/issues/1882009-06-26T01:42:29ZPaula Gearon
<p>Loading a zipped N3 file successfully unzips the file, but doesn't recognize the extension as referring to an N3 file. As a result, the system falls back to the RDF/XML content handler, which naturally fails.</p>
<p>This should be fixable if the content handler starts looking for .n3.gz as well as .n3.</p> Mulgara - Bug #164 (New): Timer no longer workinghttps://code.mulgara.org/issues/1642008-11-04T15:32:47ZPaula Gearon
<p>The "set time on" command is no longer working, apparently since the Command interface was introduced.</p>
<p>This is to be implemented on the client side.</p> Mulgara - Bug #162 (New): Transactions involving transactional resolvers do not have snapshot iso...https://code.mulgara.org/issues/1622008-10-23T13:40:30Zronald -ronald@foo.bar
<p>See <a class="external" href="http://www.topazproject.org/trac/ticket/1036">http://www.topazproject.org/trac/ticket/1036</a> for the scenario. Because<br />resolvers are enlisted lazily, mulgara suffers from the same problem. But<br />attempting to always enlist all resolvers at the beginning of every transaction<br />may be quite expensive, and is also in the case of the distributed resolver<br />nearly impossible.</p>
<p>We may want to add a flag so users can choose whether they want this or not.</p> Mulgara - Bug #108 (New): Triggering constraints in Krulehttps://code.mulgara.org/issues/1082008-05-17T21:55:23ZPaula Gearon
<p>When Krule runs a rule, it triggers other rules that it affects the underlying constraints for. These triggered rules test if they should run by comparing the size of their resolution to the last time they were run, and proceeding if that size has changed.</p>
<p>This needs to become a 2 stage process. Rules should trigger constraints, and constraints should run the above test. If the size of a constraint resolution changes, then it triggers the rule that it belongs to.</p> Mulgara - Bug #95 (New): Remote backups not compressedhttps://code.mulgara.org/issues/952008-04-03T22:40:17ZPaula Gearon
<p>When calling remote backup on a graph on a server (meaning the server saves the file to the local filesystem) the backup file is not compressed if the backup file ends in .gz. This contradicts remote load, which will try to decompress files that end in .gz.</p>
<p>Local load and graph backup are always uncompressed, regardless of filename.</p> Mulgara - Bug #31 (New): resolveVariableModel does not check securityAdaptorListhttps://code.mulgara.org/issues/312006-11-10T07:01:02ZAndrae Muys -andrae@netymon.com
<pre>
<code class="html syntaxhl">This allows queries containing variable models to bypass the security layer.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Mulgara currently doesn't have any security modules in its distribution - so this code path is currently only used by various unit-tests. This bug must be fixed when we come to implement security modules.
</code></pre> Mulgara - Bug #8 (New): Temp directory managementhttps://code.mulgara.org/issues/82006-07-11T13:50:53Zbrian -brian@foo.bar
<pre>
<code class="html syntaxhl">A research group has reported seeing Kowari fill up temp directories and fall over. This was on Solaris, but it might be a more general problem to solve. Nothing to reproduce it yet, but I just wanted to capture the experience to potentially investigate this issue moving forward.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
The usage pattern was one big load and then mostly queries with the occasional insert.
</code></pre>