W3C home > Mailing lists > Public > public-rdf-wg@w3.org > October 2012

Sloppy inference rules

From: Pat Hayes <phayes@ihmc.us>
Date: Tue, 30 Oct 2012 11:15:31 -0500
Cc: RDF WG <public-rdf-wg@w3.org>
Message-Id: <6CBF1A95-008F-41A4-AC26-1AD3B130384D@ihmc.us>
To: Guus Schreiber <guus.schreiber@vu.nl>
One of the potential semantic issues that Guus has dug up probably should be discussed by the whole group, so I will try to state the essence of it from Herman's message  http://lists.w3.org/Archives/Public/www-rdf-comments/2005OctDec/0003.html. 

It concerns a subtlety of RDFS entailment involving blank nodes. 

Consider the following graph:

:prop1 rdfs:subProperty :prop2
:prop2 rdfs:Domain :Class
:a :prop1 :b

This RDFS-entails 

:a :type :Class

No problem there; but if we replace :prop2 by a blank node:

:prop1 rdfs:subProperty _:x
_:x rdfs:Domain :Class
:a :prop1 :b

it still RDFS-entails 

:a :type :Class

but, as Herman notes, the inference rules as given don't handle this case. As he also notes, if RDF were to allow blank nodes in property position of triples, this would solve the problem: the rules as given would then cover this case. In 2005 it seemed kind of obvious that any future modification of RDF would indeed allow blank nodes in property position, just like it was obvious it would allow literals in subject position. However, those heady 2005 days are now a fading dream.

I do not know of any reasonable way to add rules which can cover this kind of case without putting a blank node into the property position of a triple. The unreasonable way is just to add a special rule to handle this case, but then there will be other cases also, eg involving ranges instead of domains, and indeed involving any property of properties, eg subproperty chaining, which can go arbitrarily deep and so would need a potential infinity of rules. And RDF semantic extensions will need to extend these cases if they do anything with properties. It is very hard to know that you have covered all the cases when the only available strategy is to think of them all and list them all.

For a similar reason, the rules as stated could be very much simpler if literals were to be allowed in subject position, since then the special ("silly") rules used to insert blank nodes in place of literals would just be handled by graph matching, in the same way that other bnode entailments are captured.  

In both cases, the problem arises because RDF imposes syntactic restrictions which are semantically meaningless, and the "illegal" expressions not only make perfect sense, but are actually needed to record perfectly valid entailments. 

So my question to the WG is, how disastrous would it be if the RDFS inference rules were stated in terms of a 'sloppy' version of RDF with the syntactic restrictions removed, i.e. with the following grammar for triples?

triple ::= term term term .
term ::=  IRI | blanknode | literal

The idea would be that inference could be done by applying the rules to exhaustion, then throwing away any triple that isn't RDF legal. (Other strategies are also possible.) And the point being, that there are inference paths from legal RDF graphs to legal RDF triples that go through derivations that involve triples which are syntactically illegal but make perfect semantic sense. For example, in the case above, the derivation would be 

:a :prop1 :b .
:a _:x :b   	by the subproperty rule
:a :type :Class   by the Domain rule

The only alternative that I can see is to just admit that the rules are incomplete, and explain why. 

Comments?

Pat

PS. AFAIK, no inference requires literals in predicate position, in fact, so we could be slightly less sloppy: bnodes and IRIs anywhere, literals fore and aft. 


On Oct 30, 2012, at 5:32 AM, Guus Schreiber wrote:

