- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Wed, 15 Jan 2025 12:59:33 -0500
- To: RDF-star Working Group <public-rdf-star-wg@w3.org>
Review of https://w3c.github.io/rdf-concepts/spec/ W3C Editor's Draft 09 January 2025 Issue: I believe that the rdf:JSON datatype is not yet adequately defined to be an RDF datatype. If the datatype is not fixed then I believe that it must be removed. Suggested changes: [Editorial] Talk about triple terms in Section 1.2. [Editorial but important] Section 1.5 uses vocabulary that is only defined later and its beginning needs to be rewritten. Here is my suggestion: A triple term is an RDF term with the components of an RDF triple, subject, predicate, and object, which can be used as the object of another triple. The presence of a triple term in another triple does not imply that the relationship indicated by the predicate in the triple term holds between the resources denoted by the subject and object. If it is desired for this relationship to hold for a triple term in a graph then the graph must also contain a triple with the subject, predicate, and object. Triple terms allow statements to be made about statements that may or may not be asserted within an RDF graph. A triple term is normally used as the object of a triple with the predicate rdf:reifies; such a triple is then a reifying triple. The subject of that triple is called a reifier. Assertions on the triple term are made using the reifier. Concrete syntaxex may provide a special notation for specifying reifying triples. [Editorial but important] The diagrams for triple terms are hard to understand as they use a special notation for rdf:reifies triples. Why not just show these triples in the normal way? This graphical notation is not defined and appears nowhere else in the document. [Editorial but important] The definition of subject, predicate, and object of a triple has been moved to after the first normative use of subject and object and into the section about triple terms. This makes no sense and the defintion should be moved back into Section 3.1. The remaining wording in Section 3.5 should be adjusted to account for the moving. [Editorial but important] Make the wording of the definitions of langauge-tagged strings and directional language-tagged strings look more like each other. Make it clear that language tags for both are the same, including comparison. [Editorial] ", synactically," -> " syntactically" [Editorial?] Section 3.7 should be tagged as non-normative. [Normative] The definition of the value space for rdf:JSON is badly defined as it is based on ordered maps. If this problem is not fixed, rdf:JSON cannot be an RDF datatype. [Normative, because the parenthesized parts are not implied] "maps (mapping strings to values in the value space where the order of map entries is not significant), lists (of values in the value space)" -> "maps mapping strings to values in the value space where the order of map entries is not significant, lists of values in the value space" [Normative, because the parenthesized part is not implied] "literal values (true, false, and null)" -> "the literal values true, false, and null" [Normative, because the wording does not make sense] "A JSON literal name maps JSON ..." -> "The JSON literal names true, false, and null are mapped to true, false, and null, respectively." [Editoral] Maybe put the addition of triple terms as the first change?
Received on Wednesday, 15 January 2025 17:59:41 UTC