Some improved language, punctuation, and markup in rdf-semantics

[TallTed]

---

Preview | Diff

[doerthe]

"standardize apart" is a fixed term (Logic Programming) and I would therefore not change that

[TallTed]

How about this?

Suggested change

	it may be necessary to <dfn class="no-export lint-ignore">standardize</dfn> the blank node identifiers
	it may be necessary to <dfn class="no-export lint-ignore">standardize apart</dfn> the blank node identifiers

[afs]

RDF Semantics is not defining "standardize apart".

Just remove the dfn markup to leave the text:

"it may be necessary to standardize apart the blank node identifiers"

[TallTed]

I think @afs advises well (hence part of this text suggestion), but based on what I found in documentation Google showed me when I asked "what does "Standardize apart" mean?", I've reordered some words, which I think makes the sentence more readable. (We might consider adding an external link to some Logic Programming text which goes further into this subject, which I believe we have not made a prerequisite for readers of our specifications.)

Suggested change

	it may be necessary to <dfn class="no-export lint-ignore">standardize</dfn> the blank node identifiers
	it may be necessary to standardize the blank node identifiers apart,

[afs]

The operation name is "standardize apart" as @doerthe notes.
The google hits has it as the two words together each time.

For better or worse, the RDF Semantics introduction starts as the document goes on:
"This document defines a model-theoretic semantics ..."

(and why I haven't done a technical review of RDF Semantics.)

[TallTed]

Any objection to this, which makes plain that it's a complex verb? I have spent some fruitless time searching for a page that clearly and simply defines this "operation", but all pages I've found treat it as preexisting knowledge, which is clearly a problematic assumption, as it was not preexisting for me. I would much rather entirely remove this term of art, and say the same thing with other words.

Suggested change

	it may be necessary to <dfn class="no-export lint-ignore">standardize</dfn> the blank node identifiers
	it may be necessary to "standardize apart" the blank node identifiers

[afs]

I think it is OK but (1) I am not an editor of this document (2) experts in the field may have a view.

[TallTed]

ping oh ye experts in the field (@doerthe @franconi @niklasl (are there other such experts among us?))! Please chime in on my latest suggested change?

[franconi]

ping oh ye experts in the field (@doerthe @franconi @niklasl (are there other such experts among us?))! Please chime in on my latest suggested change?

I think it is ok, as it uses the appropriate term.

[pfps]

I don't see any need to add m-dashes around Examples 1 and 2. In fact, my view is that they are a distraction.

Although I prefer Oxford commas there is no reason to change to them in one place unless this is the only place where there is a missing Oxford comma.

[TallTed]

I don't see any need to add m-dashes around Examples 1 and 2. In fact, my view is that they are a distraction.

They serve as a connector between the sentence fragments preceding and following the code blocks, and those code blocks. Their presence makes clear that there was no accidental omission of other punctuation (whether period, comma, or otherwise) or text. It is far more distracting to try to figure out what punctuation or text might have been left out, than it is to read the flow with the em-dashes.

Although I prefer Oxford commas there is no reason to change to them in one place unless this is the only place where there is a missing Oxford comma.

So if there are 2 missing terminal commas, in a document which otherwise has them in all eligible positions, there's no reason to add them in those 2 locations? What if there are 3 missing? Why should one missing comma be added, but two or more missing commas be left that way?