[Sparql4j-devel] Result handling - URGENT

[Samppa S. <sam...@pr...>]

Problem: How to provide both row and InputStream based access to all 
types of query results.

Row based access fits better to jdbc semantics and should thus be 
emphasized. However InputStream based access is usefull for example for 
XSLT post processing and for using external RDF parser to process 
CONSTRUCT and DESCRIBE results.

Constraints:

1) Branching should be clear and consistent regardless of the type of 
the query, e.g. not dependent execution order, independent of query type 
(for ad hoc query processing)

2) JDBC semantics should not be rewritten. Future support for 
PreparedStatements, updates and stored procedures should not be blocked.

3) User should be in control of accept -preferences, i.e. whether n3 or 
rdf/xml is preferred for RDF-based results.

4) User should be able to access the content type of the results (when 
using InputStream access) as it is ultimately the server which decides 
the type of result (accept's are only preferences and may include both 
n3 and rdf/xml).


We suggest that triple-per-row should be used as the basic approach for 
DESCRIBE and CONSTRUCT (i.e. RDF form) results, with subject, predicate 
and object as the basic columns (exposed via ResultSetMetaData in 
addition to pseudo-columns for subject and object type as well as 
literal-object's additional properties).

Here are a couple of alternatives for InputStream based access to results.

/* Target method for input stream processing */
public void processStream(InputStream stream, String contentType) {...}


1) SparqlStatement

public interface SparqlStatement extends Statement {
    ...
    public ResultStream executeSparql(String query, String[] accept) {...}
    ...
}

public class ResultStream extends InputStream {
    public String getContentType() {...}
    public String getEncoding() {...}
}

Usage:

SparqlStatement stmt = (SparqlStatement) connection.createStatement();
ResultStream stream = stmt.executeSparql("CONSTRUCT ...", new 
String[]{"text/rdf+n3"});
String contentType = stream.getContentType();
processStream(stream, contentType);

Pros/cons:

+ Provides SPARQL specific extension to JDBC while preserving JDBC semantics
+ Clear way of providing accept preferences per query
+ Direct InputStream access independent of ResultSet and clob/blob access
- Needs explicit casting
- Is dependent on sparql4j API (for the SparqlStatement and ResultStream 
interfaces)


2) Specifying result set type when creating statement

Statement stmt = connection.createStatement(SparqlResultSet.TYPE_STREAM, 
ResultSet.CONCUR_READ_ONLY);
ResultSet rs = stmt.execute("CONSTRUCT ...");
if (rs.hasNext()) {
    Blob blob = rs.getBlob(1);
    String contentType = rs.getString(2);
    processStream(blob.getBinaryStream(), contentType);
}

Pros/cons:

+ Doesn't need explicit casting
+ No dependency on Sparql4J API except for the special result set type 
constant
- Requires buffering of the whole result (length of the result might not 
be available and there's no limitations on how many times 
getBinaryStream can be called).
- Clob/blob is under spceficied (e.g. relation to transactions) and 
implementations/usage are vendor specific.

Br,
  Samppa & Timo

-- 
Samppa Saarela <samppa.saarela at profium.com> Profium, Lars Sonckin kaari 12, 02600 Espoo, Finland Tel. +358 (0)9 855 98 000 Fax. +358 (0)9 855 98 002 Mob. +358 (0)41 515 1412  Internet: http://www.profium.com