W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > June 2003

Semantics review: closure rules

From: Jeremy Carroll <jjc@hpl.hp.com>
Date: Wed, 18 Jun 2003 19:05:32 +0300
To: w3c-rdfcore-wg@w3.org
Message-Id: <200306181905.32652.jjc@hpl.hp.com>

This is a review of


Appendix B: Entailment rules

1) completeness versus finiteness

I note that you gave up on completeness as noted in the para:

These rules will not generate all graphs which have the original graph as an 
instance, which could include arbitrarily many blank-node triples all of 
which instantiate back to the original triples. Modifying the rules so that 
new blank nodes could be allocated to existing blank nodes would generate all 
such graphs. 

I think it would be better to have se1 and se2 rules that do not naturally 
terminate, and leave termination as a problem for the implementor.
I would also prefer to see completeness at least conjectured if not claimed.

e.g. suggest se1 and se2 should apply to blank nodes as well as uri ref and 
literal nodes, and suggest delete "if there is no such blank node then it 
must be" which should permit "generating all graphs which have the original 
graph as an instance" - but at the cost of not having any obvious way of 

2) RDF axiomatic triples

should be mentioned as always entailed

3) RDFS axiomatic triples

suggest replace

"Note also ..."
with a clearer statement that these are always entailed

3) concerning rdfs 2a, do we also need rdfs 2b

xxx rdfs:domain yyy .
zzz rdfs:subPropertyOf xxx .


zzz rdfs:domain yyy .

similarly rdfs 3b.

4) suggest adding explicit non-completeness statement to D-entailment

example difficult case

<eg:a> <eg:p> "true"^^xsd:boolean .
<eg:a> <eg:p> "false"^^xsd:boolean .
<eg:b> rdf:type xsd:boolean .


<eg:a> <eg:p> <eg:b> .

To do that with an entailment rule looks quite hard.

Another example

<eg:a> <eg:p> "0"^^xsd:decimal .
<eg:b> rdf:type xsd:nonPositiveInteger .
<eg:b> rdf:type xsd:unsignedLong .


<eg:a> <eg:p> <eg:b> .
Received on Wednesday, 18 June 2003 13:05:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:23 UTC