Re: SILENT tests (ACTION-517)

Hi Andy,

thanks for this... I had thought a bit (at least partially) about these different options and decided to just give it a shot and publishing the test cases with my reading to the group. My understanding was driven by the current wording in section 4.1.2 of the update doc:

 "By 'atomic operation' we mean that the operation performs the described transformation of the Graph Store either completely or leaves the Graph Store unchanged, i.e., the result is either GS' or GS (in case of error)."

Anyways, your use case raises a good point... what I read from it is that - if we want these different behaviors being allowed after LOAD, we should reflect that in the spec by noting after *which* failures the status of the graph store is undefined by the spec for the SILENT case. I will try to summarise these in the following...

By scanning the update doc for "failure" and "error" I see:

 1)     (implicit) creation of an unallowed graph:

Section 3.1, similarly in section 3.1.1, and 3.1.3, also in 3.1.4
    "there may be implementations providing an update service over a fixed set of graphs which in such case must return with failure for update requests that would create an unallowed graph"

 failed creation of an unallowed graph (for graph stores that operate over a fixed set of graphs) ... I would assume that such failures should result in the graph store remaining as it was before the request (SILENT or not). So, I think we should add here:

 "there may be implementations providing an update service over a fixed set of graphs which in such case must return with failure for update requests that would create an unallowed graph and the graph store is expected to remain in the same status as prior to the request."

 2) Section 3.1.4 (LOAD)
"In case no RDF data can be retrieved (as opposed to the empty graph being retrieved) from the IRI denoted by IRIref_from, or in case the retrieval method returns an error (such as, for instance an HTTP error code), the SPARQL 1.1 Update service is expected to return failure. If SILENT is present, the result of the operation will always be success. In case the graph named by the IRI denoted by IRIref_to does not exist in the graph store, and the retrieved graph is non-empty, it will be created; an empty graph being retrieved will not create a new graph in the graph store."

This is where your comment hooked in... the last sentence ("an empty graph being retrieved will not create a new graph in the graph store") is a bit problematic, though, since it somewhat precludes the  behaviour you suggest:

> In the SILENT case, I thinks it's reasonable for the named graph to be
> created in each case for uniformity.  Stores are free to remove it
> instantly like any other empty graph - but the operation should not
> force the issue.


A "compatible version" adapting the existing text could e.g. look as follows...

--------
"In case no RDF data can be retrieved (as opposed to the empty graph being retrieved) from the IRI denoted by IRIref_from, or in case the retrieval method returns an error (such as, for instance an HTTP error code), the SPARQL 1.1 Update service is expected to return failure and the status of the graph store is expected to remain in the same status as prior to the request; in case the keyword SILENT is present, however, the operation will still return success and the status of the graph store is not specified by the present document: implementations may create the destination graph or not and partially load data, in case of a transmission error where partial data has been received (which itself may be legal RDF)."
--------

... but I am a bit worried that this change could be LC critical. Opinions?

I continue for the other failures (for completeness)

3) Section 3.2.1 (CREATE)
   "if the graph already exists, then a failure should be returned, except when the SILENT keyword is used."

  I guess we agree that in either case the status of the graph store should remain as prior to the request, yes? That is, I would suggest to change to:

   "if the graph already exists, the graph store is expected to remain in the same status as prior to the request and a failure should be returned, except when the SILENT keyword is used; "

4) Section 3.2.2 (DROP)

"If the store records the existence of empty graphs, then the SPARQL 1.1 Update service, by default, is expected to return failure if the specified named graph does not exist. If SILENT is present, the result of the operation will always be success."

Suggest to change to:

"If the store records the existence of empty graphs and the specified named graph does not exist, the graph store is expected to remain in the same status as prior to the request and and the SPARQL 1.1 Update service, by default, is expected to return failure. If SILENT is present, the result of the operation will always be success."

5) Sections 3.2.3, 3.2.4, 3.2.5 (COPY, MOVE, ADD)

  "If the destination graph does not exist, it will be created. By default, the service is expected to return failure if the input graph does not exist. If SILENT is present, the result of the operation will always be success."

 Suggest to change to:

 "If the destination graph does not exist, it will be created. By default, the service is expected to return failure if the input graph does not exist, where the graph store is expected to remain in the same status as prior to the request. If SILENT is present, the result of the operation will always be success."

I think those were all cases. Opinions?

Axel
 
On 15 Aug 2011, at 19:55, Andy Seaborne wrote:

> I have now been able to execute the tests:
> 
> I disagree with "LOAD SILENT INTO" though.
> 
> The operation is:
> 
> LOAD SILENT <DoesNotExist> INTO GRAPH <http://www.example.org/>
> 
> There are several kinds of error caught by the SILENT:
> 
> * The source of the operation does not exist (explicitly 404)
> * The source is not contactable (may or may not exist)
> * The graph has parse errors.
> * Transmission error : partial data recieved (which itself may be legal
> RDF).
> 
> A possible implementation [*] is create the destination in the triple
> store, then attempt to read in the remote data.  This avoids needing to
> have a separate place to conduct the operation in case it does wrong.
> 
> In the SILENT case, I thinks it's reasonable for the named graph to be
> created in each case for uniformity.  Stores are free to remove it
> instantly like any other empty graph - but the operation should not
> force the issue.
> 
> The test assumes it does not exist afterwards.  I suggest not testing
> against possible implementation approaches.  Instead, change into a
> parse error test, with no possible triples even by partial parsing.
> 
>         Andy
> 
> [*] I have this kind of implementation and also the no-empty-graphs kind.
> 
> On 15/08/11 13:22, Axel Polleres wrote:
> > Thanks! The syntax errors were indeed not intended and should be fixed now. Moreover, I added test cases for COPY.
> >
> > best,
> > Axel
> >
> > On 15 Aug 2011, at 14:25, Andy Seaborne wrote:
> >
> >> I get syntax errors when running these tests:
> >>
> >> Error:    LOAD SILENT INTO
> >> Encountered "<IRIref>  "<http://www.example.org/>  "" at line 1, column 76.
> >> Was expecting:
> >>       "graph" ...
> >>
> >> Error:    CREATE SILENT
> >> Encountered "<IRIref>  "<http://example.org/g1>  "" at line 1, column 15.
> >> Was expecting:
> >>       "graph" ...
> >>
> >> SILENT does not imply ignore syntax errors does it?
> >>
> >>          Andy
> >>
> >>
> >
>

Received on Monday, 15 August 2011 19:22:28 UTC