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

Dave Reynolds wrote:
> 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)?

Right.

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

Unless you require lists to be well formed in the input.

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

Well, there is currently no notion of conformance in SWC.  If we would
have such a notion, I would prefer using performance, rather than
tweaking the semantics, because I think this might lead to unintuitive
results.

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

Yes, I think this can be done if we have appropriate built-ins.  But
we'll first have to see what happens there.

Jos


> 
> Cheers,
> Dave
> 
> 
> 

-- 
+43 1 58801 18470        debruijn@inf.unibz.it

Jos de Bruijn,        http://www.debruijn.net/
----------------------------------------------
Many would be cowards if they had courage
enough.
  - Thomas Fuller