Re: victory is not declared, but won

On 30.11.23 06:33, Thomas Lörtsch wrote:

Hi Thomas,

First, I still have a very hard time understanding some of your
arguments (I try, I just don't understand/follow some of them). And I
have the feeling that I'm not alone. But I still want to react to some
of the things you write in this email:

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

As of today, the RDF-star Working Group Charter does not mention graphs.
We started talking about them and I think for good reasons. But as Peter
mentioned several times, we never adjusted the charter. So as of right
now, graphs are *not* officially on the table in the group.

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

Very early in the discussions we IMO acknowledged as a group
(informally), that graphs are a can of works *exactly* because there is
no clear definition and/or application of them. (Almost) everyone is
using them but in some slightly different way than others. I've seen
stuff which I found completely nuts to do with graphs but this is the
reality.

But again, there is no word about graphs on our charter and we would
have to decide as a group that we want to "strengthening named graphs".
I don't say this is a particularly bad idea but I doubt we will get
there anytime soon, even if we would decide to take this route.

> 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

I find this a strange argument. The strength and weakness of RDF is, as
Dan Brickley & Libby Miller put it that "RDF is painfully simplistic,
but it allows you to work with real-world data and problems that are
horribly complicated"

People use RDF in very different ways. I don't see how we can come up
with one way to rule them all and I don't think it's our job to do so as
a WG. I always liked "Primers" around RDF & schemas/ontologies as it
gave me an overview of a topic and best practices about how I could or
should address a problem. But none of these primers tell me that this is
the only way. Months ago I did mention that I would like to have an
RDF-Star primer at some point, which gives a more real-world take on how
to use the formal RDF-Star specification once we are done. But that
doesn't mean that everyone has to (or will) use them only that way.

> 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

I don't follow that argument. Why do we invalidate graphs, if we talk
about triple terms only? I do most of my basic RDF modeling without
graphs, and use graphs later in the game in an application-centric way.
Which means based on what I try to do with the data, graphs might be
used in different ways.

Is there anything that *breaks* graphs for eternity if we define triple
terms the way we talk about so far?

> 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

By doing triple terms we don't invalidate the need of having
sets/graphs/whatever we call it later annotations/terms as well. Again,
YMMV but I think in the real world we can easily come up with good
arguments for having both types at some point in time.

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

This is an interesting argument because you just claimed above that "we
would thereby invalidate a good part of the installed base of named
graph", which I don't see why this would be the case.

Again, our charter right now is about triples, not graphs. And I think
that no one in this group has an interest to call them "ripe for
deprecation". Defining triple terms and declaring victory for the
charter does not say that we never talk about quads anymore.

> Why are the problems that Peter laid out a problem for the semantic 
> web? 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.

I would also like to see some pragmatism on your part. You seem to work
a lot with graphs in your practice, but that doesn't mean that graphs
are equally relevant for everyone else.

To be clear: This WG cannot (and will not) break graphs. But it might
decide that graphs/quads are out of scope right now.

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

Again, YMMV. "what's actually needed" might be ambiguous because we, as
a group, have different problems.

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

Your comments have raised some critical questions that undoubtedly
deserve careful consideration. However, I feel compelled to address the
tone and implications of your remarks. It is important to remember that
this working group includes diverse perspectives and expertise. Each
member brings valuable insight and experience to our discussions.

While questioning and challenging ideas is an important part of our
process, insinuating that the group as a whole lacks understanding or is
blindly following a predetermined path undermines the collective efforts
we have all invested in. The reference to 'Don't Look Up' represents a
scenario of willful ignorance that I believe does not accurately reflect
the careful work and extensive discussions we have had over the past year.

Our goal is to develop standards that are not only technically sound,
but also practical and universally applicable. This requires a balance
between idealism and pragmatism, recognizing that no single solution can
perfectly solve all the complex problems we face.

I would encourage us to continue our discussions with an emphasis on
constructive criticism and mutual respect. Only through such shared
engagement can we create standards that truly reflect the collective
wisdom and needs of the broader community.

(This is a ChatGPT rewrite of my initial take on that paragraph, which
was a lot less... diplomatic.)

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

Again hard "don't look up" feelings here, not good Thomas. You are
welcome to share your concerns so we can work on them. You are not
welcome to dismiss other opinions the way you did in this last two
paragraphs.

> 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

Recognizing that people use graphs differently is not a "trauma".

> 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 always found it interesting to see how people use RDF. It took me some
time to even care about quads. It took me a long time until I had a real
use-case for reasoning. It took me a long time to adore rule languages
like Notation3 (thanks Dörthe!), and it took me even longer to have a
use case for triple terms. When Ora and Olaf approached me to be
co-chair I told them I'm not a good fit, as I don't really see the need
for it. They said that's exactly what we are looking for. Now I do see
more and more use-cases because I start to understand when it's useful
and what could be done with it. When the group started talking about
quads, I thought that might be useful as well.

But the emphasis is on "might be useful". If you don't see a point for
triple terms, don't use it. All you have to make sure is that we don't
make quad terms impossible by design. And I think most in this group
would be with you on that one. Once we "declare victory" on triple
terms, people like you can push the work further to quad terms, or
whatever will make sense to do at this point.

But please get away from the idea that the only sane use-case is yours
and everyone else is an idiot. Because that's the vibe I get right now.

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

To quote another movie: "Stupid is as stupid does".

regards

Adrian

-- 
Adrian Gschwend
CEO Zazuko GmbH, Biel, Switzerland

Phone +41 32 510 60 31
Email adrian.gschwend@zazuko.com

Received on Thursday, 30 November 2023 07:28:50 UTC