W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2010

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

From: Andy Seaborne <andy.seaborne@talis.com>
Date: Wed, 21 Jul 2010 14:11:12 +0100
Message-ID: <4C46F1F0.7000609@talis.com>
To: Axel Polleres <axel.polleres@deri.org>
CC: SPARQL Working Group <public-rdf-dawg@w3.org>


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 13:11:40 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:43 GMT