Re: victory is not declared, but won

Dear Thomas, 

This is a very long mail covering a lot of topics and as I am afraid that this will also result in many responses targeting different topics you touched. Maybe we should structure your questions and discuss them one by one.

Having said so, I now pick the N3 topic and try to focus on that aspect (with some exceptions, sorry, I can’t hold back :) ).

> Am 29.11.2023 um 23:33 schrieb Thomas Lörtsch <tl@rat.io>:
> 
> Dear WG,
> 
> 
> regarding Agenda 2. - Proposal for next week's discussion - I'd like to propose two topics:
> 
> 
> 1) Graphs
> 
> Graphs were on the table (and that’s why Datagraph/Dydra joined the working group) and it seems they now get pushed off the table again. An argument has been introduced about problems with graph term entailments and there are long standing reservations against strengthening named graphs to make them usable for semantically sound annotations. Both arguments however are rather sweeping and haven’t been properly discussed.
> 
> If we dismiss graphs alltogether and settle for statement level annotations, we’re falling prey to a new problem: we will never be able to provide clear guidance about when which annotation mechanism should be used, named graphs or some tbd triple based approach. The best we could do is to advice people to use only the new mechanism, creating two new problems: we would thereby invalidate a good part of the installed base of named graphs, and we would still lack a graph based approach to annotation (or does someone want to live in a world where _all_ annotations have to be made per statement?). We can’t just declare named graphs off limits for any sound modelling - that would amount to calling them ripe for deprecation. The RDF 1.1 WG left a note on what was done and what could be probable venues of future endeavours. That note should guide us, not unspecific fear of breaking some free-wheeling first generation implementations.
> 
> For such reasons I think it is important that we discuss this in some depth. Also, and in any case, I’d like to encourage Andy to provide more detail about the problems he sees w.r.t. the installed base of named graph implementations. The RDF 1.1 WG Note on dataset semantics discusses some, but it seems that he sees more.
> 
> I proposed to discuss the other graph-related aspect, graph term entailment, in a Semantics TF meeting this Friday. There hasn’t been any response to that, but I’m still hopefull. To pepper the request a bit: apparently Notation3 did get by with graph terms for more than 20 years already. Why are the problems that Peter laid out a problem for the semantic web?

The problems Peter laid out are not a problem for the semantic web. What Peter laid out is that there are many ways how to understand graph terms. The problem is thus not, that this is not doable. The problem is that we will have to agree on the semantics and in order to agree, we will need a lot of discussions. This is an interesting thing to do and we should go for that, but we should go step by step: I would argue that triple terms are easier than graph terms and therefore, I would want us to first focus on the triple terms and then get further after that part of work is done. I see the danger of getting lost in discussions here and then end up with nothing at the end.

Notation3 has graph terms and we now even think that we formalized them properly (but I will adjust the explanations of the semantics such that outsiders better understand, so be aware that Peter could still break it ;) ). But finding that semantics took a long time and that despite the fact that the use was rather clear. Here in this group we consider more use cases and we are less focussed on rules. Therefore, I expect that our views on graph terms are more diverse. Of course we can built up on N3 and the things we discussed in The CG. The N3 CG even plans to go further with N3, we just agreed that it would be better to wait for RDF-star and see where the semantics of triple terms lands.

> And why are they considered relevant enough to dismiss the enormous usability benefits that graphs bring? Can’t they be solved, or at least called off limits, without breaking something very basic? What would that be? And again, why didn’t it break Notation3? It seems to me that a bit of pragmatism would be adequate. This is the semantic web, and logic in this context should be a means to an end - no less, no more. 
> 

We do not dismiss. Even though there is no decision taken yet, I would want to prioritize graph terms first. Mainly because it is easier to solve problems step by step.

> 
> 2) Basics
> 
> There is a lot of talk about abstract syntax and foramlizations (and I agree that the Nested Named Graph proposal doesn’t provide enough of both yet). However, there is also a glaring lack of a deeper understanding of the issues at hand.

Here I can clearly speak from an N3 perspective: formalization is a way to better understand the issues. Notation3 was quite some time without explicit semantics and we could observe that some concrete ambiguities in the informal spec lead to differences in the implementations. If we want to have a standard, we should make sure that it is formalizable and that the formalization is in line with the intended use (here I am with you again). All these intents to formalize and also the questions about the formalization of your ideas serve the purpose of fully understanding them.

> As I argued with Olaf this week, a formalization may be nice and pretty, but it is of little practical relevance if it doesn’t  formalize what’s actually needed.

These things are not separated. Formalization helps us to understand. It is not just about formalizing what is actually needed but about making proposals more concrete and to test whether it can be formalized at all.

> But there is very little discussion of what is actually needed in this WG, and there has been very little such discussion in the CG as well - I was even accused of stealing people’s time when I insisted on questioning the design of RDF-star as referentially opaque types. Many just _want to believe_ that there must be a simple solution and that we can force it into practice, declaring victory without actually winning. It’s a "don’t look up" approach where the winner - RDF-star - has already been crowned and now we just have to make it work somehow.  It won’t work. It will only undermine the credibility of W3C and the semnatic web standards suite.

Maybe you can share your examples with us. I think the formalization is just an attempt to make the discussion concrete. Detailed examples (like the ones Peter is working on) can serve the same purpose. Maybe a use case could help us to convince us? 

> RDF* had a basic design flaw from the beginning - targeting types instead of tokens - and the CG only made things worse with the proposed semenatics.

Just a short remark since that came up in several of your mails. I am totally not convinced that RDF-star should directly target tokens in the way you see them (in a way referential opaque triples could also be seen as tokens, there is a new source for discussions ;)). The moment you address tokens, you want to refer to them, that is, you will need a name. If your really want to re-use such a name, it should not be hidden in syntactic sugar. But now I go against my plan to limit my answer to N3, sorry for that.

> This happens because there is no proper understanding, but more importantly not even a proper will to try to understand, the underlying design issues of meta modelling, namely that it has to target occurrences, that its semantics has to be very middle-of-the-road, that there should be no gap between the statement and its annotation (like the gap that all type-based approaches but even RDF standard reification introduce and that the OneGraph paper discusses w.r.t. to updates and deletes), and that it should be applicable to both singleton and sets. 
> 
> And then there is the question of the goal:
> - RDF* was conceived as an alternative to verbose RDF standard reification. 
> - the Berlin graph workshop aimed for RDF/LPG interoperability. 
> - the issue of graphs in RDF has developped into a veritable trauma, but it is the elephant in the room: grouping stuff is the most basic knowledge representation activity thinkable, even more basic than graphs. A proper grouping mechanism will always be required. 
> If we really settle for just one very minimal solution then IMO it has to be tailored to LPG interoperability. That certainly means tokens, not types, and it certainly means referential transparency. It also means singletons, but then again: it would be so easy to extend such a mechanism to sets that I really can’t see why we can’t do that too, and do everything right. That’s topic 1 again.
> 
> 
> 
> I know that many of you just want to go home and be done with it. Maybe it would be better to dissolve this WG without any result? Certainly better than doing something stupid.
> 
> 
> Best,
> Thomas
> 
> 

Kind regards,
Dörthe

Received on Thursday, 30 November 2023 12:21:29 UTC