On 18/08/15 12:10, james anderson wrote:
good afternoon;
On 2015-08-18, at 12:35, Andy Seaborne <[email protected]
<mailto:[email protected]>> wrote:
[…]
That is the definition of PUT for HTTP always. See quote from the RFC.
"created or replaced", the old content is lost. There is nothing
special about SPARQL, RDF or linked data here.
That's why the graph store protocol is needed for adding naming to
direct operations to specific graphs in a store
In HTTP if any app does GET after PUT, then the returned resource (up
to conneg and concurrency) is the thing that was PUT and only that.
POST is the additive operation.
[…]
while i do find the notion quite appealing, that the url query arguments
determine the effective protocol independent of endpoint, i would never
have dared to suggest it.
if there was any commentary during the ratification process, it would be
useful to be able to refer parties to it, when they ask.
The protocol is HTTP and it's verbs. OK - POST is often used in weird
and wonderful ways but the spec does define "append to database" as one
blessed usage. It is what HTTP has always said.
The other essential point is that different URLs name a different
resource. A query string makes it a different URL. We/people think of
arguments to an endpoint but HTTP does not actually say that.
In HTTP,
http://host/form.html&name=foo
and
http://host/form.html
are different (web, http) resources.
So in GSP,
http://host/dataset?default
http://host/dataset?graph=...
are all different (web, http) resources
and different to http://host/dataset
so that's why
http://host/dataset?query=....
returning a result set is not a representation of the dataset.
Andy
Cross posting and setting the reply to [email protected] will confuse things!
Dydra has documented some HTTP logic here - are we talking about the
same thing?
https://github.com/dydra/sparql-tests/blob/master/suites/http-api/README.md#triples-quads-and-named-graph-in-import-requests
Some of the descriptions looks a bit dodgy. "add" is used in PUT
descriptions - could be a typo.
the intent is to distinguish the “clear” from the “add” aspects as the
former may have its own consequences.
if that was omitted somewhere, please advise.
best regards, from berlin,
Specifically, which tests are your referring to in that long list?
Some are GSP related, some acting on the repository.
On Tue, Aug 18, 2015 at 8:57 AM, Andy Seaborne <[email protected]
<mailto:[email protected]>> wrote:
On 17/08/15 22:40, Martynas Jusevičius wrote:
So what are the semantics of POSTing quads and PUTing quads?
Append and replace as per HTTP.
RFC 7231: 4.3.3. POST
...
- Extending a database through an append operation.
...
(any ordering implied by "extend" is irrelevant for a set of quads)
RFC 7231: 4.3.4. PUT
The PUT method requests that the state of the target resource be
created or replaced with the state defined by the representation
enclosed in the request message payload.
On Mon, Aug 17, 2015 at 11:32 PM, Andy Seaborne <[email protected]
<mailto:[email protected]>> wrote:
On 17/08/15 22:21, Martynas Jusevičius wrote:
Is that an oversight in the GSP spec?
Not really - the GET/POST/PUT on the dataset itself is just normal
use of
HTTP.
The "Graph Store Protocol" for managing a graph store. What it really
adds
is the naming convention, ?default and ?graph.
Andy
I had done something similar (which I use as a low-level API):
https://github.com/Graphity/graphity-core/blob/master/src/main/java/org/graphity/core/util/DataManager.java
On Mon, Aug 17, 2015 at 10:16 PM, Andy Seaborne <[email protected]>
wrote:
On 17/08/15 20:26, Martynas Jusevičius wrote:
Andy,
I have a related question. What if I have a Dataset at hand, not a
Model - how do I send it to a remote Graph Store?
The SPARQL Graph Store Protocol does not mention this. Fuseki
supports
REST-ish PUT/POST/GET on the dataset URL.
Currently, you need to send it yourself -- HttpOp.execHttpPost
has lots
for
support for that e.g. see DatasetGraphAccessorHTTP for sending a
model
-
generalise to datasets.
We have been talking about this on dev@
http://mail-archives.apache.org/mod_mbox/jena-dev/201508.mbox/%3C55BE6A0B.5020404%40apache.org%3E
where we're talking about bring the remote (and local) interaction
together
and whetre I'm suggesting adding the plain-old HTTP ops on teh
dataset
URL.
Andy
Martynas
On Mon, Aug 17, 2015 at 9:19 PM, Andy Seaborne <[email protected]>
wrote:
DatasetAccessor
This is the API to the SPARQL Graph Store Protocol.
Model model = ...
DatasetAccessor acc = DatasetAccessorFactory.createHTTP
("http://.../datasets/data";) ;
acc.add(model) ; // adds to existign data, if any.
or
acc.putModel(model) -- which overwrites existing data
On 17/08/15 20:11, [email protected] wrote:
There may be a better answer for this, but at the very least, you
can
serialize your triples/quads and use SPARQL Update to send
them to
your
Fuseki instance.
---
A. Soroka
The University of Virginia Library
On Aug 17, 2015, at 3:08 PM, Andy Doddington
<[email protected]>
wrote:
On 17 Aug 2015, at 19:50, Andy Doddington
<[email protected]> wrote:
Hoping the subject makes my query clear - since I am a total
newbie
in
this area.
I have created a tiny model, using
ModelFactory.createDefaultModel()
to
create my initially empty model,
which I then populate manually.
So, having done this, is there any way that I can persist
this to a
Fuseki database running on a remote server?
Thanks for any help,
Andy D
---
james anderson | [email protected] <mailto:[email protected]> | http://dydra.com
