Re: victory is not declared, but won

Hi Adrian,


sorry if I left the impression that I’m calling everyone an idiot! TBH, I was padding myself on the shoulder a bit last night for having been able to put my concerns so nicely… Well, I guess it comes with the reputation if I’m understood the way you understood me, and of that I’m certainly to blame myself.


Some comments:

> On 30. Nov 2023, at 08:28, Adrian Gschwend <adrian.gschwend@zazuko.com> wrote:
> 
> 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.

Comes with the territory...

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

I interpret the charter as: "standardize an easy way to annotate triples".

RDF-star was, and to some degree still is, perceived as being simple, so it was the natural candidate in Berlin, and the CG held on to that view although it made RDF-star much more complicated, and still didn’t account for all the complications inherent to the design from the start. 

My interperetation of the charter therefore is: let’s try to fulfill the request as best as we can, but let’s not feel bound too much by what the charter thought the best way forward would be. In the CG I was often pacified with the prospect that it’s only a CG and a WG would have to discuss again and then decide. I’m taking the freedom to interpret that in a rather extensive way, but still well within the limits of our task. I didn’t formulate the charter as narrow as it was formulated, and I think that was a mistake, but still the charter leaves us that freedom of interpretation. 

Now, graphs: I know they aren’t mentioned in the charter, but they exist and I claim we could fulfill the charter by using them. Now, wouldn’t that be a very good outcome for everyone? Implementors wouldn’t have to implement a new term type, users would have less trouble authoring and querying different types of terms, etc.

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

I wasn’t there, so can’t comment, but I would like to have a more solid account because I have the feeling that a lot of not well thought through assumptions rule the place. For example all the completely nuts applications out there that undoubtly exist: would *one* of them actually *break* if we said "if you call graph by its name using this new predicate, then you thereby declare that you call it as a graph and not as anything else you nuthead might use the name to refer to in other contexts". I’d really like to see that example, because I assume it would also break the open world assumption that we can call anything anything. Really, I think there is a lot of hysteria going on w.r.t. named graphs. The RDF 1.1 WG couldn’t settle on *one* definition and that’s fine. But it’s not fine to conclude that we shouldn’t touch them anymore (and it’s also not what the RDF 1.1 WG concluded in its note).

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

Yeah, well, that is certainly not in the charter and I don’t claim that it should be the aim of this WG as an aim on itself, but if it comes as a side product and for free: shouldn’t we just all be happy and take it?
 
> 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.

Well, as far as I can see, we (the WG, also before I joined) didn’t properly discuss it, and I have some hopes.

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

A good design allows to model 
1) many things 
2) easily 
3) with few primitives. 
There is no excuse for a proliferation of primitives. It may be necessary, yes, but it’s not just "hey the world is complicated anyway, let’s just add one more device and people will figure it out". That’s not design, that’s bricolage and it pollutes the space.

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

Well, the primer would be good to have before we standardize, as a way to check how the design actually plays out in practice. But use cases are a way there. In my opinion, RDF-star doesn’t fare too good.

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

And would you find it too hard to *also* use them for annotation purposes?

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

No, I don’t think so. But we might lay the ground for a lot of confusion and unsound triples.

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

Yes, I think our milage differs. But that’s okay. However, still the question is: would it hurt if we could do everything with one type instead of two?

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

Well, if you say "I use named graphs for application specific purposes, late in the game" that’s totally fine. But other people use them already to annotate and qualify statements, and not just for out-of-band, application specific purposes. Don’t you invalidate those practices - in-voluntarily, but in effect - if you assume that those purposes could (and maybe better should) use something RDF-star like instead of named graphs? 

I think we have to try - and coud indeed achieve - to use named graphs in both ways: if you don’t care for sound semantics because graph semantics are embedded in your application - fine! If you add a little semantics to your poperties to use them in ways more compatible with RDF model-theory - good for you! I really believe that we can achieve both,if we respect each side and don’t try to decide the conflict one way or the other. 

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

Well, as i said above, this wasn’t my intention, but I know I did not get the reputation without reason. However, I *feel* like that those questions of mine have been ignored for years and I’m still trying to find a tone that doesn’t hurt but also doesn’t get ignored any longer.
 
>> 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.

Well, sorry, but there just isn’t a proper will to get to the ground of these problems. I watched Niklas voice the exact same concerns as I did, with the utmost politeness. Where did that go? I assume he is just as frustrated as I am. No, the problem goes a bit deeper than just my ways of expressing myself.

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

That’s not what I mean. Nobody wants to discuss the issue anymore, although the RDF 1.1 WG was even pretty close to device a small vocabulary to define their semantics on demand - not for everyone, but according to the needs of ones' applications. And I’m not asking for more. The semantics that the CG proposes for RDF-star is pretty hardcore constraining. Why is a much more liberal semantics based on named graph syntax a problem?

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

Well, sorry again, but that’s not my intention (even if I do indeed think it from time to time ;-) Oh, I shouldn’t have said that... Believe me: I’m a rather amicable (although dull) guy in private, and I thoroughly believe that you all are very amicable (and not dull) persons - all of you, even those that I curse regularly about in private. Yes, I should take it all less to heart - I’m trying. But I’m also trying to make sure that the WG does its work thoroughly and that everyone reflects on their assumptions, even regarding named graphs.

Best,
Thomas

>> 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 13:46:18 UTC