Mulgara Project: Issueshttps://code.mulgara.org/https://code.mulgara.org/favicon.ico?15861924492009-09-01T20:02:05ZMulgara Project
Redmine Mulgara - Feature #198 (New): SPARQL XML results encodinghttps://code.mulgara.org/issues/1982009-09-01T20:02:05ZGregg -gar@foo.bar
<p>Currently the XML response to SPARQL queries does not specify an encoding in the XML header. The SPARQL Protocol definition doesn't seem to address this, and the examples omit it; but the SOAP example includes it. As a matter of "best practice" I think Mulgara should always explicitly indicate the encoding.</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 - Feature #184 (New): Refactor Protocol Servlethttps://code.mulgara.org/issues/1842009-02-25T18:44:25ZPaula Gearon
<p>The protocol servlet is getting too many methods, and still needs to expand.</p>
<p>The proposed refactoring is to create classes based on the <em>resource type</em> of the request. Each class then manages operations on the type that it manages.</p>
<p>Resource types are identified by parameters in the request. Care must be taken with POST requests, as parameters may arrive in the content, and not the URL.</p>
<ul>
<li>Graphs. These are identified by the inclusion of a <strong>default-graph-uri</strong> parameter, and none of the other parameters that identify other types. A synonym for this parameter is <strong>graph</strong>.</li>
<li>Statements. These are identified by the inclusion of <strong>subject</strong>, <strong>predicate</strong>, <strong>object</strong>, and <strong>graph</strong> (or <strong>default-graph-uri</strong>) parameters. Synonyms include: <strong>subj</strong>/*s*, <strong>pred</strong>/*p* and <strong>obj</strong>/*o*. If only some of these are present, or duplicates occur, then this is an error.</li>
<li>Queries. These are not "resources", but are defined by the SPARQL spec.</li>
</ul>
The operations for these objects are:
<ul>
<li>Graph:
<ul>
<li>GET: Issue a CONSTRUCT for the entire graph. <em>TODO</em>.</li>
<li>PUT: Create a graph. <em>TODO: return 201</em></li>
<li>DELETE: Delete a graph.</li>
<li>POST: Load a file into a graph.</li>
<li>HEAD: Return the graph type, if known.</li>
</ul>
</li>
<li>Statement:
<ul>
<li>GET: An OK response if the statement exists. Otherwise return 404. <em>TODO</em>.</li>
<li>PUT: Create the statement. <em>TODO: return 201</em></li>
<li>DELETE: Remove the statement.</li>
<li>POST: Take an ID parameter and use this as a URI to reify the statement. <em>TODO.</em></li>
<li>HEAD: Get the Reification ID for the statement. <em>TODO.</em></li>
</ul>
</li>
<li>Query:
<ul>
<li>GET: Perform a read-only query.</li>
<li>PUT: N/A (should this do an insert/select for <strong>construct</strong> queries?)</li>
<li>DELETE: N/A (should this do an delete/select for <strong>construct</strong> queries?)</li>
<li>POST: Allows writable commands (TQL only. Possibly SPARQL Update.)</li>
<li>HEAD: Get the size of the result of a read-only query. <em>TODO</em>.</li>
</ul></li>
</ul> Mulgara - Feature #178 (New): Queries with limits should be annotated as suchhttps://code.mulgara.org/issues/1782009-01-28T19:18:32ZPaula Gearon
<p>Some queries should have the limits applied while being processed via the FILTER operator. This is hard to apply in the general case, but if processing is being done at the level of the top conjunction or disjunction, then the limit can be applied to avoid latter processing.</p>
<p>An example is shown here in SPARQL:<br /><pre>
This requires processing of every line before returning the first one.</p></pre> 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 - 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 #171 (New): Default graph option to movehttps://code.mulgara.org/issues/1712008-11-18T20:40:25ZPaula Gearon
<p>Currently the SPARQL interpreter handles default graphs by setting the graph on any queries it parses.</p>
<p>A mechanism that will fit in better with the SPARQL protocol will be to allow the graph to be set to null, and for the Connection to set the graph. This will require all Connection implementations to accept a default graph setting, and to set this on any queries that require it as they are passed along the connection.</p> Mulgara - Feature #170 (New): Default graph for TQLhttps://code.mulgara.org/issues/1702008-11-18T20:37:28ZPaula Gearon
<p>The SPARQL parser has a method to set the default graph on all queries. We would like the same to be enabled for TQL.</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 #57 (New): Extend use of Annotations to improve transparency of deferral based ...https://code.mulgara.org/issues/572007-04-17T05:51:27ZAndrae Muys -andrae@netymon.com
<pre>
<code class="html syntaxhl">[[ReresolvableResolution]] needs to be removed and replaced with an Annotation.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
All Major Tuples that provide operations on Tuples need to be modified to provide aggregated access to their operands annotations when their operands provide them.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
As a longer term goal we should rephrase the annotations in terms of complexity estimates for reordering/sorting/etc operations as well as constraints on join ordering to permit more nuanced optimisation of joins - this however needs to wait until we are fully exploiting the capabilities of the existing annotations.
</code></pre> Mulgara - Feature #27 (New): Eliminate all use of static variables from Mulgarahttps://code.mulgara.org/issues/272006-10-16T07:13:57ZAndrae Muys -andrae@netymon.com
<pre>
<code class="html syntaxhl">The use of static (ie. global) variables prevents Mulgara being restarted within a jvm. These are not necessary, and are being used to avoid considering where objects belong within the system.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Note this does not apply to static *constants* - being compile-time immutable values they are not an issue.
</code></pre> Mulgara - Feature #23 (New): We must find a more descriptive way of expressing the cost of iterat...https://code.mulgara.org/issues/232006-09-26T11:08:34ZAndrae Muys -andrae@netymon.com
<pre>
<code class="html syntaxhl">An increasing number of resolvers (relational, federating, distributed) cannot provide a meaningful upper-bound to their row-count.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Also row-count assumes a uniform cost of iteration, when iteration (as opposed to resolution) entails network latency this is unrealistic.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
How do we handle this? Do we need some sort of bogomips-like timing constant to provide a baseline for comparison? Can we use this to also provide selectivity data that would also improve our join performance?
</code></pre> Mulgara - Feature #22 (New): Make from clause optionalhttps://code.mulgara.org/issues/222006-09-26T04:13:24ZAndrae Muys -andrae@netymon.com
<pre>
<code class="html syntaxhl">Consider the following query:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
select $type
<span class="nt"><br/></span>
(select $s from <span class="ni">&lt;</span>server<span class="ni">&gt;</span> where $s <span class="ni">&lt;</span>rdf:type<span class="ni">&gt;</span> $type and $s <span class="ni">&lt;</span>p<span class="ni">&gt;</span> <span class="ni">&lt;</span>o<span class="ni">&gt;</span>)
<span class="nt"><br/></span>
from <span class="ni">&lt;</span>server<span class="ni">&gt;</span>
<span class="nt"><br/></span>
where $type <span class="ni">&lt;</span>mulgara:is<span class="ni">&gt;</span> <span class="ni">&lt;</span>test:Class<span class="ni">&gt;</span> ;
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Mandating from clauses is regularly redundant, and clutters the query.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
While from is the most common example, I have come across examples for every component of a itql query where they are redundant. Apart from mandating the keyword 'select', to identify it as a query, we should probably make the rest of the query should be optional.
<span class="nt"><br/></span>
</code></pre> Mulgara - Feature #21 (New): HybridTuples should defer sort and support prefix-define/reresolvehttps://code.mulgara.org/issues/212006-09-26T03:51:34ZAndrae Muys -andrae@netymon.com
<pre>
<code class="html syntaxhl">Currently [[HybridTuples]] performs it's sort when it is constructed. This forces the evaluation of its argument before join-optimisation has an opportunity to specify a desired prefix or reresolve. [[HybridTuples]] should defer it's sort until at least the first call to beforeFirst.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Considerations:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Reresolve - If [[HybridTuples]] argument is Reresolvable [[HybridTuples]] should support passing this argument through.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
[[DefinablePrefix]] - If our argument is unordered then a projection is free, so we should expose this to the join optimisation. However note that if we are only sorting once, then we cannot pass this call through to the argument. Rather we should project the argument to maximise the prefix length available.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Single vs. Multiple sorts - A sort is O(nlogn), and a n from m prefix is O((0 from m)^((n - m) / m)). If we can increase the prefix length sufficiently to pay for the cost of the extra sorts we should resort on each call to beforeFirst(). Note that if the argument is itself prefix-definable then the cost of a sort is in terms of the estimated reduced length.
</code></pre> Mulgara - Feature #18 (New): Provide a language independent interface to Mulgara compatible with ...https://code.mulgara.org/issues/182006-09-14T04:38:41ZAndrae Muys -andrae@netymon.com
<pre>
<code class="html syntaxhl">We need to support access to the entire Session API from languages other than java.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Both xml-rpc and REST have been proposed as alternatives. OTOH we should probably support both.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
XMLRPC because of it's wide language support and classic-rpc model.
<span class="nt"><br/></span>
REST because it is a better fit to W3C architecture, and provides benefits when working with loosely coupled distribution.
</code></pre>