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

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.

Apart from that, what you write in [1] pretty much makes sense to me,
We could summarize what we seem to agree so far as follows:

  - treat bnodes in a head by skolemization (or the built-ins suggested).
  - treat bnodes in a body or query as (special) variables.

  what yet seems to be open for me is three things:

  - how we'd deal with bnodes in N3 like rules reused in several rules.
      Alternatives: - forbid
                    - standardize apart upfront.
                    - other ... ?
  - how we'd deal with bnodes occurring in both head and body of N3 like
    rules.Alternatives: - forbid
                        - treat both as variable
                        - treat hewad as skolem and body as variable
                        - other ... ?

  - how we'd deal with results of rule(set)s? ie. if we have a frame
    s[p->o] in the head of a rule (where s,p,o is a variable skolem
    term, literal, iri, etc), it might well not be a valid RDF
    triple, so my question is, for N3 like rules, how would we ensure
    that the result is getting back to RDF again. Do we need/want that?

    (Here, e.g. SPARQL takes the approach
    to simply ignore all non RDF triples, and only consider valid RDF
    triples as consequences)

cheers,
  axel

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


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

Received on Wednesday, 4 July 2007 11:54:57 UTC