Re: [rdf12-concepts] Feedback W3C Candidate Recommendation Snapshot (07 April 2026)

Hi Michael,

thanks for this review.

I made a PR (https://github.com/w3c/rdf-concepts/pull/279) implementing 
some of your suggestions.

Responses below are mine only, not an official WG response.

On 12/05/2026 21:41, Michael Schneider wrote:
> Dear RDF & SPARQL Working Group members,
>
> following my last week's request for an extension of the feedback 
> period, let me first thank you for giving me the opportunity to still 
> send my feedback. Here I am starting with the RDF 1.2 Concepts and 
> Abstract Data Model. I plan to send another feedback for the RDF 1.2 
> Semantics later this week.
>
> My general impression of the RDF 1.2 Concepts and Abstract Data Model 
> is that it is a good document. For someone familiar with previous 
> versions of RDF, the document is a pretty straight-forward read, as it 
> is mainly an incremental update of the RDF 1.1 Concepts specification. 
> I appreciate that RDF 1.2 focuses on introducing only a small number 
> of significant changes, with the new triple terms as probably the 
> biggest change, followed by base directions and versioning of RDF 
> data, and finally some corrections, such as specifying 
> case-insensitivity of language tags, and editorial improvements, such 
> as moving some material to the appendix, including the rdf:XMLLiteral 
> datatype and the discussion about blank node Skolemization.
>
> The following is a list of specific findings and suggestions:
>
> * §1, example list of serialization syntaxes: I suggest to also 
> mention RDF/XML, since it was the primary syntax in older versions of 
> RDF and is still important for storing RDF data and for data exchange 
> between tools.
The importance of RDF/XML is an eternal topic of discussion in the WG :-)
Some communities have long migrated to the Turtle family of syntaxes, 
others are still using RDF/XML...

I did include this change in my PR, we'll see how the rest of the group 
reacts.

> * §1.1, spelling error: "The abstract data model ... while preserving 
> the same stucture": should be "structure".
This was fixed in the meantime.
>
> * §1.9, first table: The "object" row lists "triple" as a node kind. 
> Shouldn't it be "triple term" instead, or is this considered 
> interchangeable terminology?

"triple" is a /kind/ of things in the data model; "triple term" is a 
/role/ that a triple can play in a graph (the other role being "asserted 
triple", and they are not exclusive).

As the list in this row is a list of *kinds*, I think it is appropriate 
to keep "triple" here.

>
> * §1.9, second table: An RDF dataset is defined as "a pair" of a 
> default graph and a set of named graphs. In several other places in 
> the document, in particular at the beginning of §4 about "RDF 
> Datasets", an RDF dataset is said to be "a collection" of RDF graphs.
>  I suggest to stay consistent and always call an RDF dataset "a 
> collection" of graphs. 

Tables in §1.9 use common mathematical notions (set, 3-tuple, pair) to 
describe the abstract syntax. "collection" would not fit in there.

On the other hand, the rest of the spec, including normative text, uses 
mostly English prose, where some terms are used to provide useful 
intuitions, even if they don't contribute formally to the definition.

More specifically: the normative definition of "dataset" in §4 does 
indeed use the term "collectionj", but continues with a list of two 
items, which constitute the "pair" referred to in §1.9. I don't see 
those as contradictory.

> * §2.2, second paragraph: "An implementation MAY determine string 
> equality by comparing the code units of two strings that use the same 
> Unicode character encoding (UTF-8 or UTF-16) without decoding the 
> string into a Unicode code point sequence." I believe it is evident 
> that, in order to be conformant, an implementation may internally 
> apply any comparison approach, as long as it leads to the same result 
> that one would get from comparing the Unicode code point sequences. I 
> therefore suggest to remove this sentence as redundant, or at least 
> not to state it within a normative context.
Good point; I moved this text into a note paragraph (non normative).
> * §3.4, item 4 about base directions: The section does not state 
> whether base direction strings (e.g. "ltr") are case sensitive or 
> insensitive, whereas for all other components of a literal there 
> exists some statement about case, e.g. that language tags are to be 
> compared in a case-insensitive way. I think this should be clarified 
> for base direction strings as well.

The general idea, IMO, was that `ltr` and `rtl` in this context are 
abstract values, not strings (concrete syntaxes are responsible for 
specifying how those abstract values are represented). But agreed, this 
subtlety may easily be lost. I added a clarifying sentence.

   best

>
>
> Best regards
> Michael
>