Suggestions from January review on §1.4

[pchampin]

---

Preview | Diff

[hartig]

Suggested change

	<p>In some serialization formats it is common
	to some [=namespace IRIs=] to arbitrary [=namespace prefixes=],
	and to abbreviate <a>IRIs</a> that start with one of those <a>namespace IRIs</a> by using the corresponding <a>namespace prefix</a>,
	in order to assist readability.
	<p>In some serialization formats it is common
	to abbreviate <a>IRIs</a> that start with one of those <a>namespace IRIs</a> by using the corresponding <a>namespace prefix</a>,
	in order to assist readability.

[pchampin]

a verb ("associate") was missing from my text, sorry.
Hopefully, this is now clearer.

The point was to say explicitly that the prefix-IRI association was specified in the syntax, not provided by some external convention.
(the previous wording was ambiguous in that respect)

[TallTed]

Suggested change

	Note however that these abbreviations are <em>not</em> valid IRIs (or only coincidentally),
	Note, however, that these abbreviations are <em>not</em> designed to be valid IRIs,

[pchampin]

I'm not sure about this... I feel that it alters the message. @afs @gkellogg @hartig WDYT?

[hartig]

I agree that Ted's proposal has a slightly different touch. Users who create (/design) such abbreviations may indeed assume that they are creating valid IRIs. The purpose of the sentence is to emphasize that such an assumption is wrong.

Having said that, the "(or only coincidentally)" part that you added is also not ideal, because it is not clear what exactly that means and why that is mentioned.

How's about changing this whole part of the paragraph (including all the sentences that follow the one in question) as follows?

Note that such abbreviations are <em>not</em> meant to be processed directly as IRIs and
must not be used in syntactic contexts where IRIs are expected.
Instead, they are merely a syntactic convenience for abbreviating IRIs;
for processing, the actual IRIs are reconstructed by replacing the namespace prefixes
with the corresponding namespace IRIs.
In this sense, namespace IRIs and namespace prefixes are not a formal part of the RDF data model.

[pchampin]

TL/DR: I like very much your proposal @hartig

FTR, the reason I added this parenthetical was that the statement is, arguably, inaccurate: rdf:type or xsd:string satisfy the IRI grammar! Whether they are valid IRIs may be a slightly different issue, if we consider that an IRI is valid only if it uses a registered scheme and complies with the additional constraints of that scheme... But I don't know of any implementation that is so strict...

Anyway, your wording is IMO much better. Can you push a commit to this branch, please?

[gkellogg]

I generally like this, but the bit on prefixed IRIs can use some improvement

[afs]

such as? Is this hinting at RDF/XML and qnames?

[TallTed]

Suggested change

	and must not be used in contexts where only non-prefixed IRIs are expected.
	and must not be used in contexts where only IRIs are expected.

[afs]

Prefixed names are not IRIs. They could be "expanded to give IRIs during parsing".

Suggested change

	Note, however, that these "prefixed name" abbreviations are generally <em>not</em> valid IRIs,
	Note, however, that these "prefixed name" abbreviations are <em>not</em> valid IRIs,

I am not sure what the "valid" means here.

[TallTed]

Suggested change

	Note, however, that these "prefixed name" abbreviations are generally <em>not</em> valid IRIs,
	Note, however, that these "prefixed name" abbreviations are generally <em>not</em> IRIs,