> 
> I did a scan of the comments received on
> 
>  http://lists.w3.org/Archives/Public/www-rdf-comments/
> 
> from Feb 2004 onwards. Below is the result. To be on the safe side I included all threads that were not explicitly either closed or added to the errata list.
> 
> I expect most of the comments below to have been dealt with. The comments still need to be sorted wrt the document concerned.
> 
> Guus
> 
> 
> POTENTIAL ISSUES
> 
> Media types and assertions, Mark Baker
> http://lists.w3.org/Archives/Public/www-rdf-comments/2004JanMar/0075.html
> 
> RDF Keys, Bob McGregor
> http://lists.w3.org/Archives/Public/www-rdf-comments/2004JanMar/0089.html
> 
> Inconsistency in RDF spec, Bill Davis
> http://lists.w3.org/Archives/Public/www-rdf-comments/2004AprJun/0018.html
> 
> Implementation feedback
> http://lists.w3.org/Archives/Public/www-rdf-comments/2004JulSep/0007.html
> 
> Difficulty with syntax spec, Klyne
> http://lists.w3.org/Archives/Public/www-rdf-comments/2004JulSep/0004.html
> 
> Pls warn against untested hooks, DanC
> http://lists.w3.org/Archives/Public/www-rdf-comments/2005JanMar/0003.html
> 
> RDF Semantics / error in RDFS entailment lemma, ter Horst
> http://lists.w3.org/Archives/Public/www-rdf-comments/2005OctDec/0003.html
> 
> RDF validator, Firefox
> http://lists.w3.org/Archives/Public/www-rdf-comments/2006AprJun/0000.html
> 
> Comment on RDF Model Theory, Jeremy Carrol
> http://lists.w3.org/Archives/Public/www-rdf-comments/2007AprJun/0001.html
> 
> N-Triples MIME type should not be text/plain, Tim Berners-Lee
> http://lists.w3.org/Archives/Public/www-rdf-comments/2007OctDec/0001.html
> 
> 
> ERRATA
> 
> http://lists.w3.org/Archives/Public/www-rdf-comments/2011JulSep/0000.html
> http://lists.w3.org/Archives/Public/www-rdf-comments/2011AprJun/0000.html
> http://lists.w3.org/Archives/Public/www-rdf-comments/2011JanMar/0000.html
> http://lists.w3.org/Archives/Public/www-rdf-comments/2010OctDec/0002.html
> http://lists.w3.org/Archives/Public/www-rdf-comments/2010OctDec/0001.html
> http://lists.w3.org/Archives/Public/www-rdf-comments/2010JanMar/0002.html
> http://lists.w3.org/Archives/Public/www-rdf-comments/2010JanMar/0001.html
> http://lists.w3.org/Archives/Public/www-rdf-comments/2010JanMar/0000.html
> http://lists.w3.org/Archives/Public/www-rdf-comments/2009OctDec/0000.html
> http://lists.w3.org/Archives/Public/www-rdf-comments/2009JanMar/0005.html
> http://lists.w3.org/Archives/Public/www-rdf-comments/2008OctDec/0000.html
> http://lists.w3.org/Archives/Public/www-rdf-comments/2008JulSep/0003.html
> http://lists.w3.org/Archives/Public/www-rdf-comments/2008JulSep/0000.html
> http://lists.w3.org/Archives/Public/www-rdf-comments/2008JanMar/0003.html
> http://lists.w3.org/Archives/Public/www-rdf-comments/2007OctDec/0018.html
> http://lists.w3.org/Archives/Public/www-rdf-comments/2007OctDec/0006.html
> http://lists.w3.org/Archives/Public/www-rdf-comments/2007OctDec/0005.html
> http://lists.w3.org/Archives/Public/www-rdf-comments/2007OctDec/0004.html
> http://lists.w3.org/Archives/Public/www-rdf-comments/2007OctDec/0003.html
> http://lists.w3.org/Archives/Public/www-rdf-comments/2007OctDec/0000.html
> http://lists.w3.org/Archives/Public/www-rdf-comments/2007JulSep/0000.html
> http://lists.w3.org/Archives/Public/www-rdf-comments/2006JanMar/0000.html
> http://lists.w3.org/Archives/Public/www-rdf-comments/2005AprJun/0000.html
> http://lists.w3.org/Archives/Public/www-rdf-comments/2005JanMar/0028.html
> http://lists.w3.org/Archives/Public/www-rdf-comments/2005JanMar/0001.html
> http://lists.w3.org/Archives/Public/www-rdf-comments/2004OctDec/0001.html
> http://lists.w3.org/Archives/Public/www-rdf-comments/2004OctDec/0000.html
> http://lists.w3.org/Archives/Public/www-rdf-comments/2004JulSep/0013.html
> http://lists.w3.org/Archives/Public/www-rdf-comments/2004JulSep/0005.html
> http://lists.w3.org/Archives/Public/www-rdf-comments/2004JulSep/0002.html
> 
> 
> 
> 
> 
> 

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973   
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
Received on Tuesday, 30 October 2012 16:16:07 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:52 GMT