[sparql-wrapper-devel] Fwd: [Jena-devel] SPARQL/Update http post parameter

[Zach D. <zd...@gm...>]

The response from the Joseki team.

---------- Forwarded message ----------
From: Seaborne, Andy <and...@hp...>
Date: Mar 6, 2009 9:14 AM
Subject: Re: [Jena-devel] [sparql-wrapper-devel] SPARQL/Update http post
parameter
To: Sergio Fernández <ser...@fu...>, "
spa...@li..." <
spa...@li...>, Ivan Herman <iv...@w3...>
Cc: "jen...@li..." <jen...@li...>

Zach - many thanks for the patch.  If there are no side-effects to existing
installations, I'll probably incorporate it. I happen to think split
update/query is better as discussed below.


> -----Original Message-----
> From: Sergio Fernández [mailto:ser...@fu...]
> Sent: 06 March 2009 08:36
> To: spa...@li...
> Cc: jen...@li...
> Subject: Re: [Jena-devel] [sparql-wrapper-devel] SPARQL/Update http post
> parameter
>
> On Thu, 2009-03-05 at 23:21 -0600, Zach Dwiel wrote:
> > I'm trying to use the python-sparqlwrapper library to run
> > SPARQL/Update operations.  In the sparql-wrapper code, the update
> > query is bound to the 'query' parameter in the HTML post. In Joseki's
> > implementation, the query is expected to be bound to the parameter
> > 'request'.
>
> AFAIK, SPARUL [1] is just an extension for SPARQL Query Language [2].
> The name of that HTTP parameter is defined by other specification, the
> SPARQL protocol [3].


Not quite true I'm afraid - it might so that way.  It's a separate language
with it's own characteristics reusing the syntax of SPARQL.  It may end up
merged in to SPARQL, it may end up as separate language along side the query
language.  In ARQ, it's one parser but separate entry points.

Using "request=" is a device to distinguish request to the same endpoint
although I recommend not having the query and update on the same URL but
treat them as separate services over the same datastore.  As two endpoints,
the security mechanaism of whatever web container is being used can be
applied to incoming HTPP requests.  At least with parameter names, the
service can switch before having to parse (Example1: a large update from a
know source is reasonable but might want to limit the incoming size of
general queries. Example2: a machine that does not request the query but
forwards it as a gateway to a backend system)

The protocol design was in early versions of SPARQL/Update but there was
more debate in that area - there were good points about how best to do this
in web architecture - so we focused on the language part which is useful in
its own right.

My hope is that the newly started working group will quickly establish which
direction to go in.

        Andy

(I'm not on spa...@li... - could someone
please forward this message?  Thanks).


>
> > Otherwise, maybe something could be changed on the sparql-wrapper side
> > to make this possible.  Previously, I have dealt with this by changing
> > the library to make the query parameter changable ... What do you
> > think?
>
> While the wrapper uses the mandatory name, I don't want to patch that
> side. But I think it would be nice to propose your patch to Joseki guys,
> in order to align it with other implementations.
>
> Cheers,
>
> [1] http://www.w3.org/Submission/2008/SUBM-SPARQL-Update-20080715/
> [2] http://www.w3.org/TR/rdf-sparql-query/
> [3] http://www.w3.org/TR/rdf-sparql-protocol/
>
> --
> Sergio Fernández - ser...@fu...
> R&D Deparment
> CTIC Foundation - www.fundacionctic.org
> Phone: +34 984 29 12 12
> Fax:  +34 984 39 06 12
> Edificio Centros Tecnológicos
> Parque Científico Tecnológico
> 33203 Cabueñes - Gijón - Asturias - Spain
>
>
>
----------------------------------------------------------------------------
> --
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco,
CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the
Enterprise
> -Strategies to boost innovation and cut costs with open source
participation
> -Receive a $600 discount off the registration fee with the source code:
SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________

> Jena-devel mailing list
> Jen...@li...
> https://lists.sourceforge.net/lists/listinfo/jena-devel

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________

Jena-devel mailing list
Jen...@li...
https://lists.sourceforge.net/lists/listinfo/jena-devel