Skip to content

Suggestions from January review on §1.4 #194

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.

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 9 commits into
base: main
Choose a base branch
from

Conversation

pchampin
Copy link
Contributor

@pchampin pchampin commented Apr 23, 2025

@pchampin pchampin added the spec:enhancement Change to enhance the spec without affecting conformance (class 2) –see also spec:editorial label Apr 23, 2025
@pchampin pchampin requested review from gkellogg, afs and hartig April 23, 2025 23:46
Copy link
Member

@gkellogg gkellogg left a comment

Choose a reason for hiding this comment

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

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

@pfps
Copy link
Contributor

pfps commented May 1, 2025

Isn't this just editorial.

pchampin and others added 6 commits July 4, 2025 16:16
Bob DuCharme's 2nd comment
https://www.w3.org/mid/33e6564c-0dc3-4ca6-8304-4e47da867bf6@snee.com

not exactly Bob's suggestion,
but I think it addresses the core of the issue.
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
re-reading this, I realized it could be surprising:
the predicate position of a triple is a "context where IRIs are expected",
and so this text could read as "don't use abbreviated forms in the predicate position",
which is of course not how it was intended.
@pchampin pchampin force-pushed the 2025-01-reviews-s1.4 branch from 5f5790b to 9ee0284 Compare July 4, 2025 14:16
... with some slight adaptations

*: #194 (comment)
RDF data model. They are merely a syntactic convenience for
abbreviating IRIs.</p>
Note however 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.
Copy link
Member

Choose a reason for hiding this comment

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

I've lost track of normativity. Should this use MUST instead of must?

Suggested change
and must not be used in syntactic contexts where IRIs are expected.
and must not be used in syntactic contexts where IRIs are expected.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No. This is in §1.4; §1 (Introduction) as a whole is informative.

Copy link
Member

Choose a reason for hiding this comment

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

Does this work?

Suggested change
and must not be used in syntactic contexts where IRIs are expected.
and are not to be used in syntactic contexts where IRIs are expected.

Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
@pchampin pchampin requested a review from TallTed July 8, 2025 10:45
Co-authored-by: Andy Seaborne <andy@apache.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
spec:enhancement Change to enhance the spec without affecting conformance (class 2) –see also spec:editorial
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants