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

On 27/03/17 22:51, Peter F. Patel-Schneider wrote:
>
>
> 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
>

SERVICE wikibase:label is not a real SERVICE call - it is not calling 
the wikibase:label endpoint - which would be a URL and no fragment 
because fragments do not go across the HTTP connection.

Try visiting wikibase:label = <http://wikiba.se/ontology#label>

wikidata is running BlazeGraph which repurposes the SERVICE keyword for 
local enhancements (e.g. it knows the name of the input variables which 
is beyond SPARQL evaluation - it's top-down to get ?NAME).

All bets are off.

Though because this is in fact purely local, the system controls inside 
and outside the SERVICE call and can do anything.

As the name of in-scope variables not used in the pattern got passed in 
to the "SERVICE" (which is not possible in SPARQL 1.1), the renaming 
could be done consistently.

     Andy

Received on Monday, 27 March 2017 23:17:22 UTC