- From: Dave Reynolds <der@hplb.hpl.hp.com>
- Date: Fri, 24 Apr 2009 14:38:26 +0100
- 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 lists). 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. Cheers, Dave
Received on Friday, 24 April 2009 23:41:45 UTC