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

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

From: Dave Reynolds <der@hplb.hpl.hp.com>
Date: Fri, 24 Apr 2009 14:38:26 +0100
Message-ID: <49F1C0D2.7010700@hplb.hpl.hp.com>
To: Jos de Bruijn <debruijn@inf.unibz.it>
CC: RIF <public-rif-wg@w3.org>
Jos de Bruijn wrote:
> Dave Reynolds wrote:
>> Look like good proposals.
> So you do not have a problem with the slight change in the semantics of
> RDF lists (in combinations) implied by the proposal?

The change being the equality implications (e.g. a list with two 
rdf:firsts implying that the object values are equal)?

If so, then the definition makes sense but does mean that even with 
simple-entailment implementing a Core-RDF combination requires equality 
reasoning, which is worrying.

In practice all the in-the-wild RDF lists I've ever seen are well-formed.

I wonder if restricting the semantics of interpretations to RDF graphs 
with well-formed lists would be preferable and leave the interpretation 
of ill-formed lists as undefined?

Alternatively, have this stronger definition of the semantics but limit 
conformance to only being required over well-formed lists.

>> My assumption is that we'd want the one-to-one mapping but that's to be
>> discussed I guess.
> 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.

> By the way, I believe that even the "RIF lists as extensions" is not so
> straightforward to implement, especially when using the RDFS semantics.
> You can do things like creating sub properties of rdf:first, and so you
> cannot read the structure of the lists from the syntax of the graph.

Not that much of a problem for any system which already does RDFS 
inference though I guess in a RDF-RIF combination they might be thinking 
of punting off the RDFS reasoning to the RIF engine by using the 
embedding approach.

> For embedding this semantics (in the appendix of this specification) I
> was thinking of restricting the use of rdf:first, rdf:rest, and rdf:nil
> in combinations, so that the RIF lists can simply be constructed from
> the RDF lists in the graphs.

That's a stronger restriction than well-formed lists.  I have seen 
in-the-wild use of sub-properties of first/rest (for representing typed 

Since the embedding is only Informative anyway then such a restriction 
would be OK but I'm not sure it is necessary. Can't you write the 
embedding so that the RIF rules construct the RIF lists from the 
separate frame assertions? Such rules would not be guaranteed 
terminating but could still be within Core now we've moved E-S safety 
out to an informative section.

Received on Friday, 24 April 2009 23:41:45 UTC

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