Review RDF 1.1 Semantics (ED 3rd June 2013)

Pat, Peter,


This is my review of RDF 1.1 Semantics. Sorry for sending this so late.
On the plus side, I'd say that overall, the presentation have been much 
improved, interpretations being independent from a vocabulary is a big 
bonus, making D-interpretations independent from the RDF vocabulary is 
also much better. Putting the rules in context with the corresponding 
entailment regime is also good.

Now, for the main criticism, I have two outstanding problems with the 
current version:
  1. D-entailment using a set rather than a mapping;
  2. Define entailment of a set as entailment of the union.


1. D-entailment
===============

Concerning 1, the implication of the new definition is that given a D, 
it not generally possible to know what are the valid D-entailments.

For instance, consider D = {http://example.com/dt}. What does the triple:

  <s> <p> "abc"^^<http://example.com/dt> .

D-entails? The specification does not say.
Moreover, because of the absence of a known mapping from IRIs to 
datatypes, there are a few ill-defined conditions:
For instance, in Section 9, the table "Semantic conditions for datatyped 
literals" says:

"""
For every other IRI aaa in D, and every literal "sss"^^aaa, 
IL("sss"^^aaa)=L2V(I(aaa))(sss)
"""

L2V is only defined for datatypes, whereas I(aaa) is not constrained to 
be a datatype. Even though it was constrained to be a datatype, this 
would not define the value of IL("sss"^^aaa), unless aaa is one of the 
normative XSD datatype IRIs.

In any case, no matter how you tweak the definitions, the application 
MUST have a mapping from the set of "recognised" datatype IRIs to some 
specific datatypes.

Later in Section 10, it says that "if D < E and S E-entails G then S 
D-entails G." Since no constraints are given on how to interpret 
"recognised" non-XSD datatype IRIs, it is possible that the same IRI in 
D-entailment is interpreted differently in E-entailment.

In Section 11, table "RDF semantic conditions:

"""
For every IRI aaa in D, <x,I(aaa)> is in IEXT(I(rdf:type)) if and only 
if x is in the value space of I(aaa)
"""

This is ill-defined because the value space of I(aaa) may not exist. 
Again, even if I(aaa) is constrained to be a datatype, how do we know 
what is its value space? Therefore, the condition cannot be verified in 
general.

Finally, the reasons why this change has been made are unclear. The 
working group was not chartered to do anything about that, the workshop 
in 2010 did not point at all to any problems with datatype maps, this 
Working Group did not discuss or complained about the D being a map when 
the change was made. No prior discussions were attempted before making 
the change.

Implementations that rely on custom datatypes are interpreting the 
custom datatype IRIs according to one specific, known datatype, 
therefore, they do have a datatype *map* implemented. There is zero 
motivation to make such a change.



2. using union
==============
This issue is different from the previous one because it does not make 
the definitions and propositions incorrect.

I see two problems with the new definition: first, it makes the notion 
of entailment in RDF different from the standard, universally accepted 
notion of entailment in logic. In general, no matter what semantics is 
considered entailment is defined as follows:

"""
A set S of formulas in the language entails a formula F in the same 
language if and only if all interpretations that satisfy all the 
formulas of S also satisfy F.
"""

That's what was in RDF 2004, that's what's in OWL, that's what's in any 
logic with a model-theory.

There are also inconvenient consequences for manipulation of RDF graphs:
how is it supposed to be implemented? Assume we have two representations 
of two graphs. How do you know what's the union of the two graphs? You 
do not have access to the bnodes, only to identifiers or locations in 
files or in memory. There is a rule of thumb saying "different 
documents, different bnodes". And what about RDF graphs in an in-memory 
model? What about two examples of RDF graphs in Turtle in a written 
article? They are in the same document, they certainly share bnodes, right?

Now if we take the simple case when the application is able to determine 
that the bnodes are disjoint, how can it perform a union? The answer is 
that it must *separate apart* the bnode identifiers. So, while in 2004 
there was a coherence between the way merge was defined and the way it 
has to be implemented, now there is a discreprency between the 
definition and the pratice.

Then, once the separation apart is made to produce a representation of 
the union, the created graph is, by definition of union, sharing bnodes 
with the two original graphs. But how can the overlap of bnodes be 
recognised in and out of the application? One would need 
meta-information about the relationship between the graphs. And how to 
represent and store that relationship?

Also, if one wants to keep two graphs that share bnodes separate (say, 
they are distinct graphs in the same TriG files). Then these graphs 
cannot be stored separately if one wants to retain equivalent inferences 
on the set of graphs. That is, if I have {G1,G2} such that G1 and G2 
share some bnodes, storing G1 apart would create a "copy" of G1 with 
disjoint bnodes. The new graph, H1, would be equivalent to G1, but the 
set {H1,G2} would not yield the same entailments as {G1,G2}.

Finally, the decision to replace merge with union was first put into the 
document without prior discussion with the Working Group, without 
evidence that it follows practices, without evidence that it solves 
known issues. The notion of merge was not identified as a subject of 
concern during the W3C workshopin 2010. Implementations do implement the 
RDF 2004 correctly.



Conclusion:
===========
More generally, any change like this is disturbing education. If this 
design is standardised at the end of the year, there will be a gap 
between what's in the standard and what has been written for years in 
tutorials, courses, research papers, and so on.

Considering that I see no added value compared to 2004 from both these 
changes, and having even identified flaws, I oppose publication of RDF 
1.1 Semnatics in such a state.

Note that the solution I propose is simple and simpler than what is 
proposed: to go back to the old design concerning entailment of a set of 
graphs and datatype map. My proposal is also less likely to trigger 
unsupportive comments in the Last Call phase. We cannot aford to spend 
more time in inventing new design.



Minor remarks:
==============
I think there are too many sections. Simple interpretations and simple 
entailment can be subsections of a common section. The same for 
D-interpretations and D-entailment.  Same for RDF interpretations and 
RDF entailment; same for RDFS.

Section 3:
"""For example, RDF statements of the form:

  ex:a  rdfs:subClassOf  owl:Thing .

are forbidden in the OWL-DL [OWL2-SYNTAX] semantic extension."""

  -> This triple can be a valid part of an OWL 2 DL ontology. A better 
example would be:

  ex:a  rdfs:subClassOf  "Thing" .

Moreover, perhaps a reference to OWL 2 mapping to RDF graphs [1] would 
be better, since [OWL2-SYNTAX] defines OWL 2 ontologies in terms of a 
functional syntax that does not say anything about the constrains in the 
RDF serialisation.

Section 4:
"A typed literal contains two names" -> We do not have the notion of 
typed literals since all literals are typed.
"Two graphs are isomorphic when each maps into the other by a 1:1 
mapping on blank nodes." -> this is very much underspecified. There are 
other constraints on isomorphisms.
"Graphs share blank nodes ... of distinct blank nodes." -> this 
discussion should not be here. In fact, it should rather appear in 
Concepts. In any case, it does not belong to notation and terminology.
"This document will often treat a set of graphs as being identical to a 
single graph comprising their union, without further comments." -> if my 
concerns above are taken into account, this should be removed. A 
definition of merge should be added instead. By the way, I haven't seen 
many sets of graph being treated as a single graph. Actually, I think I 
only saw it twice. So we cannot say "often".

Section 5:
Make it a subsection of "Simple semantics"? "Simple entailment"?
"a function from expressions (names, triples and graphs) to semantic 
values:" -> what's a "semantic value"?
"triple s p o then ..." -> why not "triple (s, p, o)" ?
Same remark in item 4 of Section 5.2

Section 6:
Make it a subsection of "Simple semantics"? "Simple entailment"?
"a graph G simply entails a graph E when every interpretation which 
satisfies G also satisfies E, and a set S of graphs simply entails E 
when the union of S simply entails E" -> change this to "a set S of 
graphs simply entails a graph E when every interpretation which 
satisfies all graphs in S also satisfies E"
Remove the Change Note.

Section 6.1:
"the inference from (P and Q) to P, and the inference from foo(baz) to 
(exists (x) foo(x))." -> the notation "(P and Q)" etc is rather obscure 
in this context. Perhaps it would be good to present the usual First 
Order Logic translation of the semantics. BTW, the usual FOL translation 
would not be valid for entailments over a set of graphs because 
{FOL(G1),FOL(G2)} is equivalent to FOL(merge(G1,G2)).
The example with ex:a ex:p _:x is confusing RDF graphs and RDF 
documents, as well as bnodes and bnode identifiers. Then, while the 
naive readers would intuitively imagine that taking the union of the two 
triples would simply amount to putting them together, they realise that 
they have to "standardise apart" the bnode identifiers.

Section 7:
"For any graph H, if sk(G) entails H then there is a graph H' such that 
G entails H' and H=sk(H')" -> this should rather be: "For any graph H, 
if sk(G) entails H then there is a skolemization sk'(H) of H such that G 
entails sk'(H)"

