- From: Gregory Williams <greg@evilfunhouse.com>
- Date: Mon, 28 May 2012 10:41:19 -0400
- To: Andy Seaborne <andy.seaborne@epimorphics.com>
- Cc: public-rdf-dawg@w3.org
On May 28, 2012, at 9:27 AM, Andy Seaborne wrote:
>> Question to greg here: is this because bnode-labels in greg's implementations are graph-specific? If so, and if these label
>> renamings across graphs are round-trippable, then update 2 should probably also be idempotent, i.e. still the result would be
>>
>> GS'''' = {}
>> <g1> { _:b :p :o }
>> <g2> { _:c :p :o }
>>
>> Is that so?
>
> No (I hope).
>
> Greg - can you confirm that the problem is the way the results are specified, not test per se:
>
>
> mf:result [
> ut:graphData [ ut:graph <insert-05-g1-pre.ttl> ;
> rdfs:label "http://example.org/g1" ] ;
> ut:graphData [ ut:graph <c> ;
> rdfs:label "http://example.org/g2" ] ;
> ] ;
>
> means read the file insert-05-g1-pre.ttl a second and third time, the first being in the mf:action.
>
> So it generates different blanks nodes each time it's read, hence no shared bank node *in creating the results* -- nothing to do with the operation.
Correct. As I said, and as you describe, the problem is the multiple parsing of the same file into the expected dataset, not in the update evaluation.
> Hence either specify results in TriG/N_quads (but these are under-defined in this area) or make a conclusion that records the intended result and test for that (my long update request suggestion).
Yes. I think your proposed solution (inserting the statement count back into the dataset) is the only sensible path forward on this.
.greg
Received on Monday, 28 May 2012 14:41:47 UTC