Review of RDF 1.2 Concepts and Abstract Syntax

Dear all, here my review. Best, Thomas


Abstract:

"RDF 1.2 introduces triple terms as another kind of RDF term which can be used as the object of another triple."

RDF Concepts diverges from the abstract grammer in the RDF Semantics "liberal baseline". Especially: RDF Concepts allows triple terms only in object posi tion, not also in subject position.
That seems wrong. Some concrete syntaxes may - depending on the outcome of still ongoing discussions - restrict triple terms to the object position, but the abstract grammer as defined by RDF Semantics does not, and why should the abstract syntax as defined in RDF Concepts?

The same applies to a few more mentions of triple terms in object position in following sections of the document, e.g. section 1.5 Triple Terms and Reification.



Introduction:

"The Resource Description Framework (RDF) is a framework for representing information in the Web."

Shouldn’t it be "on the Web"?



1.2 Resources and Statements

The definition of a triple term should precede the second paragraph about triples and statements. Same for blank nodes. I.e. triples and statements hould be defined last, after all their possible constituents are defined.

Niklas’ proposal for defining a triple term:
"A triple term denotes a proposition. This is a logical, abstract resource, identified by its constituent predicate property and subject and object resources. It is simply true in the universe if a corresponding triple is asserted. In this way, an RDF statement makes its corresponding, abstract proposition true."

Rephrase the last sentence to: "Asserting an RDF triple makes the proposition denoted by its corresponding triple term true."


1.3 The Referent of an IRI

"Perhaps the most important characteristic of IRIs in web architecture is that they can be dereferenced, and hence serve as starting points for interactions with a remote server."

Replace "a remote server" by something less technical, e.g. "an information provider".


1.5 Triple Terms and Reification

IMO it is very important to be clear about the limitations of triple terms and how to correctly deal with those. This section is a good start but needs more discussion and refinement.

I agree with Enrico that it should say that "A triple term is NEVER asserted". That makes the gap between triple terms and triples very clear in a very succinct way.

The visualization should go a slightly different route: a reification should alwaays be attached to an unasserted triple term (visualized eg by a triple on gray background). If the same triple is asserted in the graph (as Figure 3 aims to illustrate) that asserted triple should be visualized seperately and in addition to the unasserted (gray) triple term. Only in that way is it visually clear that the connection between triple term and triple is merely incidental.


2.0 Conformance

"Classic conformance only supports graphs or datasets with triples that do not contain triple terms."

The WG voted a year ago to call the two variants "Basic" and "Full". "Classic" has to be changed to "Basic". 

I disagree with Andy’s comment #6 that syntaxes should not be named because thay are already named in section 1.9. the latter section refers to all RDF syntaxes (and lists as examples also RDFa and JSON-LD) whereas section 2. conformance refers to syntaxes that support triple terms.


3. RDF Graphs

"An RDF graph is a set of RDF triples.
An RDF triple is said to be asserted in an RDF graph if it is an element of the RDF graph."

I would like a definition of "statement" as opposed to "triple" and "stating" as opposed to "asserting in a graph" to be added to what is said in the second sentence. There seem to be subtle differences of which I myself am not sure about, so some clarification might be useful.

By consequence, I wonder if the second sentence and the proposed additions are not better moved to the following section 3.1 "Triples".

+1 to Andy’s suggestion to rename this to "RDF Graphs Data Model". Or even section "3. RDF Data Model", section "3.1 Graphs", etc


3.3 Literals

"Implementations SHOULD accept ill-typed literals and produce RDF graphs from them. Implementations MAY produce warnings when encountering ill-typed literals."

SHOULD should remain MUST.


3.5 Triple Terms

The definition of a triple term at the start of this section sounds strange to me, almost as if the round braces would provide the only disambiguation between a triple and a triple term.

Niklas’ proposal of adding the sentence "The only difference between a triple and a triple term is that a triple can be a member of a graph, and a triple term can be used as the object of another triple or triple term." doesn’t seem to help much but may be understood as contradicting the descriptions given in preceding sections (which do indeed name differences, namely that between a propsition and an asserted triple. 

IMO readability and expressiveness of the section would be much improved if the first note became the introduction of this section (probably slightly re-worded).



3.7 Replacing Blank Nodes with IRIs

This section should should follow section 3.4 Blank Nodes, and therefore become section 3.5, etc 

W.r.t. to Andy’s question if this section should be made informative: IMO skolemization is important enough to let this be normative. And there is no need to test "not appreciably change" because the spec maintains this as a fact, not a (testable) condition.

W.r.t. Enrico’s comment that the spec is wrong about this (i.e. that skolemization does indeed have the potential to change the meaning of a graph) - good point! but maybe another discussion? 


8. Triple Terms and Other Metamodelling Devices in RDF

Obviously the unstar mapping is still missing (and a respective PR is blocked). 

Also missing is a discussion of the relationship of triple terms with RDF 1.0/1.1 reification and with named graphs.

Received on Thursday, 16 January 2025 15:13:22 UTC