Section 8:
Remove the second change note, as per my concerns above.
"datatype d refers to (denotes) the value" -> why not just say "denotes"
"L2V(d)(string)" -> rather, L2V(d)(sss)
"rdf:plainLiteral" -> "rdf:PlainLiteral"
"the datatype it refers to MUST be specified unambiguously" -> yes, 
there MUST be a mapping from datatype IRIs to datatypes, i.e., there 
must be a datatype map. This is a MUST, why doesn't it appear as a 
constraint in the formal semantics?

Section 9:
Make it a subsection of "D-semantics"? "D-entailment"?

Section 10:
Make it a subsection of "D-semantics"? "D-entailment"?
"a set S of graphs (simply) D-entails or entails recognizing D a graph G 
when every D-interpretation which makes S true also D-satisfies G." -> 
"a set S of graphs (simply) D-entails a graph G when every 
D-interpretation which satisfies all graphs in S also D-satisfies G."

Section 10.1:
why not put the general rule for datatype entailment:
"""
aaa uuu "xxx"^^ddd => aaa uuu "yyy"^^eee
where L2V(I(ddd))(xxx) = L2V(I(eee))(yyy)
"""

Section 11:
Make it a subsection of "RDF semantics"? "RDF entailment"?


Section 12:
Make it a subsection of "RDF semantics"? "RDF entailment"?

