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

Hi Pierre-Antoine,

thanks a lot for your answer!

I think I now understand the intended distinction between "triple" and 
"triple term" in the document and I am fine with it (and will try to use 
it that way from now on). I am also fine with going on with the term 
"pair" for RDF datasets in the table; after all the meaning is clear in 
that way. And I leave it fully to the WG to decide whether, and in which 
order, RDF/XML will be added as an example serialization syntax.

Next I will send my review for the RDF 1.2 Semantics (hopefully I find 
the time tomorrow evening).

All the best
Michael

On 22/05/2026 14:16, Pierre-Antoine Champin wrote:
> 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
>>

Received on Monday, 25 May 2026 18:58:30 UTC