Re: RDF Compatibility (Re: Homework for 17 Apr telecon)

Sandro Hawke wrote:
>> 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:

There is possibly a third such topic:

    "should RIF specify additional semantics for how RDFS terms are 
treated, for example via an implicit RDFS ruleset which is automatically 
included in all relevant RIF rulesets (or via a black box external 
reasoner)"

To which my answer would be "no" but I wasn't clear from the reference 
to Jos' paper whether such a thing might be on the table.

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

Or we allow syntactically higher order rules.

> So I think we have to go with the second
> option, unless there's some way to support both.

Agreed.

If this slotted notation is purely a syntactic sugar for a triple 
predicate then that seems fine. If the semantics of RIF slotted notation 
is subtly different from that then I'd like to understand that difference.

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

I'm happy with treating bNodes in consequents as skolem constants, it 
may not be technically correct but it is useful and in keeping with most 
current usages.

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

We do need to translate the generated skolem constants back to bNodes in 
the resulting RDF.

I think it is a separate question how we treat other RIF constructs like 
function terms in RDF results. For example in JenaRules we do permit 
function terms in the object position of a triple (in which case it is 
encoded as a typed literal with a Jena-specific type). I doubt that 
would be something to support in RIF but we might want to say that a 
processor SHOULD issue a warning if attempting to encode any function 
term back into RDF other than a specific bNodeSKF function.

Dave
-- 
Hewlett-Packard Limited
Registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

Received on Tuesday, 17 April 2007 10:28:15 UTC