Section 12.1:
Group the rules together, as in Section 14.1

Section 13:
Make it a subsection of "RDFS semantics"? "RDFS entailment"?

Section 14:
Make it a subsection of "RDFS semantics"? "RDFS entailment"?

Section 15:
"plus an optional default graph" -> the default graph is not optional, 
there must be exactly one

Appendix A:
"follows exactly the terms used in [OWL2-SYNTAX]" -> it is 
[OWL2-PROFILES], in Section 4.3. OWL2-SYNTAX does not rely on RDF triples
"Every RDF(S) closure, even starting with the empty graph, will contain 
all RDF(S) tautologies" -> not all, the closure as defined is finite, 
while there are infinitely many tautologies. All tautologies concerning 
the vocabulary of the initial graph, union the tautologies in the RDF 
and RDFS vocabularies.

Appendix C:
The proof that every graph is satisfiable does not need introducin 
Herbrand interpretation and does not need to build an interpretation for 
each graph considered. There is a single interpretation that makes all 
RDF graph simply true. Consider a domain comprising only one element x. 
Map all IRIs and literals to x, including those used as predicates. Make 
the IEXT of x be the single pair {(x,x)}. This simply satisfies all graphs.

Appendix D.1:
"The subject of a reification,/a>" -> typo

Appendix D.2:
The RDF container vocbulary should also mention rdfs:member, 
rdfs:containerMembershipProperty.
-- 
Antoine Zimmermann
ISCOD / LSTI - Institut Henri Fayol
École Nationale Supérieure des Mines de Saint-Étienne
158 cours Fauriel
42023 Saint-Étienne Cedex 2
France
Tél:+33(0)4 77 42 66 03
Fax:+33(0)4 77 42 66 66
http://zimmer.aprilfoolsreview.com/

Received on Wednesday, 12 June 2013 10:54:03 UTC