Re: definition of INDISTINCT

Eric Prud'hommeaux wrote:
> * Jeen Broekstra <j.broekstra@tue.nl> [2007-03-16 17:39+0100]
>> Alright, nitpicking a bit:
>>
>> Eric Prud'hommeaux wrote:
>>
>>> persuant to
>>>   ACTION: ericP to draft text about a LOOSE keyword and run it by w3
>>>   folks to see if we're abusing the "at risk" mechanism.
>>> I drafted this section. It was slightly more awkward to not have an
>>> ALL to lean on, but I think this is pretty well defined:
>>>
>>> 9.4 INDISTINCT
>> When/where was this term introduced?
>>
>> If we decide to add this, I think I would actually prefer LOOSE:
>> INDISTINCT suggests (to me at least) that it is the opposite of DISTINCT
>> (which it is not; it would even be acceptable to have the same behavior
>> as DISTINCT).

I agree with Jeen.  LOOSE is better.

INDETERMINATE is a bit long :-)

>>
>>> While the DISTINCT modifier ensures that duplicate solutions are
>>> eliminated from the solution set, INDISTINCT simply permits them to be
>>> eliminated. The cardinality of any set of variable bindings (solution)
>>> in an INDISTINCT solution set at least one and not more than the
>> ...*is* at least one...
> 
> noted
> 
>>> cardinality of the solution set with no DISTINCT or INDISTINCT
>>> modifier.
>> Perhaps better formulation would be to refer to the cardinality of the
>> solution set as prescribed by the algebra.
>>
>>> For example, the query
>>>
>>>   PREFIX foaf:    <http://xmlns.com/foaf/0.1/>
>>>   SELECT INDISTINCT ?name WHERE { ?x foaf:name ?name }
>>>
>>> may have one, two (shown here) or three solutions:
>>>   name
>>>   "Alice"
>>>   "Alice"
>> Of course, this only holds for a dataset which holds at least three
>> solutions for Alice, you might want to make that more explicit in this
>> paragraph (referring back to the example dataset explicitly?).
> 
> I think that in context with the DISTINCT proposal, it's clear. See
> the attached HTML and tell me if you agree.

A thought: as DISTINCT and LOOSE are mutually exclusive, maybe 9.3.1 and 9.3.2 
would be a better arrangement.  That would mean that the first part of 9.3, 
which is about queries without DISTINCT or LOOSE can go in 9.3 intro.

(Following that through, OFFSET and LIMT could go together in a "slice" 
section - editorial - for CR?)

I suggest adding text to say that queries with LOOSE may behave differently 
across different implementations.  I don't know how to say that in the 
conformance language which does not use "implementation".

And presumably a LOOSE query may differ across requests of the same query at 
the same service, given the motivating example we have been using.

It was suggested that there would be "at risk" text.  This should include 
mention that queries using LOOSE will not necessarily extend to aggregate 
functions.

	Andy

Received on Sunday, 18 March 2007 18:01:44 UTC