W3C home > Mailing lists > Public > public-rif-wg@w3.org > July 2007

Re: "entailment regime"?

From: Dave Reynolds <der@hplb.hpl.hp.com>
Date: Wed, 04 Jul 2007 17:48:08 +0100
Message-ID: <468BCF48.9030102@hplb.hpl.hp.com>
To: Sandro Hawke <sandro@w3.org>
CC: public-rif-wg@w3.org

Sandro Hawke wrote:
> (This message is likely to be controversial among the RDF folks, but I
> think it's important.  It may also not be something we can agree on --
> other Semantic Web working groups have been challenged by this -- but
> let me at least try to make the case.)
> In http://www.w3.org/2005/rules/wg/wiki/Arch/RDF, Jos writes:
>> Furthermore, this data set has a particular entailment regime
>> associated with it (e.g. simple, RDF, RDFS). 
>> rif:rdfEntailmentRegime a rdf:Property ;
>>     rdfs:domain rif:RuleSet ;
>>     rdfs:range  rif:RDFEntailmentRegime .
> If I understand this approach correctly, I'm afraid I have to disagree
> with it.  RDF entailment regimes should *not* be specified.  It's a key
> element of the architecture of the Semantic Web that semantics are
> implied by the vocabulary in use, instead of being explicitely named.

Interesting. Where is this written down?

On the telecon we discussed that part of the proposal and I thought we 
agreed to change it, that the entailmentRegime should be an attribute of 
the ruleset rather than the dataset. At least that's what I was 
suggesting and I thought Jos agreed and no one else objected.

Does that address your issue?

As discussed in the parallel thread with Jos and Axel I would prefer to 
do that by providing an import mechanism rather than metadata. So that a 
rule set where one wanted to process RDF data and assume RDFS semantics 
could be something like:

         <rif:import uri="http://www.w3.org/2007/rif#RDFSruleset.rif" />
         ... rules ...

However, if that were done indirectly via ruleset metadata that would be 
OK too (I can make arguments both ways round if you like :-)).

If neither ruleset import nor ruleset metadata are acceptable to you 
what's the alternative?

> This is for exactly the same reason I argued that RIF documents should
> not be labeled with a dialect identifier, unless it's just a
> suggestion/hint; it provides backward compatibility. 

I hadn't twigged that's what you were after. I think dialect metadata is 
at least needed as a hint ("ah this rule set is supposed to be in 
dialect D, I'm sure I had a D processor around here somewhere, I'll try 
that one first").

> The idea, though, is that you use all the entailment regimes which are
> defined for the vocabulary in use.  So for an RDF/XML document that uses
> no RDFS or OWL terms, RDF entailment applies.  If you use RDFS terms,
> RDFS entailment applies.  If you use OWL terms, OWL entailment applies.
> At a high enough level, this is equivalent to just using all the
> entailment regimes you can.  I know for people concerned with
> theoretical properties of logics, this is painful, and it does present
> some challenges.  But if there's a case where this approach is a real
> problem to users, I'd like to hear about it.

I don't think this is workable in practice. Applications need control 
over which entailment regime to apply for many reasons. Consider writing 
an OWL editor, my editor wants to treat the RDF making up the OWL as 
plain triples when it is editing. Consider checkers such as Jena's 
Eyeball, it proves useful to be able to check that all things used as 
classes are defined as such, if you always had RDFS inference on you 
couldn't do that. Consider applications wishing to make performance 

I can assure you that if in Jena we took away the ability to choose 
inference level separately from content we would have major user support 

However, this last part seems like a more general semantic web 
discussion that should be off the RIF list.

Hewlett-Packard Limited
Registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England
Received on Wednesday, 4 July 2007 16:48:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:46 UTC