Mulgara Project: Issueshttps://code.mulgara.org/https://code.mulgara.org/favicon.ico?15861924492009-09-06T14:49:10ZMulgara Project
Redmine 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 #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 #181 (New): Need Authorization for HTTPhttps://code.mulgara.org/issues/1812009-02-04T05:32:53ZPaula Gearon
<p>Now that Mulgara can be put on the web, the write operations need to be locked down, else it cannot be deployed. For HTTP we will need to employ authorization through standard means.</p>
<p>Several questions come out of this. First, how should authorization be handled? In the database? In an external file? Second, should it be done on an operation basis (GET is safe, but PUT/POST is not) or on a graph-by-graph basis like Mulgara security used to employ?</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 - Feature #175 (New): Resolver interface needs to provide back-up/restore capabilityhttps://code.mulgara.org/issues/1752008-12-04T22:25:53Zamit -amit@foo.bar
<p>To provide a simple administrative routine, it would help if the resolver interface supported backup and restore capabilities.</p>
<p>This will allow resolvers to also dump their data into a backup, and have restore data brought back in. This will only be applicable to writable resolvers.</p>
<p>Resolvers may also need to mark a new section of the backup file, which will be ignored by other resolvers. This will result in new code that asks each resolver if it <em>can</em> do backups, and during restore it will need to iterate over each resolver to find out with one can handle the data about to be restored (according to a section marker in the backup file)</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 #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 #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 #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 #83 (Feedback): Mulgara fails to start after abrupt terminationhttps://code.mulgara.org/issues/832008-03-07T06:07:03Zronald -ronald@foo.bar
<p>I killed mulgara abruptly, and subsequently it failed to start.<br />According to Andrae's initial analysis, the problem is that mulgara<br />assumes during recovery that certain deleted structures are internally<br />valid when in this case they aren't.</p>
<p>Attached is the db from after the crash. The failure to recover seems to<br />be reproducable only on 32-bit jvm's, and even then not consistently<br />(due to the timing between certain operations).</p> Mulgara - Bug #82 (In Progress): Read-close-write creates redundant phasehttps://code.mulgara.org/issues/822008-03-05T21:13:22ZPaula Gearon
<p>When reading and closing an Answer in a write transaction, a redundant micro-commit occurs. This leads to unbounded growth when regularly reading in large transactions.</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>