Re: graph terms vs nested triples

> On 22. Dec 2023, at 10:40, Pierre-Antoine Champin <pierre-antoine@w3.org> wrote:
> 
> 
> On 21/12/2023 19:04, Thomas Lörtsch wrote:
>> To poke a bit it the perceived impossibility of graph terms:
> Assuming that this questions is aimed (at least in part) at me (following my concluding remark from yesterday):

It’s aimed at everybody, and you are of course welcome to answer it.

> I'm not saying that graph terms are impossible. I've been involved in the Notation 3 Community Group (although less so recently), and working on a proposed semantics for graph terms.
> 
> Graph terms are definitely something possible, and IMO a great idea.
> However, I'm not sure that they are ripe for standardisation just yet
> (judging from some reactions in the WG,

The WG is indeed reluctant, but *we* are the WG and *we* have to discuss the issue.

> and more generally on their adoption of lack thereof in the wild).

This is a pretty peculiar interpretation of adoption, clipping most of the semantic web as we know it. Notation3 does indeed lack adoption in the wild, named graphs however quite to the contrary. That does rather supports my point that the concerns of the WG, which center around issues that Notation3 so far hasn’t standardized, shouldn’t hold us back from standardizing the basic attributes of graph terms, namely naming and sound denotation. The issues that the Notation3 community still discusses - namely reasoning across graphs IIUC - can be standardized when they are settled. Such issues so far haven’t hindered the adoption of named graphs. One could say: the lack of adoption of Notation3 shows the lack of relevance of the still unsolved questions for the whole field of graphs. Please don’t get me wrong on this: I’m not saying that Notation3 would not open great prospects when those issues are eventually resolved. I’m just saying that they are not blocking a more pedestrian usage of graphs, and shouldn’t block standardization of the basics. From what I understand, sound denotation is required in any but the most basic szenarios, and standardizing it will not impede standardization of more advanced issues as discussed in Notation3.

>> what is the difference between a nested triple term, e.g.
>> 
>>     << << :a :b :c >> :d :e >>
>> 
>> and a graph term? How is it categorically different from e.g.
>> 
>>     << :a :b :c .
>>        :x :d :e >>
>> 
>> ?

In your answer you haven’t discussed my question at all. So I tried to make it more convincing as follows:

 << << :x :y :z>> :a :b ; 
                  :c :d >> :v :w .

This should be a pretty standard use case where a quoted triple has a multipart annotation which again is annotated. Here the nested triples cleary form a graph. However, the only RDF-star online validation service that I could find, http://sparql.org/query-validator.html, rejected it with a syntax error:

 Encountered " ";" "; "" Was expecting: ">>" …

So it seems that RDF-star still has unpleasant surprises in stock at least for me. I can’t remember that this issue was ever discussed and I wonder if it’s handled consistently across implementations.


> AFAICT, there are (at least) two kinds of concerns about graph terms:
> 
> * they add "structural" complexity to the abstract syntax ;
>   the people with this concern are equally concerned about "nestable" triple terms (e.g. Niklas, Souri, if I am not mistaken)

Given the above discovery one may indeed be tempted to dismiss at least RDF-star’s interpretation of nesting (and what can I say: IMHO triple terms shouldn’t go into the core of RDF and the shorthand syntax should be normatively defined as syntactic sugar for RDF standard reification). However, my original question is not about nesting, and the concerns about nesting are based on complexity, not on graphs IIUC. The two issues are not completely orthogonal, but they shouldn’t be thrown into one pot either.

> * they add "usability" complexity,

That is an argument that goes both ways: there is always a balance to be struck between expressivity and complexity. Graphs are in general considered very useful when tackling repetitive tasks. As the nested graph proposal shows they can also be used to structure the information space and make an unwieldy entangled mess of triples more manageable, more accessable. Using them wisely is of course advisable, but that should go without saying. The huge popularity of named graphs, despite their lack of proper standardization, IMO proves that there is a need for expressive means beyond the simple (but also simplistic) triple. That is hardly a new insight, given that the discussion about (the need for) graphs is almost as old as the triple formalism itself.

> as different people with different use cases may have different expectations about how graph terms behave with inference/querying. See the excellent examples that Peter put in his slides [1], pages 4-9.

You are conflating inference and querying. If I understand Peter correctly his concerns are about inferencing across graphs. We discussed that in the Semantics TF and my take away was that the issues that Peter points out are both quite special w.r.t. use cases and quite well defined - i.e. they are clearly distinct from the mainstream of use cases, especially in querying but also w.r.t. entailment *within* graphs.


> [1] https://lists.w3.org/Archives/Public/public-rdf-star-wg/2023Oct/att-0108/work.pdf
> 
>   pa
> 
>> 
>> Or at least different enough that the former was for a decade by and large considered unproblematic (modulo concerns w.r.t. computational complexity) whereas the latter raises all kinds of vague concerns?
> meta-remark: you're doing it again, please refrain...

That is a questionable remark: you make some extremely vague reference to "it" and "again", but add a pretty judgemental framing - at least it seems to me that that’s how I’m supposed to interpret your remark. I don’t think that's appropriate. To the contrary, you should be quite precise when making such a remark, you shouldn’t jump to conclusions w.r.t. to my stated view (is there something obviously unacceptable about calling a concern "vague"?) and you should be very scrupulous before claiming some moral high ground (which of course is my interpretation, but motivated by the somehow stilted wording). 

Recently Adrian attacked me for being "paasive aggressive" when I was indeed only countering your very questionable framing of calling for a fundamental change to RDF-star as risking to split the community. I don’t like those spins of yours, just as I don’t like it when you represent reality as selectively as you did above w.r.t. adoption of graphs, or when back in the CG you claimed support of RDF* in the wild as support for the proposed semantics (while indeed that semantics never had much support in the wild).

You will have to excuse me if I occassionally get pert about such argumentation, that is too selective to be reliably disambiguated from spins, from outright manipulation. Being very polite - as you unquestionably are - doesn’t completely make up for that. And please don’t forget that I had to fight for *years* to get this CG/WG to acknowledge the primacy of occurrences over types in practice. I brought forward "Andy’s proposal" shortly after the shorthand syntax was introduced - again, years ago - and I can’t remember if you even found it worth a response back then. I have absolutely no desire to have those discussions again, to have to fight those decidedly uphill battles again. So, yes, I may occassionally be a bit sensitive and sharp. I would be much less so if our discussions were always as open minded, constructive and scrupulous as they are supposed to be. 


Best,
Thomas


>> 
>> Best,
>> Thomas
> <OpenPGP_0x9D1EDAEEEF98D438.asc>

Received on Wednesday, 27 December 2023 12:17:14 UTC