putting the proposed semantics in perspective

[rat10]

This PR sets a decidedly different tone w.r.t. the achievements of the proposed semantics and also hints at some problems that (I fear) otherwise only seasoned semanticists would notice.

On a technical note: I created this pull request in main. A seperate branch would probably be more appropriate but I didn't dare as I'm quite clumsy with all things Git. Also: sorry about all the false positive diff's in the SPARQL section (and beyond, possibly). My editor (IntelliJ) kept adding them again and again...

---

Preview | Diff

[pchampin]

A problem with this PR is that it touches many parts of the documents (regardless of the false positive changes), for many different purposes (from fix typos in examples to adding whole sections).

It is really hard to discuss it as a whole, not to mention approve it.

I would recommend that you split it into targeted PRs that can be discussed agreed upon more easily.

[rat10]

A problem with this PR is that it touches many parts of the documents (regardless of the false positive changes), for many different purposes (from fix typos in examples to adding whole sections).

Correction of typos is limited to examples 33 (replacing clark with clarkKent or loisLane to bring the example in line with its established source) and 34 (correctingg the umlaut in Linköping). Sorry for the distraction but I couldn't resist. Apart from that there are no trivial changes. I didn't - willingly - change anything at all in the SPARQL sections.

It is really hard to discuss it as a whole, not to mention approve it.

I would recommend that you split it into targeted PRs that can be discussed agreed upon more easily.

I fear it has to be discussed as a whole. You can't discuss the tone and general direction of a text in a piece meal fashion. In some paragraphs I only changed a few words and it already changes the tone dramatically, no less than some whole paragraphs that I added. Working on this PR as a whole also is indispensable to avoid repetition and get the contexts right, especially with the intertwined topics of referential transparency/opacity and types/occurrences. Detailed discussions can be split into seperate issues later.

I would also be too clumsy with Git to do anything meaningful right now, and until tomorrow's call I have other tasks to attend to.

[afs]

This PR is opinionated and seeks to chip away at the document to render it useless.

I suggest that @rat10 writes a separate "minority opinion" document where he has full control over the tone and content without attribution to the other authors and contributors.

but requires extra effort when used to model common idioms like provenance annotations

This confuses provenance of what was said (i.e. the utterance) with provenance of claims (the disputable assertion).

As discussed before, a proposal that does not cover utterances is missing some use cases. Supporting the (arguable) majority and not the rest at all is weaker.

default referentially transparent semantics, switching to referential opacity on demand

As previously - in RDF, turning off isn't possible.

very unusual design decision

Unhelpful language.

[rat10]

This PR is opinionated and seeks to chip away at the document to render it useless.

Setting a different tone is not "chipping away" and it certainly doesn't render the document useless - not to mention the implication that this was my intention.

I suggest that @rat10 writes a separate "minority opinion" document where he has full control over the tone and content without attribution to the other authors and contributors.

but requires extra effort when used to model common idioms like provenance annotations

This confuses provenance of what was said (i.e. the utterance) with provenance of claims (the disputable assertion).

I missed the point, yes. That may be a valid point. I'll have to think about that more.

As discussed before, a proposal that does not cover utterances is missing some use cases. Supporting the (arguable) majority and not the rest at all is weaker.

Right, and I made that explicit: the proposed semantics has merits and it has downsides. The current draft fails to provide a balanced picture to people that are not well versed in the subtleties involved.

default referentially transparent semantics, switching to referential opacity on demand

As previously - in RDF, turning off isn't possible.

My proposal mentions that (twice I think), doesn't it?

very unusual design decision

Unhelpful language.

Introducing referential opacity in RDF is certainly unsual but you are welcome to propose a more fitting expression: I'm not a native speaker and subtleties may get lost on me. How about "surprising"? [EDIT nah, "surprising" possibly has a negative connotation. The point I want to make is that users have to be aware that behind the scenes things move very differently to what they are accustomed to, and that is not obvious from the syntax. People like me who like to skim examples and then think they 'got it' will get int trouble.]

[TallTed]

I think s/"surprising"/"possibly surprising"/ would remove most negative connotations, especially if that statement were followed by a number of "concern was addressed thus and not so because basis", and should help avoid the "skimmer's folly" you describe.