Re: [RDF+OWL] Way of connecting RDF and RIF lists

Sandro Hawke wrote:
>>> The argument against the one-to-one mapping is that it's harder to
>>> implement.  I believe you cannot implement it in a rule system that does
>>> not support function symbols, unless you have specific machinery for
>>> manipulating the RDF list structures while you manipulate the RIF
>>> structures: the construction of an RIF list implies the existence of a
>>> bunch of objects used for the structure of the RDF list.
>> I think any system likely to implement this would have such specific 
>> machinery anyway.
>>
>> However, the "as extensions" option is still useful and a lower 
>> implementation barrier so perhaps that would be the better choice. It 
>> doesn't stop people doing future extensions which strengthen the link.
>>
>> I won't be there on Tuesday (though I may be able make the first 25m of 
>> the call if that would be useful). At the moment my preference would be 
>> "as extensions" as top choice (on grounds of lower implementation cost) 
>> but "1-to-1" also acceptable.
> 
> How big is the implementation cost?  Jos said he thought Jena had this.

The implementation should be easy for Jena (if we do implement at all). 
Indeed it would harder to do it the other way since by default our lists 
would actually be RDF lists. I was commenting in general rather than for 
Jena but indeed I'm not sure the implementation cost is significant.

On reflection I've some slight unease about the 1-to-1 option and was 
using "implementation cost" as a cop out to avoid me having to figure 
out why I was uneasy. :-)

Thinking out loud here ... consider the rule set[*]:

    p(:a).
    q(List(?x, ?x)) :- p(?x).

Under 1-1 semantics I believe this entails the RDF list (using Turtle 
notation):

    (:a :a)

i.e.

    [rdf:first :a; rdf:rest [rdf:first :a; rdf:nil]]

Right?

So creating a list, even just as an argument to a predicate, implies 
creating an RDF list structure (with a bNode for the list root) even 
though the rest of the predicate is invisible to the RDF view.

So for a PR engine if they want to implement RIF-RDF combinations with 
the 1-1 semantics then every time they cons up a list they will need to 
assert the corresponding frame formulae into their working memory. This 
seems like a high overhead.

Does that make sense? Is this a genuine problem or am I off base here?

I realize the term "RDF view" is not a defined notion in RIF, we only 
define the semantics of RIF-RDF combinations. However, in an RDF 
implementation I would expect to provide a means to extract an entailed 
RDF graph from the RIF-RDF combination, that's the value of such 
combinations for RDF processing. The fact that RIF predicates are not 
part of the entailed graph is rather useful. Having lists which aren't 
otherwise referenced (by non-list frames) leak out into that view is 
problematic.

Now, to argue against myself, in the rule set:

   p(:a).
   :f[:p->List(?x ?x)] :- p(?x).

Then you would prefer the RDF view of the entailments to include:

   :f :p (:a :a) .

Since the RDF view of the RIF-RDF entailments is not defined then an 
implementer could do what they like. In the 1-1 case they could omit the 
orphaned lists from the view, in the extensions case they could add the 
non-orphaned lists into the view. So I can make something useful work 
either way.

> The main reason I want one-to-one is for people doing SPARQL queries on
> the frames in a RIF rule base.  But I guess that SPARQL interface could
> do this conversion without it really being a mandatory part of RIF (just
> like it would do the conversion from rdf:text to RDF's plain literals).

Yes, this sounds like what I mean by an "RDF view" of the combination.

Dave

[*] By the way, is this rule set in RIF Core? During the f2f discussion 
on "grounded lists" in the core I found it hard to follow on the phone 
what people were meaning by grounded lists.

Received on Friday, 1 May 2009 08:45:10 UTC