- From: thomas lörtsch <tl@rat.io>
- Date: Sat, 18 Sep 2021 14:27:17 +0200
- To: James Anderson <anderson.james.1955@gmail.com>
- Cc: "public-rdf-star@w3.org" <public-rdf-star@w3.org>
> On 18. Sep 2021, at 12:31, James Anderson <anderson.james.1955@gmail.com> wrote: > > good afternoon; > >> On 2021-09-18, at 11:49:24, Fabio Vitali <fabio.vitali@unibo.it> wrote: >> >> Dear James, >> >>>>> yes, absent a definition for dataset construction, there is no way to interpret the chronology example. >>>>> post-3.8, why does that matter? >>>> >>>> So let me clarify this: 3.8 suggests we use a ASK WHERE query to verify the truth value of a graph. Thus I add a boolean statement to the example, say: >>> >>> more importantly and without regard to the specific consequences as to interpretation, 3.8 refers to a situation which demonstrates that, whichever question one asks, if one defines how to merge graphs, it is possible to answer ones questions. >>> which of 3.1 -- 3.7 one chooses is (modulo issues of completeness and correctness) immaterial. >>> sparlq chooses one. >> >> Allow me to rephrase. >> >> What you are saying is that, regardless of the semantics of named graphs (3.1 <-> 3.7) one may think they have chosen for their application, > > i am unsure what you intend your formulation to mean. > i do not claim "regardless of the semantics". > i suggest that one can choose a definition - from among 3.1--3.7 or elsewhere, given which an interpretation of a given question is possible in the context of the constructed dataset. > this is more a matter of "dependent on", rather than "regardless" (given its possible connotation of "independent of"). > >> if they are using sparql at all they will end up with 3.8 anyway, because the sparql part will use it regardless of opinions and wishes. > > yes, because a combination follows from sparql's conformance requirements. > one could choose some other combination. > one would then have a different query language. > dealer's choice. > > best regards, from berlin, Please help me to understand: IIUC SPARQL ASK queries return TRUE if the BGP that is asked for is either included or entailed locally to a graph (not across graphs) in the named graphs the query refers to in its request. So what you, James, are saying is that it is up to the user to decide which graphs to ask - which is a very important aspect w.r.t. Fabios general aim to control the scope of what is considered true, conjected etc. Do I understand that right? If I do, then I’d like to add that the Named Graphs paper from 2005 by Carroll et al proposed some vocabulary that allows to express which graphs are to be considered 'accepted', merely quoted etc. I agree that something like that could go a long way towards standard - and flexible - graph semantics if it was properly declared and followed. Fabios proposal on first sight seems even more powerful - a very interesting perspective! Also the following is not quite clear to me: IIUC the Note on Dataset Semantics discusses named graphs semantics along the following 4 dimensions and no others: 1: if the name refers to the graph itself or something else (which is in an unspecified relation to the graph) 2: how named graphs in a dataset influence the truth value of each other 3: if named graphs are referentially opaque or transparent 4: if named graphs are types or occurrences If this list is correct and complete then I understand that SPARQL ASK answers these questions as follows: 1: it does not answer this question, leaving the denotation of a graph name undefined 2: it does answer this one, treating graphs as independent contexts 3: it does answer this one, treating graphs as referentially transparent 4: it does answer this one, treating graphs as occurrences (here I’m not entirely sure but as SPARQL does access graphs by name, not by their content…) So when ASKing, SPARQL defines most aspects of the semantics of named graphs but not what the graph name denotes. 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? Or can we exclude this possibility because it violates basic principles of web architecture w.r.t. URI collisions? I do think so but I wonder why the Note (or rather the RDF 1.1 Working Group) didn’t. However if we agree that the above list is complete, that my answers to 2, 3 and 4 are correct and that 1 is answered outside of SPARQL by one of the most basic principles of web architecture then … yeah, that would indeed be an interesting perspective on the question of how undefined the Named Graphs semantics actually is. Best, Thomas
Received on Saturday, 18 September 2021 12:27:36 UTC