Re: RDF* and conjectures

good afternoon;

> On 2021-09-21, at 13:30:47, thomas lörtsch <tl@rat.io> wrote:
> 
> 
> ...
> 
> My original argument however was that SPARQL only retrieves and its syntax unambiguously defines if an IRI is used to address a named graph. Maybe that isn’t true as for example there’s also SARQL update which I have not looked into yet. But if you’re interested in understanding my original reasoning, pre-reading the spec’s definition what the graph name denotes, read the following paragraph again:
> 
>>>>> Using the graph name in the FROM clause refers to the graph. Using it to annotate the graph however is shaky territory: nothing in SPARQL prevents me from naming my graph with triples from Paris with the URI <paris.com>. So I have no soundly defined way to annotate that graph, right?
>>>> 
>>>> which graph was that?
>>> 
>>> The graph that is addressable by that name in the dataset.
>> 
>> which graph was that?
>> (this is not a rhetorical question. once you answer it
> 
> For example:
> 
> <paris.com>  {
>    :me :goingTo <paris.com> ;
>        :purpose :conference .
> }
> 
> <paris.com> :created "53 b.c." , 
>                     "just now" . 
> 
> It’s easy to query for the graph named <paris.com> because using the IRI in the FROM clause determines that it is used as a graph name. But it’s hard to annotate the graph so named because the IRI used to name it denotes two different things: the graph and the city (not to mention the website itself, but let’s refer to the Cool URIs document for that discussion). But I take it now that not only basic principles of web architecture but also the SPARQL spec itself discourage such unsound naming practices.
> I probably wouldn’t argue about this seemingly obvious point at all if the Note didn’t discuss it (and Antoine Z. didn’t still employ examples where he reasons over graphs that have the same name but different sets of statements)

the sparql recommendation even alludes to contributing circumstances where it allows, if the designators in a dataset definition are interpreted as locations from which statements are to be retrieves and a given designator appears more than once, the respective content may not be identical.
zimmerman suggests dataset construction and interpretation methods other than those of sparql which could facilitate such reasoning.

absent such variants, the recommendation's named graph examples (https://www.w3.org/TR/2013/REC-sparql11-query-20130321/#exampleDatasets) demonstrate that it intends the VarOrIri from a GraphGraphPattern to unify within the dataset with any subject, predicate, or object elsewhere in the sparql expression, subject to the algebra's scoping rules and the entailment regime, but otherwise without restriction.
in other words, _within the extent of a given constructed dataset_, i do not understand what problem annotation presents.

best regards, from berlin,

Received on Tuesday, 21 September 2021 12:50:18 UTC