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

Jos de Bruijn wrote:

 >> Axel wrote:
>> so I'd prefer that we say explicitly what of the RDFS semantics
>> we cover, if we add RDFS as an "implicit" rules set.
> 
> 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).

Axel wrote:

> Anyway, I was in particular referring to
>     http://www.eswc2007.org/pdf/eswc07-munoz.pdf
> which provably is complete for a subset of RDFS and the one rule I refer to is not expressible in RIF Core, as far as I can see. Anyway, if you can convince me that there is a complete set of rules expressible in RIF core which covers bnode renaming, fine.

You don't need such a rule unless you are trying to implement graph 
entailment testing (does G |- G'). In practice what is needed is the 
ability to answer queries over the entailed graph and in the query the 
bNodes are variables.

My evidence for this is that in Jena we do not offer graph entailment 
testing as an operation. This is deliberate. No single user over the 
many years and 100k downloads of the system has ever noticed that this 
was missing and asked for it. To implement the W3C entailment test cases 
we translate the conclusions graph to a query and run the query and it 
is the translation of bNodes to query variables which performs the 
implicit bNode renaming not the entailment rules.

>> I am not sure what is meant by "real bnode" here, but I'd assume a bnode
>> only appearing in the head but not in the body. 
> 
> I would rather assume that bnodes are not shared between the body and
> the head in these N3-like  rule languages.

Agreed.

Axel wrote:

> well, a) this is why I asked today what you meant by N3-like.
> Do you count SPARQL's CONSTRUCTs into N3 like rules? If not what does count as N3 like?
> b) I did not say that these rules USE function symbols, but in order to do Skolemization properly you DO NEED function symbols (or special built-ins which "emulate" a skolem function by generating something like a "parametrized" new ID) 

That's what I meant on the teleconference by wanting a bNode data type 
and associated constructor builtin that assigns a unique internal skolem 
ID to the rigid-bNode instance based on argument values.

Of course this could also be done by general function symbols but they 
are not required and I would rather keep them separate in order to allow 
for a future RIF RDF profile which omits function symbols but includes 
rigid-bNodes.

Cheers,
Dave

[*] http://lists.w3.org/Archives/Public/public-rif-wg/2007May/0078.html
-- 
Hewlett-Packard Limited
Registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

Received on Tuesday, 3 July 2007 20:34:02 UTC