W3C home > Mailing lists > Public > public-rif-wg@w3.org > April 2007

RDF Compatibility (Re: Homework for 17 Apr telecon)

From: Sandro Hawke <sandro@w3.org>
Date: Mon, 16 Apr 2007 17:16:07 -0400
To: Chris Welty <cawelty@gmail.com>
Cc: "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>
Message-Id: <20070416211634.4B5BE4EFF0@homer.w3.org>

> At the next telecon we will discuss RDF compatibility.  Please prepare 
> for this by briefing yourself on any background you may need - this is 
> an important issue to resolve (or at least substantially address) by 
> the next Core WD.

There are lots of different RDF compatibility issues (we listed eight in
the F2F1 breakout [1]) but I guess there are two we're likely to address
at this point:

** RDF issue: binary vs ternary

Here the question is whether the RDF triple { s p o} appears in RIF
conditions as 
   - a binary atom: p(s,o)
   - a "property" atom:  like s[p->>o] or  __property_triple(s,p,o)

The binary-atom approach seems simpler, but it doesn't allow for
variables in the property/predicate position, which seems to be
important in RDF rules.  So I think we have to go with the second
option, unless there's some way to support both.

I wonder what would happen if translators supported both, in parallel.
That's kind of nuts, I guess....   Hrm.   The n3 rule
    { a b c.  d e f } => { g h i }
would have to turn into (ad hoc syntax)
    if  ( b(a,c) or a[b->>c] ) and
        ( e(d,f) or d[e->>f] ) 
    then ( h(g,i) and g[h->>i] )
which isn't Horn, but can be re-writen to Horn with exponential growth.
That's nuts, right?  Maybe there's some other way to support both,

** RDF issue: b-nodes

Here the question is how to map an rdf triple like { _:x p o } to a RIF
atom.  "_:x" is a b-node, a file-scoped existential variable.

It seems to me that:

  - in a fact, a b-node is just like like a file-scope identifier.
    (You know, those things we use to name things when we don't feel
    like using URIs.)

  - if a b-node occurs only in a rule's consequent, it's a Skolem term.
    That is:
        { ... ?x ... ?y ... } => { _:x a b }
    turns into
        if ... ?x ... ?y ... 
        then a(skolem_function_x(?x, ?y), b)

    [how do you write that in f-logic?   skf(?x,?y)[a->>b]  ? ]

  - if a b-node occurs in just the antecendent, or in both the
    antecedent and the consequent, it's probably the same as a
    universally quantified variable.  If it also occurs in a fact, who
    knows ....  but hopefully the language designer does, so we don't
    have to.

There may be some other cases, ... but the bottom line, I think, is that
one can map between b-nodes and constructs we'll have in RIF Core
anyway.  So RIF Core doesn't need to do anything to accomodate b-nodes.

It would be nice to have some way to indicated that a term is a Skolem
term.  I know lots of reasoners want that anyway, but I've never quite
understood why.  In this case, it might be needed for round-tripping.
(Although, in going from RIF to n3, all function terms -- Skolem or not
-- will have to be translates into b-node expressions.   So maybe we
don't need a Skolem flag.)

     -- Sandro

[1] http://www.w3.org/2005/rules/wg/wiki/F2F1_Breakout_Session_on_OWL_and_RDF_Compatibility
Received on Monday, 16 April 2007 21:16:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:43 UTC