Re: SPARQL test case structure for update test cases (ACTION-267 completed)

So, in the end it looks like we can't just use qt:data and qt:graphData (neither for update nor for  entailment tests)...
maybe better to return to my initial proposal with a separate vocabulary?
I didn't want to overload the sd: vocabulary, since it implies domain and range restrictions that aren't 
fulfilled for test case manifests...

Axel

On 21 Jul 2010, at 14:11, Andy Seaborne wrote:

> 
> 
> On 20/07/2010 1:36 PM, Axel Polleres wrote:
> > Hi all,
> >
> > I completed ACTION-267 and modified the structure of update test cases to use qt:data/qt:graphData to denote the graphstore for update test cases
> >
> > http://www.w3.org/2009/sparql/docs/tests/README.html
> >
> > Note however, that I couldn't use qt:graphData the same way as it was done for query test cases.
> > I modified the text explaining qt:graphData as follows:
> >
> > "The qt:data and qt:graphData relations points the status of the Graph Store prior to the update execution described in terms of at most one qt:data property denoting the unnamed graph and optional qt:graphData properties denoting named graphs. The object of the qt:data property is a URI reference to an RDF graph, whereas the object of the qt:graphData property indicates the named graph components of the Graph Store. Named graphs are described either by explicit URI reference (in which case the graph name is supposed to correspong to the respective URI reference), or the object of the qt:graphData property may be a resource further described in terms of a reference to the graph by the qt:data property and a reference to its name under which it is accessible in the graph store using the rdfs:label property."
> >
> >
> > The reason why this is needed (explicit reference of the name) is that in SPARQL UPDATE a named graph can be modified, so I can;t just dereference it by it's name.
> > (Note that an alternative would still be to use just qt:data and a TriG file, but I suggest to go with the current, due to the non-standard status of TriG)
> >
> > (I also added some test cases illustratign this, particularly insert-data-spo-named2 ... see next mail)
> >
> 
> What's a "URI reference"?  I only know this from RFC 2396 where is means
> a URI with a #fragment (IIRC) and RFC 3986 (sec 4.1) where teh term is
> broadened to:
> 
> URI-reference = URI / relative-ref
> 
> Did you mean:
> 
> "RDF URI Reference" (it's different and defined by RDF - it includes
> space :-()
> "IRI" because that is what the "RDF URI Reference" should have been but
> couldn't as it did not exist at the time (and was expected to include
> spaces).
> 
> >
> > I did a similar addition to the query test cases section, which allows us to explicitly rename graphs for future query evaluation test cases as well:
> >
> > "The object of the<tt>qt:graphData</tt>  property may be a resource further described in terms of a reference to the graph by the<tt>qt:data</tt>  property and a reference to its name in the dataset using the<tt>rdfs:label</tt>  property."
> >
> >
> > Axel
> 
> On 20/07/2010 6:12 PM, Axel Polleres wrote:
>  > minor update on that: following the dioscussion today, I changed the
> graph names in the examples to plain literals instead of URI refs (also
> because rdfs:label has Literals as range)
> 
> Here is one of the tests:
> 
> :insert-data-spo-named1 rdf:type ut:UpdateEvaluationTest ;
>      mf:name    "Simple insert data named 1" ;
>      rdfs:comment "This is a simple insert of a single triple to a named
> graph of an empty graph store" ;
>      dawgt:approval dawgt:NotClassified ;
>      mf:action [ qt:query <insert-data-named1.rq> ;
>                  qt:data <empty.ttl>
>                ] ;
>      mf:result [ ut:result ut:success ;
>                  qt:data
>                     [ qt:data <empty.ttl> ;
>                       qt:graphData  [ qt:graph <spo.ttl> ;
>                                       rdfs:label "http://example.org/g1" ]
>                     ]
>                ] .
> 
> 
> 1/ The overloading of qt:data doesn't work for me. It reads as a double
> meaning which is what URIs are supposed to help avoid.  Even worse
> where, qt:data is the default graph but it describes a named graph as well.
> 
> Can we reuse some vocabulary from service description?  sd:defaultGraph
> and sd:namedGraph and add a "contents from".  i think we need an
> explicit way to say "these are the contents of this graph" - we didn't
> need it in SPARQL 1.0 testing as qt:graphData was enough.  Here, we are
> at risk of parser-ism on relative IRIs
> 
> 2/ qt:graphData : much the same but the use of a plain literal as the
> label (rdfs:label is defined by text including "may be used to provide a
> human-readable version of a resource's name.")
> 
> 3/ qt:query <insert-data-named1.rq>
> 
> A query is not an update - shouldn't we have ":update"?  Also, I don't
> use .rq as that comes from the MIME type registration for SPARQL 1.0.
> Instead I suggest ".ru" (and aren't we going to apply for a second MIME
> type for an update? This would be useful for an endpoint that handles
> query, update and WWW-forms).
> 
>         Andy
> 
>

Received on Wednesday, 21 July 2010 16:32:27 UTC