Re: [Arch] ACTION-259 Start OWL/RDF compatibility section of Arch document

Axel Polleres wrote:
> Jos de Bruijn wrote:
>>>> What we cover is well defined.  We cover simple entailment, RDF
>>>> entailment, and RDFS entailment.  See [1].
>>>
>>> As I said in [*]
>>>
>>> (a) I don't think we need claim that the rules perform simple entailment
>>> at all;
>>>
>>> (b) I would rather that we defined one or more rulesets and make those
>>> rule sets themselves the specification of what is covered. I.e. they are
>>> not "implicit" but "explicit". In particular, different RDFS
>>> applications typically make use of different subsets all of which are
>>> easily handled by rules. We would bless a couple of standard rule sets
>>> (giving them standardized URIs so that importing of those rulesets can
>>> be hardwired into RDF-aware RIF processors).
>>
>> I must say that I do not really like this approach, because it is hard
>> to know what is going on exactly if we just give some rule sets which
>> define some kind of semantics for RDF.
>> Furthermore, the RDF specification defines three normative kinds of
>> entailment.  I would say that they are normative for a reason; we should
>> not ignore the specification.
> 
> we shouldn't, but it might make sense to define some rulesets which e.g. 
> do not include all the infinite axiomatic triples.

Quite.  Given that a complete RDFS closure is infinite whatever we 
define will be a subset of RDFS in any case.

If RDFS-without-the-infinite-axiomatic-triples is the only ruleset we 
define then that would acceptable.

Experience with current implementations says that people find a simple 
RDFS subset (roughly the same as the rhoDF paper) useful so providing a, 
possibly non-normative, ruleset and identifying URI for that would seem 
beneficial to me. But if that's controversial then it's not an issue I 
will fight hard over.

Dave
-- 
Hewlett-Packard Limited
Registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

Received on Wednesday, 4 July 2007 14:39:43 UTC