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

Dave Reynolds wrote:
> 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.

I tyhink I already said that I buy into this argument, but we shouldn't
say then that we cover RDF entailment rules. Your above proposal of
identifying rulesets and explicitly referring these seems to be a very
reasonable approach to me.

> 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.

ok.

>>> 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.

Yes, this is what I meant with "built-ins which "emulate" a skolem 
function by generating something like a "parametrized" new ID)"

best,
axel

> 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


-- 
Dr. Axel Polleres
email: axel@polleres.net  url: http://www.polleres.net/

Received on Wednesday, 4 July 2007 08:37:06 UTC