Re: [RDF+OWL] Problem with coreifying RDFS entailment embedding

Jos de Bruijn wrote:
> 
> Dave Reynolds wrote:
>> Jos de Bruijn wrote:
>>> While trying to prove that the RIF Core version of the RDFS embedding I
>>> came up with [1] is correct, I found out that it is not.  In fact, I
>>> believe it is not possible to embed all RIF-RDFS combinations into RIF
>>> Core in a straightforward manner.  The problem is with rdfs:Resource.
>>> According to the semantics, every object in the domain is in the class
>>> extension of rdfs:Resource. This is naturally expressed using the rule
>>> Forall ?x (?x[rdf:type -> rdfs:Resource])
>>>
>>> However, this rule is not safe.  I see three ways of dealing with this
>>> problem:
>>>
>>> 1) disallow using rdfs:Resource in the rules and in RDF triples that are
>>> not of the form xxx rdf:type rdfs:Resource in the embedding
>>>
>>> 2) extending the embedding to define rules for all predicate symbols
>>> appearing in the rule set, e.g., if ex:p is a binary predicate, we add
>>> the rules
>>> Forall ?x ?y (?x[rdf:type -> rdfs:Resource] :- ex:p(?x,?y))
>>> Forall ?x ?y (?y[rdf:type -> rdfs:Resource] :- ex:p(?x,?y))
>>>
>>> 3) we drop the requirement of the rules being safe
>>>
>>> I would prefer option 1, because option 2 would make the embedding very
>>> complicated and I guess it is desirable to have the embedding in RIF
>>> Core (ruling out option 3).
>> Something like option (1) seems like the best solution to me. However,
>> wouldn't you also need permit triples of the form:
>>
>>     xxx rdfs:subClassOf rdfs:Resource
> 
> I suppose such triples would not do any harm, so we could allow them.
> I was not aware, however, that people actually used such statements in
> practice.

When manually writing an RDFS schema vocabulary then such statements are 
indeed uncommon (at least less common that C rdfs:subClassOf owl:Thing).

However, RDFS reasoners will derive such statements and so it is not 
totally uncommon to see such statements in knowledge bases and documents 
that have been subject to some machine processing.

I don't feel strongly about this and would not object to these being 
omitted but if it does no harm and doesn't require substantial effort 
then it seems more symmetric to allow them.

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

Received on Tuesday, 10 March 2009 09:48:19 UTC