Mulgara Project: Issueshttps://code.mulgara.org/https://code.mulgara.org/favicon.ico?15861924492009-09-06T14:39:02ZMulgara Project
Redmine 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 - Feature #185 (New): Create HTTP testshttps://code.mulgara.org/issues/1852009-02-25T18:45:19ZPaula Gearon
<p>We need a framework for HTTP tests. This can be modeled on the JXUnit tests.</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 #172 (New): Add Talis changeset files as an uploadable file type on the SPARQL/...https://code.mulgara.org/issues/1722008-11-21T00:51:00ZPaula Gearon
<p>HTTP updates currently only allow a single TQL command.</p>
<p>SPARQL update will address some of this, but a more flexible approach will be to support Talis changeset files. Note that these files only permit modification on a single subject at a time, though they can include both inserts and deletes in the same file.</p>
<p><a class="external" href="http://vocab.org/changeset/schema">http://vocab.org/changeset/schema</a></p> Mulgara - Feature #168 (New): Add collection support to RLog AND ruleshttps://code.mulgara.org/issues/1682008-11-10T17:37:38ZPaula Gearon
<p>RLog needs a collection syntax, which needs to be converted to the appropriate "walk" constraints in the rules engine.</p>
<p>For instance, see rule S35 in <a href="http://mulgara.org/trac/attachment/wiki/SKOS/skos.rlog" class="external">skos.rlog</a>:</p>
<pre></pre> 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 - Feature #147 (New): Configurationhttps://code.mulgara.org/issues/1472008-09-08T18:15:06ZPaula Gearon
<p>Create a registry object for EmbeddedMulgaraServer to set pass out to any services that it starts up.</p>
<p>I was initially tempted to go with a dictionary, but I prefer the idea of keeping a tighter control on the information passed around. We can always expand what's held in the registry, but it will be centralized, rather than having services work on an ad hoc basis.</p>
<p>The reason this needs to be a registry and not a set of parameters is because objects may need to be passed to services after they have been created. The canonical example here is where the framework creates a SessionFactoryFactory, along with the web servlets, but until the startup phase there is no instance of Database - which is what the web servlets need. For the moment, each service is holding a handle to EmbeddedMulgaraServer and queries that object directly, but the internals of this class need to be kept away from all the objects it creates.</p> Mulgara - Feature #116 (New): All answers are DISTINCThttps://code.mulgara.org/issues/1162008-05-17T23:01:21ZPaula Gearon
<p>Answers never have duplicates. SPARQL requires that duplicates remain unless removed with DISTINCT.</p>
<p>This will need changes to the Resolver API, and so are being delayed for a later release.</p> Mulgara - Feature #109 (New): Constraint merginghttps://code.mulgara.org/issues/1092008-05-17T22:12:34ZPaula Gearon
<p>Constraints in Krule can all be separate objects, despite having the same resolution patterns. The differences come about because of variable names. For instance, the following two constraints have the same resolution pattern:<br /> ($x <rdf:type> $y)</p>
<pre><code>($a &lt;rdf:type&gt; $b)<br />The variable names cannot be changed, as the distinct names may be needed within each rule. However, the resolutions to these constraints are identical.</code></pre>
<p>Krule needs to:</p>
<p>a. Identify constraints that use the same pattern (see how rlog does this).</p>
<p>b. Map each constraint to a (shared) resolution that matches it.</p>
<p>c. Allow resolutions to be marked as stale by triggering events (see ticket 108).</p>
<p>d. When a constraint needs to use it's resolution in the resolution of the entire rule, then don't let the query engine get the resolution. Instead, provide the common resolution after mapping its variable names to the required names. This may need some internal operations in the query engine.</p> Mulgara - Feature #86 (In Progress): Clean up XSD Resolver so it becomes suitable demo-resolverhttps://code.mulgara.org/issues/862008-03-17T01:36:49ZAndrae Muys -andrae@netymon.com
<p>The XSD-Resolver is currently in a very poor state of repair. The Resolver Interface also desperately requires detailed documentation, and this really requires an exemplar resolver.</p>
<p>Clean up the XSD-Resolver so that it can be used as an example of how to write a resolver.</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 - Feature #71 (New): Clean up DatabaseOperationContexthttps://code.mulgara.org/issues/712007-09-13T08:57:10ZAndrae Muys -andrae@netymon.com
<pre>
<code class="html syntaxhl">This is the next cleanup refactoring.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
We have:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
[[ResolverFactory]] findModelResolverFactory(long model)
<span class="nt"><br/></span>
[[ResolverFactory]] findUncachedExternalResolverFactory(long model)
<span class="nt"><br/></span>
[[ResolverFactory]] findModelTypeResolverFactory(URI modelTypeURI)
<span class="nt"><br/></span>
Resolver obtainResolver(ResolverFactory resolverFactory)
<span class="nt"><br/></span>
URI mapToModelTypeURI(URI modelURL)
<span class="nt"><br/></span>
URI findModelTypeURI(long model)
<span class="nt"><br/></span>
String findProtocol(long n)
<span class="nt"><br/></span>
<span class="nt"><br/></span>
most of which do multiple overlapping tasks, often implemented slightly differently.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Most of these methods used to live in different classes, and have migrated here as their homes were refactored and tidied.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
[[DatabaseOperationContext]] and [[LocalQueryResolver]] are the last two dumping grounds in the system-core where we have left the cruft that was too difficult to clean up concurrently with previous refactorings; and [[DatabaseOperationContext]] is by far the worst of the two - so it's next on the list.
</code></pre> Mulgara - Feature #49 (New): Create a SOAP endpoint on the serverhttps://code.mulgara.org/issues/492007-03-01T03:56:01ZPaula Gearon
<pre>
<code class="html syntaxhl">Currently, the most common way for non-Java clients to connect to Mulgara is via SOAP. This is done by wrapping the itql.jar in a SOAP endpoint, and calling that. This gives a topology of:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Client <span class="ni">&lt;</span>---[SOAP]---<span class="ni">&gt;</span> Itql.jar <span class="ni">&lt;</span>---[RMI]---<span class="ni">&gt;</span> Mulgara
<span class="nt"><br/></span>
<span class="nt"><br/></span>
This double-network hop is horrible and inefficient. It also has an unfortunate dependence on RMI.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Until we have a good HTTP solution (via [[NetKernel]]) it would be far preferable to allow the following:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Client <span class="ni">&lt;</span>---[SOAP]---<span class="ni">&gt;</span> Mulgara
<span class="nt"><br/></span>
<span class="nt"><br/></span>
This should not be too hard. The main thing that the server needs is a means of converting iTQL queries from the client into Query objects used by the session. Code already exists in [[ItqlInterpreter]] to do this, but it will to be decoupled from remote session creation (since it will now be done locally, and no finding of remote resources is necessary).
<span class="nt"><br/></span>
<span class="nt"><br/></span>
The other thing to do is:
<span class="nt"><br/></span>
- Provide SOAP access to the Answer object. This will help get it running, but is not suitable for real work (since SOAP calls would be needed to read every element of every line).
<span class="nt"><br/></span>
- Convert small Answers into a DOM for returning.
<span class="nt"><br/></span>
- Configure a streaming XML result set suitable to be parsed via SAX. Hopefully this can be done?
</code></pre> Mulgara - Feature #16 (In Progress): Add Rules for OWL DL/Full supporthttps://code.mulgara.org/issues/162006-09-14T04:28:54ZAndrae Muys -andrae@netymon.com
<pre>
<code class="html syntaxhl">Extend the new Rules Engine to support OWL Full.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Provide rule sets for OWL DL and OWL Full.
</code></pre>