Mulgara Project: Issueshttps://code.mulgara.org/https://code.mulgara.org/favicon.ico?15861924492012-02-07T21:37:21ZMulgara Project
Redmine Mulgara - Bug #213 (New): Error on ORDER BY variables projected away by SELECT clausehttps://code.mulgara.org/issues/2132012-02-07T21:37:21ZAlex Hall -alexhall@revelytix.com
<p>A SPARQL query that mentions a variable in an ORDER BY expression that appears in the WHERE clause but is projected away by the SELECT clause incorrectly causes an exception to be thrown. According to SPARQL, ordering is applied prior to projection, so this should be valid. This appears to be a case where TQL and SPARQL semantics are mis-aligned.</p> Mulgara - Bug #201 (New): Accept-Charset HTTP header not honoredhttps://code.mulgara.org/issues/2012009-09-06T14:39:02ZGregg -gar@foo.bar
<p>(This ticket obsoletes <a class="issue tracker-3 status-3 priority-33 priority-high2" title="Bug: SPARQL results char encoding (New)" href="https://code.mulgara.org/issues/197">#197</a>)</p>
<p>Currently there doesn't seem to be a way to request a specific character encoding for query results. I think the way to do this is via content negotiation; at least I haven't seen any way to make such a request in SPARQL, but I might be wrong about that. In any case, I need a way to definitely indicate that I want utf-8 for the results.</p>
<p>The Mulgara HTTP interfaces (version 2.1.3) don't seem to honor the Accept-Charset header. Ideally it should be possible to use the header to stipulate any encoding for XML results. For JSON results, it should be possible to stipulate any UTF (utf-8, utf-16, utf-32) or UCS (UCS-4; I understand UCS-2 is obsolete.)</p> Mulgara - Bug #189 (New): Cascading FILTERs ignores all FILTERs except the last onehttps://code.mulgara.org/issues/1892009-06-26T01:44:50ZPaula Gearon
<p>If multiple FILTERs are applied in a row, only the last one is recognized.</p> Mulgara - Bug #177 (New): Help does not work from jLine prompthttps://code.mulgara.org/issues/1772009-01-22T16:38:24ZPaula Gearon
<p>When "help;" is typed at the CLI provided by jLine, nothing happens.</p> Mulgara - Bug #176 (New): A more descriptive exception needed in case of triples modifications to...https://code.mulgara.org/issues/1762009-01-08T00:20:08Zamit -amit@foo.bar
<p>The exception thrown by Mulgara when triple operations are peformed on a non-existent graph is quite confusing. For example, currently you might see:</p>
<pre>
org.mulgara.query.QueryException: Unsupported protocol for destination graph (local, -1 : 'local')
</pre>
<p>It would be a little more useful to see:</p>
<pre>
org.mulgara.query.MissingGraphException: Graph <graph uri> not created in store.
</pre>
<p>or something like that.</p> Mulgara - Bug #174 (New): FILTERs external to an OPTIONAL applied inside the OPTIONALhttps://code.mulgara.org/issues/1742008-12-02T18:05:40ZPaula Gearon
<p>Based on Jim Irwin's report:<br />I wrote a SPARQL query that attempts to find all the root classes of an<br />ontology, i.e. those that are not subclasses of classes other than<br />owl:Thing and rdfs:Class.</p>
<p>Setting aside for the moment the question of whether this is the best<br />approach to finding the root classes, here is the SPARQL that I ran:</p>
<p>SELECT DISTINCT ?root<br />WHERE
{
{
{ ?root rdf:type owl:Class . }<br /> UNION
{ ?root rdf:type rdfs:Class . }<br /> FILTER ( (?root != owl:Thing) && (?root != rdfs:Class) )<br /> }<br /> OPTIONAL {<br /> ?root rdfs:subClassOf ?sup .<br /> FILTER ( (?sup != owl:Thing) && (?sup != rdfs:Class) )<br /> }<br /> FILTER ( !bound(?sup) )<br /> }<br />ORDER BY ?root<br />}}</p>
<p>I ran the query against the FOAF ontology, and got eight results:<br /> <a class="external" href="http://www.w3.org/2000/10/swap/pim/contact#Person">http://www.w3.org/2000/10/swap/pim/contact#Person</a><br /> <a class="external" href="http://www.w3.org/2003/01/geo/wgs84_pos#SpatialThing">http://www.w3.org/2003/01/geo/wgs84_pos#SpatialThing</a><br /> <a class="external" href="http://xmlns.com/wordnet/1.6/Agent">http://xmlns.com/wordnet/1.6/Agent</a><br /> <a class="external" href="http://xmlns.com/wordnet/1.6/Agent-3">http://xmlns.com/wordnet/1.6/Agent-3</a><br /> <a class="external" href="http://xmlns.com/wordnet/1.6/Document">http://xmlns.com/wordnet/1.6/Document</a><br /> <a class="external" href="http://xmlns.com/wordnet/1.6/Organization">http://xmlns.com/wordnet/1.6/Organization</a><br /> <a class="external" href="http://xmlns.com/wordnet/1.6/Person">http://xmlns.com/wordnet/1.6/Person</a><br /> <a class="external" href="http://xmlns.com/wordnet/1.6/Project">http://xmlns.com/wordnet/1.6/Project</a></p>
<p>However, there is actually another root class in FOAF, the<br />foaf:OnlineAccount class. That class is defined as</p>
<pre><code>&lt;owl:Class rdf:about="OnlineAccount"&gt;<br /> &lt;rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/&gt;<br /> &lt;vs:term_status&gt;unstable&lt;/vs:term_status&gt;<br /> &lt;rdfs:label&gt;Online Account&lt;/rdfs:label&gt;<br /> &lt;rdfs:comment&gt;An online account.&lt;/rdfs:comment&gt;<br /> &lt;rdfs:isDefinedBy rdf:resource=""/&gt;<br /> &lt;rdfs:subClassOf rdf:resource="http://www.w3.org/2002/07/owl#Thing"/&gt;<br /> &lt;/owl:Class&gt;</code></pre>
<p>Note the foaf:OnlineAccount rdfs:subClassOf owl:Thing triple.</p>
<p>Here's my question: In my SPARQL query's OPTIONAL group, I filter out<br />all the rdfs:subClassOf triples that contain owl:Thing or rdfs:Class as<br />the object. So I would expect that the ?sup variable would not be bound<br />outside that group, and that foaf:OnlineAccount would pass the<br />!bound(?sup) filter. However, it appears that it does not pass the<br />filter, as if the !bound filter were being applied inside the OPTIONAL<br />group rather than outside it.</p>
<p>Just for comparison, I ran the same query using Jena, and<br />foaf:OnlineAccount does appear in the results list when using Jena, as I<br />would expect it to.</p> Mulgara - Bug #159 (New): Correct license on recent sourcehttps://code.mulgara.org/issues/1592008-10-23T02:53:27ZPaula Gearon
<p>All recent files were supposed to be with the Apache license, but unfortunately my macros have still been creating OSL files. These need to be corrected.</p> Mulgara - Bug #154 (New): HTTP uploads of RDF/XML can give errorhttps://code.mulgara.org/issues/1542008-10-17T01:59:11ZPaula Gearon
<p>The Jena parser for RDF/XML can fail to register the final </rdf:RDF> tag if it is immediately followed by a new line. Loading from a file is OK, but an <a class="wiki-page new" href="https://code.mulgara.org/projects/mulgara/wiki/InputStream">InputStream</a> can lead to an error if this condition occurs.</p> Mulgara - Bug #136 (New): IntervalConstraintDescriptor converts all bounds to xsd:doublehttps://code.mulgara.org/issues/1362008-08-04T20:04:13ZAlex Hall -alexhall@revelytix.com
<p>The <code>Bounds</code> object used by <code>IntervalConstraintDescriptor</code> to store the upper and lower bounds of a constraint stores the bounds as doubles. The <code>IntervalConstraintDescriptor.resolve(...)</code> method always uses <code>SPDouble</code> objects constructed from these bounds when slicing the stringpool. This makes it impossible to compare on datatypes derived from <code>xsd:decimal</code> (i.e. <code>xsd:int</code>, <code>xsd:long</code>, etc).</p>
<p>For instance, the following sequence of TQL commands produces no results:</p>
<pre>
create <rmi://localhost/server1#test>;
insert <test:foo> <rdf:value> '1'^^<http://www.w3.org/2001/XMLSchema#int>
into <rmi://localhost/server1#test>;
select $x from <rmi://localhost/server1#test> where
$x <mulgara:gt> '0'^^<http://www.w3.org/2001/XMLSchema#int> in <sys:xsd>;
</pre> Mulgara - Bug #134 (New): Jar files contain duplicateshttps://code.mulgara.org/issues/1342008-07-24T22:17:10ZPaula Gearon
<p>There are multiple occurrences of several files in the distribution jars. For instance, grepping for the Castor generated file Jetty:<br /><pre>
$ jar tf mulgara-2.0.0.jar | grep 'Jetty\.class'
org/mulgara/config/Jetty.class
org/mulgara/config/Jetty.class
org/mulgara/config/Jetty.class
org/mulgara/config/Jetty.class
org/mulgara/config/Jetty.class
</pre></p>
<p>The final jars are built out of several sub-jars, which is where the duplicates come from. These duplicates need to be removed.</p> Mulgara - Bug #132 (New): GraphAnswer improperly builthttps://code.mulgara.org/issues/1322008-07-10T00:54:09ZPaula Gearon
<p>This class was built as a result type for CONSTRUCT queries, as per <a class="issue tracker-9 status-27 priority-27 priority-high3 closed" title="Feature: CONSTRUCT SPARQL queries (Closed)" href="https://code.mulgara.org/issues/112">#112</a>. As DESCRIBE queries also return graphs, the initial implementation is also used as the result type for these queries as well.</p>
<p>Unfortunately, when I first built CONSTRUCT I was half thinking of how they are used in TQL INSERT/SELECT queries, where a multiple of 3 selection items are automatically inserted into the correct column. This translated into the GraphAnswer object accepting only 3 columns of results, and renaming these to "subject", "predicate" and "object". This is incorrect, as it prevents templates from having more than 3 columns (they must be a multiple of 3), prevents sorting by selected variables, and disallows different variable names. These are all incorrect.</p>
<p>CONSTRUCT queries are converted to SELECT queries with a multiple of 3 columns. The appropriate Answer will still have only 3 columns, which may be renamed to "subject", "predicate", and "object", but it must wrap this wider Answer, and not a 3 column Answer as is currently presumed.</p>
<p>The implementation will keep an internal counter for iterating over groups of 3 columns in the wrapped Answer with each call to <code>next()</code>. This continues until the end of a row. At the end of a row, the counter resets to zero, and the wrapped Answer has next() called on it. If this <em>wrapping</em> Answer is applied late enough, then sorting will be handled automatically.</p>
<p>DESCRIBE queries need not change from their current implementation, but if this happens then sorting will not be applied. Given that DESCRIBE has no requirements on returned data, this may be acceptable. However, there is an alternative.</p>
<p>Like CONSTRUCT queries, DESCRIBE can have their own Answer type that wraps a given Answer. In this case, we can presume DESCRIBE queries to return multiple columns, with the first 2 given the labels of "predicate" and "object". All other columns will be mapped to "subject". The implementation will need to scan each of these columns to find that <em>one</em> column that is bound for that row, and return that as the subject. Again, this will provide sorting, if the wrapper is applied late enough.</p>
<p>Both types of Answer will appear to have only 3 Variables: "subject", "predicate" and "object". Many of the filtering characteristics will also be the same, in that Subjects cannot be a Literal, and Predicate cannot be a Literal nor a Blank Node. For this reason, GraphAnswer should be changed to an abstract class implementing this functionality, with the implementations of <code>next()</code> and <code>getObject()</code> performed in the extending classes.</p> Mulgara - Bug #81 (In Progress): Blank Node Assignment in Inserts inconsistent with autocommithttps://code.mulgara.org/issues/812008-02-28T06:23:04ZAndrae Muys -andrae@netymon.com
<p>It appears that the binding of variables to blank nodes when inserting <br />statements behaves differently depending on whether autocommit is turned <br />on for the session. If I have autocommit turned on and execute the <br />following iTQL commands:<br /><pre>
create <rmi://localhost/server1#test>;
insert <test:subj> <test:pred> $x $x <test:value> 'o1'
into <rmi://localhost/server1#test> ;
insert <test:subj> <test:pred> $x $x <test:value> 'o2'
into <rmi://localhost/server1#test> ;
select $s $p $o from <rmi://localhost/server1#test> where $s $p $o;
</pre><br />Then I see that the variable "x" is bound to different blank nodes in <br />each of the two insertions, and the resulting model has 4 statements. <br />This is the behavior (behaviour?) that I would expect.</p>
<p>However, when I turn autocommit off prior to the first insertion, and <br />turn it back on after the second insertion, then I see that the variable <br />"x" is bound to the <strong>same</strong> blank node in each of the insertions, <br />resulting in 3 total statements in the model, which came as a bit of a <br />surprise to me. Is this the expected behavior in that situation?</p> Mulgara - Bug #56 (Feedback): Distributed blank nodes not uniquely identifiedhttps://code.mulgara.org/issues/562007-04-15T05:55:17ZPaula Gearon
<pre>
<code class="html syntaxhl">Any blank nodes returned from a distributed resolver may contain the same gnode IDs as local blank nodes. This means they cannot be distinguished. Add a factory in the appropriate place to mark blank nodes from elsewhere with the IP of their source.
</code></pre> Mulgara - Bug #53 (New): FileSystemResolver keeps exhausting heaphttps://code.mulgara.org/issues/532007-03-20T03:51:53ZAndrae Muys -andrae@netymon.com
<pre>
<code class="html syntaxhl">Regularly seeing heap exhaustion when running the [[FileSystemResolver]] unit test.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
I believe this resolver is memory bound and needs to be modified to use disk-backed structures.
</code></pre> Mulgara - Bug #52 (New): Insufficient dereferencing in TransactionalAnswer.sessionClose leading t...https://code.mulgara.org/issues/522007-03-19T07:03:14ZAndrae Muys -andrae@netymon.com
<pre>
<code class="html syntaxhl">There is a need for the normal error-path to properly dereference and cleanup transactions so that exceptional failures within the error-path can be logged without being lost in 'noise'.
</code></pre>