Re: RDF* and conjectures

Dear Thomas, all. 

My own impression is that the semantics of named graphs is problematic in a way that cannot be fixed, and it is better to find a way out in a totally different way. 

We have a proverb where I come from, that says: if you glue back together a broken vase, you still have a broken vase. Dataset semantics is a broken vase. 

Personally, I see a clear parallelism with RDF reification, a complicated and pedantic mechanism for an important necessity, and although it has a clear semantics, but over time people have variously enforced or ignored it, so it is not reliably found in the wild. So Olaf and you guys said: RDF reification is a broken vase, and even if we fix it we still are stuck with a broken vase. Instead, let's get a new and shiny vase and use it in addition with the old one for our purposes. 

So with RDF*  we now have 
1a) a nice and compact syntax for stated triples s p o 
1b) which corresponds, for those so inclined, to _:x a rdf:Statement; rdf:Subject s; rdf:Predicate p; rdf:Object o.   
and  
2a) a nice and compact syntax for non-stated triples <<s p o>> 
2b) which corresponds, for those so inclined, to _:x unstar:Subject s; unstar:Predicate p; unstar:Object o, etc..   

Things are clear, the truth state of quoted triples in RDF* is clearly non asserted, and it is impossible to confound the two types of statements, neither in syntax nor in semantics. Nice and clean: if there is a doubt in interpretation, create something new so different from the old that there is no way to mixing them up again. Good. 

Now let's come to named graphs. This situation is better from the syntactical point of view, since graph syntax is actually quite reasonable, but worse from the semantic point of view, since there is none accepted. 

This is a broken vase, and even if you manage to glue back all that is wrong in the current situation, it would still be a broken vase. Let's learn the lesson from RDF* and let's get a new and shiny vase and use it in addition with the old one for our purposes. 

Then we would have
1c) a nice and compact syntax for usual named graphs, whatever semantics you want to associate to them, as before (the broken vase)
2c) a nice and compact syntax for non-stated named graphs (the new vase)

Things would be clear, the truth state of quoted graphs would be clearly non asserted, and it would be impossible to confound the two types of graphs, neither in syntax nor in semantics. Nice and clean. 

This is what I wish to create: a new and shiny vase for graphs corresponding to the one that RDF* is becoming for reification. 

Ciao

Fabio

--

> On 22 Sep 2021, at 23:47, thomas lörtsch <tl@rat.io> wrote:
> 
> 
> 
>> On 21. Sep 2021, at 19:08, Andy Seaborne <andy@apache.org> wrote:
>> 
>> The more appropriate text for RDF-star is probably that in
>> "RDF 1.1 Concepts and Abstract Syntax"
>> 
>> 1.6 Working with Multiple RDF Graphs
>> https://www.w3.org/TR/rdf11-concepts/#managing-graphs

>> 
>> and the definition:
>> 
>> 4. RDF Datasets
>> https://www.w3.org/TR/rdf11-concepts/#section-dataset

>> 
>> which has the note:
>> 
>> """
>> Despite the use of the word “name” in “named graph”, the graph name is not required to denote the graph. It is merely syntactically paired with the graph. RDF does not place any formal restrictions on what resource the graph name may denote, nor on the relationship between that resource and the graph.
>> """
> 
> The failure of the RDF 1.1 WG to standardize a named graphs semantics is well known and the very reason for this soul searching expedition into the semantics of SPARQL as a normative practical force. 
> 
> As a co-editor of SPARQL 1.0 and 1.1 and a participant in the RDF 1.1 WG (and co-editor of TriG as I just noticed) and probably numerous other RDF-related standardization efforts you should be in a formidable position to shed some light on the question which model theoretic semantics might best describe the semantics of SPARQL. 
> 
> You might also comment on if the RDF 1.1 WG discussed standardizing a model theoretic semantics as close as possible to the operational semantics of SPARQL, if that was deemed impossible for technical or "political" (read: conflicts with vendor interests) reasons. 
> 
> These are just two ideas of how you could help flatten the knowledge differences in this CG.
> 
> Thomas
> 
> 
>> 
>>   Andy
>> 
> 
>

Received on Thursday, 23 September 2021 11:00:17 UTC