[jira] [Issue Comment Edited] (JENA-226) New Client API

["Andy Seaborne (Issue Comment Edited) (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/JENA-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13236538#comment-13236538 ] 

Andy Seaborne edited comment on JENA-226 at 3/23/12 1:25 PM:
-------------------------------------------------------------

This looks good and is good timing.

The SPARQL features support has grown organically as new SPARQL features have become available.  Pulling these together into  coherent client-facing API would be very useful.  There's bits in Fuseki (e.g. DatasetAccessor) as well which have not had time to migrate to the right place.  As SPARQL access has evolved, the Dataset interface has become the object around which the various API use.  The query execution factory or update execution factory uses the kind of Dataset to route to the right code. 
This abstraction isn't complete (no concept of "create Dataset").

Keeping the new API as a separate module for better release cycles than core ARQ seems to me to be the way forward.  We can then deliver in various forms. When we repackage under the org.apache.jena root, we have a chance to make API chanages and one thing to consider is having less of a separation of SPARQL and the Jena core API.  Maybe move Dataset, DatasetGraph, Quad into just two packages (API, SPI).

I don't have answers to your questions at [1], just some thoughts:

On "Should the API be based Graph/Triple or Model/Statement objects?", I'd design the API to be related to Model/Statement but keeping an eye open to the graph level.  We could make Graph/Triple/... more of an official API after a bit of clearing up like better naming, and refactoring out unused stuff.

On "GSP and quads", I'm inclined just do the REST-thing GET/PUT/POST at the quads level.  

Final comment - "small steps".  A partial API and implementation that covers the natural core of this, and made available labelled "experimental - for feedback" (another argument to me for being separate for now).  Howabout the pure SPARQL bit for now?

Sort of related, but not enough to link the JIRA to them, are JENA-189 (Jena3 technical) and JENA-190 (Jena delivery); JENA-189 because of getting streaming to work end-to-end and misc consolidation of the Graph API and JENA-190 because we can put this API bundled with other code in a  single "development jar" to make it eaiser to use Jena.


                
      was (Author: andy.seaborne):
    This looks good and is good timing.

The SPARQL features support has grown organically as new SPARQL features have become available.  Pulling these together into  coherent client-facing API would be very useful.  There's bits in Fuseki (e.g. DatasetAccessor) as well which have not had time to migrate to the right place.  In fact, keeping this new API as a separate module for better release cycles than core ARQ seems to me to be the way forward.  We can then deliver in various forms.

When we repackage under the org.apache.jena root, we have a chance to make API chanages and one thing to consider is having less of a separation of SPARQL and the Jena core API.  Maybe move Dataset, DatasetGraph, Quad into just two packages (API, SPI).

I don't have answers to your questions at [1], just some thoughts:

On "Should the API be based Graph/Triple or Model/Statement objects?", I'd design the API to be related to Model/Statement but keeping an eye open to the graph level.  We could make Graph/Triple/... more of an official API after a bit of clearing up like better naming, and refactoring out unused stuff.

On "GSP and quads", I'm inclined just do the REST-thing GET/PUT/POST at the quads level.  

Final comment - "small steps".  A partial API and implementation that covers the natural core of this, and made available labelled "experimental - for feedback" (another argument to me for being separate for now).  Howabout the pure SPARQL bit for now?

Sort of related, but not enough to link the JIRA to them, are JENA-189 (Jena3 technical) and JENA-190 (Jena delivery); JENA-189 because of getting streaming to work end-to-end and misc consolidation of the Graph API and JENA-190 because we can put this API bundled with other code in a  single "development jar" to make it eaiser to use Jena.


                  
> New Client API
> --------------
>
>                 Key: JENA-226
>                 URL: https://issues.apache.org/jira/browse/JENA-226
>             Project: Apache Jena
>          Issue Type: New Feature
>            Reporter: Stephen Allen
>            Assignee: Stephen Allen
>            Priority: Minor
>
> Develop a new API geared towards bridging the gap between local Jena databases and remote SPARQL HTTP endpoints.  This would provide a single object to represent a repository, and provide functions to perform querying and modification of the data in the repository.  These functions would attempt to be as efficient as possible (i.e. streaming modifications to remote servers), while also promoting safe practices such as parameterizing user supplied query inputs to prevent SPARQL-injection attacks.
> I've started writing up some use cases at [1] (would like to move over to the Confluence Wiki shortly).  And I've also started a branch [2] (not much there yet).  Feedback is greatly appreciated.
> [1] http://people.apache.org/~sallen/jena/ClientUseCases.html
> [2] http://svn.apache.org/repos/asf/incubator/jena/Jena2/ARQ/branches/ArqClient

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira