Skip to content

Suggestions from January review on §3.4 #198

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 5 commits into
base: main
Choose a base branch
from
Open

Suggestions from January review on §3.4 #198

Changes from 4 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
466cd55
grammar
pchampin Apr 23, 2025
8e1d1a9
consistency
pchampin Apr 23, 2025
5680be1
elements -> component elements
pchampin Apr 23, 2025
00f04c8
link to definition of 'inconsistency'
pchampin Apr 23, 2025
4d71ebc
Update spec/index.html
pchampin Apr 24, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions spec/index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -791,7 +791,7 @@ <h3>Literals</h3>
<p>Literals are used for values such as strings, numbers, and dates.</p>

<p>A <dfn data-local-lt="RDF literal">literal</dfn> in an <a>RDF graph</a> consists of
two, three, or four elements, as follow:</p>
two, three, or four component elements, as follows:</p>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a suggestion ("component elements" sounds a bit weird to me):

Suggested change
two, three, or four component elements, as follows:</p>
two, three, or four components, as follows:</p>

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@afs suggested "component elements", so that's what I wrote.
"component" works for me. @afs? @gkellogg?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Small tweak.

      two, three, or four components, as follow:</p>

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@TallTed the change from "as follow" to "as follows" was suggested by @bobdc, and makes sense to me because

  • everywhere else, we use "as follows"
  • my understanding, confirmed by a quick web search, is that "as follows" is grammatically correct, while "as follow" is not

Any argument in the defense of "as follow"?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are differing opinions on this bit of grammar. To my ear, follow sounds better after a plural antecedent. I think the best solution would be to change follow(s) to below, for which there is no belows.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"components" is also used as "The three components (s, p, o) of an RDF triple. "component element" is an attempt to distinguish the usage at this point then continue using "element" in the rest of the next. It leaves "element" in the rest of the section alone.

If its one word "component" here the rest of the section needs updating as well. "if the third element is present" etc.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for mentioning the rationale for this change @afs ! Yet, I would still prefer to use "components". "component element" sounds repetitive and clunky.

If its one word "component" here the rest of the section needs updating as well. "if the third element is present" etc.

There are three places in the whole document where the word "element" is used in the given context:

  1. Right after the four bullet points of the definition of "literal". Here it says: "[..] if the third element is present and the fourth element is not present. [..] if both the third element and fourth elements are present."
    --> I propose to replace these mentions of "element" by the actual names of the elements: "[..] if the language tag is present and the base direction is not present. [..] if both the language tag and the base direction are present."
  2. In the abstract, where it says: "RDF 1.2 also introduces directional language-tagged strings, which contain a base direction element that [..]"
    --> I propose to replace this by: ".. contain a base direction component .."
  3. In the change log (4-th bullet point), where it says: "Added the base direction element as part of [..]"
    --> Also for this one, I propose to replace it by: ".. the base direction component .."

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"component" is OK with those changes.


<ol>
<li>A <dfn>lexical form</dfn>, being an <a data-lt="string">RDF string</a>.
Expand All @@ -805,7 +805,7 @@ <h3>Literals</h3>
language tag MUST be well-formed according to
<a data-cite="bcp47#section-2.2.9">section 2.2.9</a>
of [[!BCP47]],
and MUST be treated accordingly, that is, in a case insensitive manner.
and MUST be treated accordingly, that is, in a case-insensitive manner.
Two [[!BCP47]]-complying strings that differ only by case represent the same [=language tag=].</li>
<li>If and only if the <a>datatype IRI</a> is
<code>http://www.w3.org/1999/02/22-rdf-syntax-ns#dirLangString</code>,
Expand Down Expand Up @@ -901,7 +901,7 @@ <h2>Literal value</h2>
<a>lexical form</a>.</li>
<li>Otherwise, the literal is <dfn data-lt-no-plural>ill-typed</dfn> and no literal value can be
associated with the literal. Such a case produces a semantic
inconsistency, but it is not <em>syntactically</em> ill-formed.
[=inconsistency=], but it is not <em>syntactically</em> ill-formed.
Implementations SHOULD accept [=ill-typed=] literals and produce RDF
graphs from them. Implementations MAY produce warnings when
encountering [=ill-typed=] literals.</li>
Expand Down
Loading