SPARQL endpoint authentication using SuRF

[Tatiana Al-Chueyr Martins]

Hi Guys,

I'd like to connect to a SPARQL endpoint that requires authentication.

Apparently, SuRF doesn't provide this feature. However, SPARQLWrapper (that's already being used by sparql_protocol plugin) does. I'd like to add this feature to SuRF, providing a patch.

Based on this, I have the following questions:

(1) Does the community have interest in such a feature?

(2) Any suggestions regarding the implementation?

Regarding (2), I considered adding two optional keyword arguments (eg. <user> and <passwd>) to surf.Store's __init__, as we currently set the endpoint there. Is this ok?

Despite changing Store's constructor, I'd also need to make some change on surf.sparql_protocol - taking care to maintain backward compatibility and letting authentication to be optional.

Last question:

(3) How is the compatibility between plugins? Can this feature be implemented only on the sparql_protocol plugin? How should the user be warned?

Best regards,

Tatiana

[Cosmin Basca]

Hi Tatiana,

Thanks for your interest in SuRF and great suggestions. It's been a while since I last looked at SuRF's code base. The Plugin and Store classes pass on the *args and **kwargs arguments to the __init__ of each plugins individual reader and writer implementation class. So you could pass in the "password" and "user" keyword arguments to the stores constructor. They will of course have to he "connected" to the sparql-wrapper instance that's used internally by the sparql protocol plugin.    

On Monday, July 9, 2012 6:26:00 PM UTC+2, Tatiana Al-Chueyr Martins wrote:

Hi Guys,

I'd like to connect to a SPARQL endpoint that requires authentication.

Apparently, SuRF doesn't provide this feature. However, SPARQLWrapper (that's already being used by sparql_protocol plugin) does. I'd like to add this feature to SuRF, providing a patch.

Based on this, I have the following questions:

(1) Does the community have interest in such a feature?

Yes, I'd like to see it - in fact it should have been in from the begging, thanks for pointing it out!

 

(2) Any suggestions regarding the implementation?

The only modifications I see are required in the plugin class itself

 

Regarding (2), I considered adding two optional keyword arguments (eg. <user> and <passwd>) to surf.Store's __init__, as we currently set the endpoint there. Is this ok?

no need to add them explicitly, the **kwargs already support you to call Store with the user="user", password="password" arguments.  

 

Despite changing Store's constructor, I'd also need to make some change on surf.sparql_protocol - taking care to maintain backward compatibility and letting authentication to be optional.

of course, you could do it like this: 

user = kwargs.get('user', None), use user only of set - by default it's not set. Same goes for password  

 

Last question:

(3) How is the compatibility between plugins? Can this feature be implemented only on the sparql_protocol plugin? How should the user be warned?

the plugin system is flexible, such features are basically easy to add - just provide support for them in the actual plugin. Compatibility will not be broken, if the defaults are set to None (for user and password). This set of extra arguments should be documented in the plugins description, along side with any other features that are supported at one point or another. 

 

Best regards,

Tatiana

Cheers,

Cosmin 

[Cosmin Basca]

Hi Tatiana, 

Sorry for the long delay - I've finally gotten some time to play with surf :). I've fixed the issue as of rev 377, please check it out and let me know if it does the job for you. 

When you create the store just pass in the user and password parameters as keyword arguments and they should be propagated all the way to the SparqlWrapper instance.

Cheers,

Cosmin