- From: Pierre-Antoine Champin <pierre-antoine@w3.org>
- Date: Fri, 17 Jan 2025 15:53:25 +0100
- To: RDF-star WG <public-rdf-star-wg@w3.org>
- Message-ID: <14178fc5-eb13-4693-8ee9-2aaf59abc2e8@w3.org>
Below are a number of non-normative changes that I think would improve
RDF-Concepts, but can be done after we decide to transition to CR.
o Abstract <https://www.w3.org/TR/rdf12-concepts/#abstract>
+ bullet "RDF graphs": the list of elements should mention
triple terms
+ paragraph after list: should maybe start with "Compared to
RDF 1.1, "
+ last paragraph: replace "RDF 1.2 Concepts" with "This
document" (or, at least, full title of the document, and
make it clear it is a (self-)reference)
o SOTD <https://www.w3.org/TR/rdf12-concepts/#sotd>
+ refers to RDF 1.1 Test Cases → I know we don't have an RDF
1.2 Test Cases yet, but that's weird (there is an editor's
note about it)
o Set of Documents <https://www.w3.org/TR/rdf12-concepts/#related>
+ the order should be revised ?
(this is supposed to be othographic, but is not quite
"What's new" comes first, and SPARQL is /not/ orthographic)
# group concrete syntaxes together
# put triple-based syntax before quad-based syntaxes?
o 1.2 <https://www.w3.org/TR/rdf12-concepts/#resources-and-statements>
+ 2nd paragraph: rephrase the 1st sentence to
"Asserting an RDF triple in a graph means that, according to
the author of this graph, some relationship ..."
o 1.3 <https://www.w3.org/TR/rdf12-concepts/#referents>
+ last pagraphah: "Linked Data Design Issue" → "Linked Data"
o 1.4 <https://www.w3.org/TR/rdf12-concepts/#vocabularies>
+ table: add to the caption "used in this specification"
(they are not just examples, they are also a reference, at
least for rdf: and xsd:)
+ "Note however that these abbreviations are /not/ valid IRIs,"
→ syntactically, they kind of are (modulo the fact that the
prefix may not be a registered IRI scheme... depends on how
you define "valid").
I would add a parenthesis that says ("(or only coincidentally)")
o 1.5
<https://www.w3.org/TR/rdf12-concepts/#section-triple-terms-reification>
+ 2nd paragraph, is clumsy, esp 1st sentence. Suggest to
rephrase:
"The presence of a triple term (as the object of another RDF
triple) in a graph does not constitute an RDF statement.
This allows statements to be made about other statements
that may not be asserted withing an RDF graph, or even about
statements that may be contradictory. It is possible,
however, to have the same triple (same subject, predicate
and object) used both as a triple term and an asserted
triple in the same graph."
o 1.6 <https://www.w3.org/TR/rdf12-concepts/#change-over-time>
+ give an example of temporal vocabularies? owl-time?
schema:Event?
o 1.8 <https://www.w3.org/TR/rdf12-concepts/#entailment>
+ should "logical expression" really be a definition?
+ shouldn't "entailment", "equivalence" and "inconsistency"
refer to RDF-SEMANTICS rather than being redefined here?
o 3.2 <https://www.w3.org/TR/rdf12-concepts/#section-IRIs>
+ I remember why "absolute" was replaced with "resolved", but
I guess that this will be mysterious to other readers.
Suggest to rephrase:
"IRIs in the RDF abstract syntax MAY NOT be relative
references, and MUST be resolved per [RFC3986]. They MAY
contain a fragment identifier."
o 3.3 <https://www.w3.org/TR/rdf12-concepts/#section-Graph-Literal>
+ lexical form: why not simply state that it is an RDF string ?
+ refactor bullets 3 and 4 of the definition of literals:
bullet 3 should be language tag (with 2 possible datatypes);
bullet 4 should be base direction
+ base direction: should it be defined to be an RDF string?
the "lowercase" constraint (present later on) should be in
the definition
+ definition of (directional)? language-tagged string should
be in terms of their datatype rather than which components
are present
+ literal value: "by an RDF implementation" should be replaced
with "by the RDF implementation" (twice)
+ link "inconsistency" to the definition in RDF-Semantics
o 3.4 <https://www.w3.org/TR/rdf12-concepts/#section-blank-nodes>
+ " Implementations that handle blank node identifiers in
concrete syntaxes need to be careful not to create the same
blank node from multiple occurrences of the same blank node
identifier except in situations where this is supported by
the syntax."
→ I had to read this sentence twice to understand what it meant;
Propose rephrasing:
"Implementations that handle blank node identifiers in
concrete syntaxes need to be careful not to create the same
blank node when the same blank node identifier is
encountered in different contexts, unless those contexts
explicitly have the same scope for blank node identifiers."
o 3.5 <https://www.w3.org/TR/rdf12-concepts/#section-triple-terms>
+ I would prefer if the definitions of subject, predicate and
object where still in 3.1 (RDF Triple), and if 3.5 referred
to these definition
o 3.6 <https://www.w3.org/TR/rdf12-concepts/#section-text-direction>
+ is the only non-normative sub-section of Sec 3, and is
disconnected from the rest... It should be somewhere else,
maybe as a subsection of 3.3 Literals.
+ 1sr paragraph, last sentence: add "in the general case" at
the end
+ 2nd paragraph: explain in parenthesis that |he| is the
language code for hebrew
+ use quotation marks around the hebrew text that includes "W3C"
+ and maybe include a translation?
o 5 <https://www.w3.org/TR/rdf12-concepts/#section-Datatypes>
+ lexical-to-value mapping: I would rather define it as a
function, and then add that it can be seen as a set of pairs...
+ the note about rdf:langString and rdf:dirLangString should
be after the example about booleans
+ example about xsd:boolean: "the literals that can be
defined" → "the *well formed* literals that can be defined"
o 5.1 <https://www.w3.org/TR/rdf12-concepts/#xsd-datatypes>
+ get the paragraph about xsd:float and xsd:double and the
note about the same datatypes closer to each other
o Appendix D
<https://www.w3.org/TR/rdf12-concepts/#internationalization>
+ note explicitly that rdf:dirLangString should be preferred
to the i18n namespace? (the former is normative, the latter
is not)
Received on Friday, 17 January 2025 14:53:27 UTC