- From: Dave Reynolds <der@hplb.hpl.hp.com>
- Date: Fri, 24 Apr 2009 15:04:35 +0100
- To: Sandro Hawke <sandro@w3.org>
- CC: Jos de Bruijn <debruijn@inf.unibz.it>, public-rif-wg@w3.org
Sandro Hawke wrote: >>>>> negative-entailment >>>>> PREMISE: >>>>> CONCLUSION: index-of(list(eg:foo eg:bar), eg:foo) = list(1) >>>> No. eg:foo is mapped to the same object in every interpretation. Let's >>>> call this object a. And let's say eg:foo is mapped to b. Then >>>> list(eg:foo eg:bar) represents the sequence (a,b). And certainly the >>>> object a appears in the first position of this sequence. >>>> >>>> So, this should be a positive entailment test. >>> Well, I'd agree that in all interpretations, there's a match in the >>> first position. But in some interpretations there's also a match in the >>> second postion (namely interpretations where eg:foo=eg:bar). So, in >>> some interpretations, the left side of the equals is interpretated as >>> list(1) and in others it's list(1 2). So, I think that means the >>> equality doesn't hold in all interpretations, and the proposed >>> conclusion is not entailed... >> You are right. My mistake. > > Which kind of makes my point about how this is counter-intuitive. :-) Sure is. > I'm not sure if this challenge comes up with giving rif:iri and > rif:local to non-list built-ins. In a sense, they are like variables, > and might be unbound, too. Did you think about that in the defn' of > safeness? > > Thinking about that led me here: > > PositiveEntailmentTest(BLD) > PREMISE: p :- isNumeric(foo) and (eg:foo > 0 or eg:foo < 0 or eg:foo = 0) > CONCLUSION: p. Surely that's not entailed, there are interpretations in which foo fails isNumeric. > Anyway, back on lists, which option shall we go with: > > 1. This is just a user-education issue. Highlight the above test > case as an example in the spec. > > 2. Require that list elements be Consts. (And say that Lists are > Consts; give them a lexical space.) > > 3. Option 2, but only for Core. Somehow enable this Const > requirement to be relaxed in extension. This would probably be > my option, except that I don't know how to do it, which leaves > me preferring option 1. > > 4. ... something more clever? 2 and thus 3 makes the lists useless for representing RDF lists at least in Core (which is the one I care about) which leaves me preferring option 1 as well. Since in Core we can't assert equality anyway then I wonder if we could allow implementations to make a UNA for Core? :-) Part of the problem is that index-of is too powerful. It in effect is testing for absence as well as presence. Perhaps it could be restricted to be slightly less problematic, for example just return *an* index rather than all indicies. Dave -- Hewlett-Packard Limited Registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 England
Received on Friday, 24 April 2009 14:05:41 UTC