Re: RDF* and conjectures

Thanks for your help, James!

> On 18. Sep 2021, at 15:16, James Anderson <anderson.james.1955@gmail.com> wrote:
> 
> good afternoon;
> 
>> On 2021-09-18, at 14:27:17, thomas lörtsch <tl@rat.io> wrote:
>> 
>> 
>> ...
>> 
>> 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?
> 
> [this is not _my_ claim.]
> _for sparql_, section 13, describes constructing and querying the dataset (https://www.w3.org/TR/2013/REC-sparql11-query-20130321/#rdfDataset).
> 
>> 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
> 
> [again, it does not matter, whether you understand _me_. the documents are what they are.]

I agree that reading the spec is indeed a useful approach ;-)

>> 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:
> 
> the ASK operator does not itself answer the questions.
> section 13, which describes how to construct the dataset and how graph matching contributes to the interpretation of any expression,  does.
> 
>> 1: it does not answer this question, leaving the denotation of a graph name undefined
> 
> the sentence in 13.2.2 
> 
>    The IRI identifies a resource, and the resource is represented by a graph (or, more precisely: by a document that serializes a graph
> 
> can be read in a way which provides one answer to this question

…although not completely unambiguous. But the introduction of Section 13 says: 

    An RDF Dataset comprises one graph, the default graph, which does not have a name, and zero or more named graphs, where each named graph is identified by an IRI.

and that settles that: the name identifies the graph it names.

>> 2: it does answer this one, treating graphs as independent contexts
> 
> they are distinctly designated sets of statement to be combined into the dataset as per the prolog and made the target of graph patterns dependent on context.

What prolog are you referring to? I guess you mean the FROM and FROM NAMED clauses that define the scope of the query.  That's not the aspect I'm trying to understand. Example 24 in the RDF 1.1 WG Note on the semantics of datasets [https://www.w3.org/TR/2014/NOTE-rdf11-datasets-20140225/#relationship-with-sparql-entailment-regime] shows how the RDFS entailment regime is employed per graph but not across graphs. That’s what led me to the above conclusion.

>> 3: it does answer this one, treating graphs as referentially transparent
> 
> this is not definitively answered as the combination method is suggested, but not stipulated.

As in the previous question I’m not sure we speak about the same topic. The scope of the query - as per my understanding of your previous answer - IMO has nothing to do with it. I see only two possible answers to this question: the statements contained in a graph are either interpreted (as any regular RDF statement, irrespective of the entailment regime chosen) or quoted. Now reading more documents, SPARQL 1.1 Entailment Regimes [https://www.w3.org/TR/2013/REC-sparql11-entailment-20130321/] says in the introdction that

    The SPARQL 1.1 Query specification [SPARQL 1.1 Query] defines the evaluation of a basic graph pattern by means of subgraph matching. This form of basic graph pattern evaluation is also called simple entailment since it can equally be defined in terms of the simple entailment relation between RDF graphs.

Other more elaborate entailment regimes like RDFS-entailment of course work in the realm of interpretation, not on quoted literals. I’d say that confirms that SPARQL generally treats 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…)
> 
> this is also not definitively answered, as it is described that repeated designators may or may not designate the same set of statements.

Variability over time is an issue that RDF in general doesn’t tackle. But in my intuition a name that refers to a type should really be stable whereas a name referring to an occurrence could be allowed more flexibility. So I would take this aspect as a slight confirmation of my provisional assessment that named graphs to SPARQL are occurrences.


> that there are variants is not material to the principal issue, as is it is not one of interoperability but of ability.
> any given sparql implementation must have a complete answer to those questions or its operators will not close.

For an implementation not to terminate would indeed be a bad pre-condition but interoperability is what we strive for after all when defining standards, isn’t it?

>> So when ASKing, SPARQL defines most aspects of the semantics of named graphs but not what the graph name denotes.
> 
> how can a process which must be applied to a concrete collection statements which were designated by graph names do one without the other?

Which one and which other are you referring to?

>> 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.

> why does it matter that there is no universal relation between the designator for a graph and the set of statements which it contains?
> for a given implementation, there must be a necessary relation, but it need not be universal.

Within an application you are free to do whatever you want. If you want to exchange data on the web and integrate data from other sources in your application, your life becomes a lot easier if you don’t have to guess or read up the documentation or even the sourec code to figure out what naming semantics are employed in the data you are interested in. There must not be one universal relation. A default relation and a way to declare alternative relation types would be very helpfull.

>> Or can we exclude this possibility because it violates basic principles of web architecture w.r.t. URI collisions?
> 
> there is nothing in the recommendation which stipulates that the content must be the resource which would be retrieved given via http (or whatever) protocol were the designator to be treated as a location.
> there are implementations in which the graph designators bear no necessary relation to resources in the internet.

You seem to see that as the exception. I had hoped that it would be rather the norm.

> it is even permitted to designate a graph wth a blank node.

Yes, and that’s fully in line with what I deem reasonable. I would like the graph name to only name that graph and nothing else, not a date of ingestion, not a topic like Paris etc. As I just figured out above the SPARQL spec seems to agree.

> yes, rdf originated as a way to describe web resources.
> it has advanced well beyond that.

It is not the question if the resource so identified is a web resource. The question is if one identifier is allowed to refer to two different resources simultanously. As the <paris.com> example shows this may work in one scenario - querying - but not in another - annotating. Generally it is discouraged in web architecture, and for good reason.
 
> best regards, from berlin,
> 
> 

thomas

Received on Monday, 20 September 2021 21:15:23 UTC