Re: graph terms vs nested triples

Hi Thomas, all

On 27/12/2023 13:16, Thomas Lörtsch wrote:
>
>> 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,
Note that I merely answered for myself ("I'm not sure"), for the WG
>   but *we* are the WG and *we* have to discuss the issue.
Looking at our charter, it is debatable that we /have/ to discuss it:
a strict reading of the charter would lead to the conclusion that only 
triple terms are in scope.
I'm not strongly advocating for this strict reading, in fact, we are 
discussing it right now.
>
>> 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.
Ok, named graphs are widely adopted. But graph terms and named graphs 
are very different beasts. Named graphs are part of RDF 1.1 Abstract 
Syntax. 'Graph terms" extend the abstract syntax with a new kind of terms.
>   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.
How is this related to graph terms?? You lost me here.
>   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.
I was trying to...
>   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.

In RDF-star, the double-pointy bracket delimit a quoted *triple*., i.e. 
a subject, a predicate and an object. The outer-most brackets in your 
example above clearly (?) contain one subject (which is itself a quoted 
triple, << :x :y :z >>), but two predicates (:a and :c) and two objects 
(:b and :d). I don't think it should be overly surprising that you can't 
fit that in a quoted *triple*/./

Hopefully this answers your question better.

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

Let me try to rephrase, then. As I pointed out above, a quoted triple / 
triple term has exactly 3 constituents. A graph term has an arbitrary 
number of constituents. That's additional complexity. That's the point I 
was trying to make.

I understood that your question was not about nesting, but since it has 
been argued (by others) that the "nestability" of complexity makes them 
also complex, despite the fact that they are restricted to two 
components, I felt this should be included in my response as well.

>> * 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.
Inference and querying are two different things, but they are related -- 
SPARQL pattern matching corresponds exactly to RDF simple entailment.
All of Peter's examples in his slides are expressed in terms of 
entailment, but could be equivalently reworded as a SPARQL ASK query.
>   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.
I would be interested in a set of explicit criteria that help to 
distinsguish a "maintream use case" from other use cases.
>
>
>> [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",

I'm sorry if this remarks was not explicit enough; I thought it would be 
clear that I was referring to Adrian's remark on Dec 7:

https://www.w3.org/2023/12/07-rdf-star-minutes.html#x169


>   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"?)
As a matter of fact, I do consider that dismissing other people's 
concern as "vague" is slightly offensive, yes.
>   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>
>