Re: is wikidata label service complaint with SPARQL 1..1

On 03/27/2017 02:10 PM, Andy Seaborne wrote:
> 
> 
> On 27/03/17 17:19, Peter F. Patel-Schneider wrote:
>> I was thinking about whether using fresh variables was a problem for SPARQL
>> and came across the Wikidta label service, described at
>> https://www.mediawiki.org/wiki/Wikidata_query_service/User_Manual#Label_service
>>
>> This service breaks if variables are renamed.  However, I don't think that
>> this is a problem because at least the automatic version of this service is
>> *NOT* a compliant SPARQL 1.1 service.  As far as I can tell, the only
>> permissable results from using the service in an experssion like
>>   SERVICE wikibase:label { bd:serviceParam wikibase:language "en" . }
>> are the empty solution sequence and the solultion sequence containing an
>> empty set of binding.
>>
>> This makes the service not part of SPARQL at all because it returns bindings
>> for other variables.
>>
>> Does anyone think that this service can be considered to be a legal SPARQL
>> 1.1 service?
>>
>> peter
>>
>>
> 
> IMO it is not strictly compliant; SERVICES is a remote invocation of SELECT *
> { ... } so the variables are those from the pattern.  It's fairly harmless to
> add variables because it is possible to generate practical globally fresh
> variables even in the absence of any agreement between all parties.
> 
> UUID (version 4 - the random ones) are 122 bits of random number so the
> chances of clash or guess are really quite small. (Many others things have
> much higher chances of happening, like data in RAM going from a 5 to a 6 in an
> unnoticed way.)
> 
> Even knowing the algorithm does not mean you can guess what a UUID will be. 
> So a UUID, made into a safe variable string is for all practical purposes
> globally unique for all time.
> 
> Version 1 UUIDs are more guessable because they are clock+fixed unique id -
> they would really need everyone to play the "try not to clash" game - but
> version 4 are unguessable.
> 
>     Andy

The problem here is not accidental clashes but instead is renaming a variable
away.  For example, the service might end up taking a value for ?person and
bind ?personLabel.  If ?person is renamed to ?<random> then it would set up
values for ?<random>Label, which isn't what is needed.

peter

Received on Monday, 27 March 2017 21:51:41 UTC