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

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

Best, Jos

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

-- 
Please note my new email address:
                         debruijn@inf.unibz.it

Jos de Bruijn,        http://www.debruijn.net/
----------------------------------------------
In heaven all the interesting people are
missing.
  - Friedrich Nietzsche