Menu
▾
▴
sparql-wrapper-devel — SPARQL Wrapper development mailing list
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
(2) |
Apr
(7) |
May
|
Jun
(4) |
Jul
(2) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
|
Feb
|
Mar
(10) |
Apr
(4) |
May
(10) |
Jun
|
Jul
|
Aug
(4) |
Sep
(5) |
Oct
|
Nov
|
Dec
(2) |
| 2010 |
Jan
(5) |
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
(4) |
Feb
(5) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(6) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
(4) |
Feb
(5) |
Mar
|
Apr
|
May
(3) |
Jun
(1) |
Jul
(1) |
Aug
(11) |
Sep
(4) |
Oct
(6) |
Nov
|
Dec
(3) |
| 2013 |
Jan
|
Feb
(1) |
Mar
(11) |
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
(8) |
Sep
(3) |
Oct
(9) |
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(2) |
Nov
|
Dec
|
|
From: Pēteris C. <cu...@gm...> - 2010-01-12 11:28:15
|
Hi, I grabbed svn version of SPARQLWrapper and enabled this feature in my application. It's issuing the requests to Virtuoso SPARQL endpoint, sometimes simultaneously from several threads. I've tried the script that does thousands of requests and so far it's been working fine. Peteris 2010/1/11 Carlos Tejo <car...@fu...> > Hi, > > > thanks you very much to point us such feature in urllib, it's good to > > know it while that wrapper strong depends on that library. > > > > We'll study how to include it, but I agree with you that should be > > something optional. Meanwhile you can register it as a feature request > > in SourceForge: > > > > http://sourceforge.net/tracker/?group_id=217900&atid=1041490 > > This feature has been registered in the tracker [1]. > > And we already included a draft of how can be implemented (see commit#96 > [2]). By the way, a new version has not been released yet, we'd like to > review that this new feature doesn't have lateral effects; if you have > time to test it, please send us any comment. > > Best regards, > > Carlos Tejo > > [1] > > https://sourceforge.net/tracker/?func=detail&aid=2929881&group_id=217900&atid=1041490 > > [2] > > http://sparql-wrapper.svn.sourceforge.net/viewvc/sparql-wrapper?view=rev&revision=96 > > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > sparql-wrapper-devel mailing list > spa...@li... > https://lists.sourceforge.net/lists/listinfo/sparql-wrapper-devel > |
|
From: Carlos T. <car...@fu...> - 2010-01-11 16:13:49
|
Hi, > thanks you very much to point us such feature in urllib, it's good to > know it while that wrapper strong depends on that library. > > We'll study how to include it, but I agree with you that should be > something optional. Meanwhile you can register it as a feature request > in SourceForge: > > http://sourceforge.net/tracker/?group_id=217900&atid=1041490 This feature has been registered in the tracker [1]. And we already included a draft of how can be implemented (see commit#96 [2]). By the way, a new version has not been released yet, we'd like to review that this new feature doesn't have lateral effects; if you have time to test it, please send us any comment. Best regards, Carlos Tejo [1] https://sourceforge.net/tracker/?func=detail&aid=2929881&group_id=217900&atid=1041490 [2] http://sparql-wrapper.svn.sourceforge.net/viewvc/sparql-wrapper?view=rev&revision=96 |
|
From: Sergio F. <ser...@fu...> - 2010-01-11 09:03:14
|
Dear Pēteris, thanks you very much to point us such feature in urllib, it's good to know it while that wrapper strong depends on that library. We'll study how to include it, but I agree with you that should be something optional. Meanwhile you can register it as a feature request in SourceForge: http://sourceforge.net/tracker/?group_id=217900&atid=1041490 Thanks you very much! Best, On Fri, 2010-01-08 at 13:18 +0000, Pēteris Caune wrote: > Hello, > > > I recently ran into an issue when using SPARQLWrapper on Windows and > executing many queries in quick succession. My script failed with: > > > (...) > File "E:\Python26\lib\site-packages > \sparqlwrapper-1.4.0-py2.6.egg\SPARQLWrappe > r\Wrapper.py", line 343, in query > File "E:\Python26\lib\site-packages > \sparqlwrapper-1.4.0-py2.6.egg\SPARQLWrappe > r\Wrapper.py", line 314, in _query > File "E:\Python26\lib\urllib2.py", line 124, in urlopen > return _opener.open(url, data, timeout) > File "E:\Python26\lib\urllib2.py", line 389, in open > response = self._open(req, data) > File "E:\Python26\lib\urllib2.py", line 407, in _open > '_open', req) > File "E:\Python26\lib\urllib2.py", line 367, in _call_chain > result = func(*args) > File "E:\Python26\lib\urllib2.py", line 1146, in http_open > return self.do_open(httplib.HTTPConnection, req) > File "E:\Python26\lib\urllib2.py", line 1121, in do_open > raise URLError(err) > urllib2.URLError: <urlopen error [Errno 10048] Only one usage > of each socket add > ress (protocol/network address/port) is normally permitted> > > > Googling for the error message turned up the issue([1]). In short, > every request creates a connection and leaves it in TIME_WAIT state, > and after 4000 or so requests client machine runs out of free ports. > The solution is either to tweak Windows Registry to allow more ports > to be used or to use HTTP 1.1 keep-alive. I investigated the second > option a bit, found an example how to do keep-alive with urllib2 > ([2]). So I tried it in practice: installed urlgrabber with > easy_install, put the following lines before class definitions in > Wrapper.py: > > > # Make urllib2 use keep-alive > from urlgrabber.keepalive import HTTPHandler > keepalive_handler = HTTPHandler() > opener = urllib2.build_opener(keepalive_handler) > urllib2.install_opener(opener) > > > Running my script again and monitoring netstat confirmed that now only > a single HTTP connection was used. > Could this feature be somehow optionally integrated in SPARQLWrapper? > Maybe a new method "setUseKeepAlive" (or similar) could be added to > SPARQLWrapper class that executes these lines (if urlgrabber is > available)? Or would this be outside the scope of SPARQLWrapper... I > asume urllib2 needn't be configured right in Wrapper.py, this could > also be done in my client code. > > > Peteris > > > [1] http://blogs.msdn.com/dgorti/archive/2005/09/18/470766.aspx > [2] http://stackoverflow.com/questions/1037406/python-urllib2-with-keep-alive > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ sparql-wrapper-devel mailing list spa...@li... https://lists.sourceforge.net/lists/listinfo/sparql-wrapper-devel -- Sergio Fernández Research Assistant ser...@fu... CTIC - Technological Center Parque Científico y Tecnológico de Gijón C/ Ada Byron, 39 Edificio Centros Tecnológicos 33203 Gijón - Asturias - Spain Phone: +34 984 29 12 12 - Fax: +34 984 39 06 12 www.fundacionctic.org |
|
From: Pēteris C. <cu...@gm...> - 2010-01-08 13:19:01
|
Hello,
I recently ran into an issue when using SPARQLWrapper on Windows and
executing many queries in quick succession. My script failed with:
(...)
File
"E:\Python26\lib\site-packages\sparqlwrapper-1.4.0-py2.6.egg\SPARQLWrappe
r\Wrapper.py", line 343, in query
File
"E:\Python26\lib\site-packages\sparqlwrapper-1.4.0-py2.6.egg\SPARQLWrappe
r\Wrapper.py", line 314, in _query
File "E:\Python26\lib\urllib2.py", line 124, in urlopen
return _opener.open(url, data, timeout)
File "E:\Python26\lib\urllib2.py", line 389, in open
response = self._open(req, data)
File "E:\Python26\lib\urllib2.py", line 407, in _open
'_open', req)
File "E:\Python26\lib\urllib2.py", line 367, in _call_chain
result = func(*args)
File "E:\Python26\lib\urllib2.py", line 1146, in http_open
return self.do_open(httplib.HTTPConnection, req)
File "E:\Python26\lib\urllib2.py", line 1121, in do_open
raise URLError(err)
urllib2.URLError: <urlopen error [Errno 10048] Only one usage of each socket
add
ress (protocol/network address/port) is normally permitted>
Googling for the error message turned up the issue([1]). In short, every
request creates a connection and leaves it in TIME_WAIT state, and after
4000 or so requests client machine runs out of free ports. The solution is
either to tweak Windows Registry to allow more ports to be used or to use
HTTP 1.1 keep-alive. I investigated the second option a bit, found an
example how to do keep-alive with urllib2 ([2]). So I tried it in practice:
installed urlgrabber with easy_install, put the following lines before class
definitions in Wrapper.py:
# Make urllib2 use keep-alive
from urlgrabber.keepalive import HTTPHandler
keepalive_handler = HTTPHandler()
opener = urllib2.build_opener(keepalive_handler)
urllib2.install_opener(opener)
Running my script again and monitoring netstat confirmed that now only a
single HTTP connection was used.
Could this feature be somehow optionally integrated in SPARQLWrapper? Maybe
a new method "setUseKeepAlive" (or similar) could be added to SPARQLWrapper
class that executes these lines (if urlgrabber is available)? Or would this
be outside the scope of SPARQLWrapper... I asume urllib2 needn't be
configured right in Wrapper.py, this could also be done in my client code.
Peteris
[1] http://blogs.msdn.com/dgorti/archive/2005/09/18/470766.aspx
[2]
http://stackoverflow.com/questions/1037406/python-urllib2-with-keep-alive
|
|
From: Carlos T. <car...@fu...> - 2009-12-14 12:04:27
|
We've just publish a new release of the Python SPARQL Wrapper, we it has been added some suport for SPARUL, improved HTTP related code and fixed many other minor bugs and issues. New packages have been uploaded to SourceForge [1] and to PyPI [2] for installing with easy install; on Debian package will be available in the following days. The documentation of the library has been also properly updated [3]. Thanks a lot for the feedback provided that encourage us to do that changes. If you find any issue with this new release, please don't hesitate to contact us. Best regards, Carlos Tejo [1] http://sourceforge.net/projects/sparql-wrapper/files [2] http://pypi.python.org/pypi/SPARQLWrapper/1.4.0 [3] http://sparql-wrapper.sourceforge.net/resources/doc/ |
|
From: Carlos T. <car...@fu...> - 2009-09-14 12:04:47
|
We've just publish a new release of the Python SPARQL Wrapper, removing simplejson dependency for python >=2.6 and adding a feature to allow developers to use their prefer json module. New packages have been uploaded to SourceForge [1] and to PyPI [2] for installing with easy install; on Debian package will be available in the following days. The documentation of the library has been also properly updated [3]. Thanks a lot for the feedback provided that encourage us to do that changes. If you find any issue with this new release, please don't hesitate to contact us. Best regards, Carlos Tejo [1] http://sourceforge.net/projects/sparql-wrapper/files [2] http://pypi.python.org/pypi/SPARQLWrapper/1.3.1 [3] http://sparql-wrapper.sourceforge.net/resources/doc/ |
|
From: Carlos T. <car...@fu...> - 2009-09-11 11:03:57
|
> I have not tested it, but isn't it possible to modify the setup.py file? > There is a line that lists the packages; that entry could be made > dependent on the version of python, using the > > if sys.version_info[0:2] >= (2, 6): > Finally, we have patched it in r74. (SPARQLWrapper v1.3.1) Rigth now, simplejson is not needed when your version of python is >=2.6 We will try to add the option to choose the json library to use. This issue in the roadmap Regards, Carlos Tejo |
|
From: Carlos T. A. <car...@fu...> - 2009-09-10 15:16:11
|
Hi, Yes. That's true. Have you ever tried the optional C extension for a serious speed boost in simplejson (v2.0.9)? Maybe the performance is better with that. CJSON is a module written in C, that's the reason of the better speed performance. We will think about add cjson as module in sparql-wrapper so developer can choose which json module prefers. Any suggestion about how to do it? Regards, Carlos Tejo -----Mensaje original----- De: Peteris Caune [mailto:cu...@gm...] Enviado el: jue 10/09/2009 16:23 Para: spa...@li... Asunto: Re: [sparql-wrapper-devel] Followup: Support cjson in SparqlWrapper Fair enough. My reason for suggesting cjson was performance, cjson is 10 or more times faster. I'll continue using my locally patched version of sparql-wrapper -- my app is juggling with big responses from SPARQL endpoint and performance improvement when using cjson is significant. Peteris 2009/9/10 Carlos Tejo <car...@fu...> > Sveiki Peteris! > > > Today I learned that json module that ships with Python 2.6 is based > > on simplejson, so SparqlWrapper would benefit from using cjson on 2.6 > > as well. Here's revised _convertJSON function: > > Thanks for your emails. > > I was reading about JSON modules in Python, at it looks like a > religion-war. Some people prefers cjson, other people prefers > simplejson, and evens other prefers other modules. > > I have checked the date of the last versions of each module, and cjson > looks like a frozen project since 2007 [1], and simplejson is still > alive (at least, the last version is dated in 2009 [2]). > > And as json is native since Python 2.6, we think that we could continue > using simplejson. > > If you had any suggestion, please, don't hesitate to contact us by email > list :-) > > Regards, > > > Carlos Tejo > > PS. Sorry for the late reply, we were on holidays > > [1] http://pypi.python.org/pypi/python-cjson > [2] http://pypi.python.org/pypi/simplejson > > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > sparql-wrapper-devel mailing list > spa...@li... > https://lists.sourceforge.net/lists/listinfo/sparql-wrapper-devel > |
|
From: Pēteris C. <cu...@gm...> - 2009-09-10 14:23:17
|
Fair enough. My reason for suggesting cjson was performance, cjson is 10 or more times faster. I'll continue using my locally patched version of sparql-wrapper -- my app is juggling with big responses from SPARQL endpoint and performance improvement when using cjson is significant. Pēteris 2009/9/10 Carlos Tejo <car...@fu...> > Sveiki Pēteris! > > > Today I learned that json module that ships with Python 2.6 is based > > on simplejson, so SparqlWrapper would benefit from using cjson on 2.6 > > as well. Here's revised _convertJSON function: > > Thanks for your emails. > > I was reading about JSON modules in Python, at it looks like a > religion-war. Some people prefers cjson, other people prefers > simplejson, and evens other prefers other modules. > > I have checked the date of the last versions of each module, and cjson > looks like a frozen project since 2007 [1], and simplejson is still > alive (at least, the last version is dated in 2009 [2]). > > And as json is native since Python 2.6, we think that we could continue > using simplejson. > > If you had any suggestion, please, don't hesitate to contact us by email > list :-) > > Regards, > > > Carlos Tejo > > PS. Sorry for the late reply, we were on holidays > > [1] http://pypi.python.org/pypi/python-cjson > [2] http://pypi.python.org/pypi/simplejson > > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > sparql-wrapper-devel mailing list > spa...@li... > https://lists.sourceforge.net/lists/listinfo/sparql-wrapper-devel > |
|
From: Carlos T. <car...@fu...> - 2009-09-10 13:59:49
|
Sveiki Pēteris! > Today I learned that json module that ships with Python 2.6 is based > on simplejson, so SparqlWrapper would benefit from using cjson on 2.6 > as well. Here's revised _convertJSON function: Thanks for your emails. I was reading about JSON modules in Python, at it looks like a religion-war. Some people prefers cjson, other people prefers simplejson, and evens other prefers other modules. I have checked the date of the last versions of each module, and cjson looks like a frozen project since 2007 [1], and simplejson is still alive (at least, the last version is dated in 2009 [2]). And as json is native since Python 2.6, we think that we could continue using simplejson. If you had any suggestion, please, don't hesitate to contact us by email list :-) Regards, Carlos Tejo PS. Sorry for the late reply, we were on holidays [1] http://pypi.python.org/pypi/python-cjson [2] http://pypi.python.org/pypi/simplejson |
|
From: Ivan H. <iv...@w3...> - 2009-08-15 12:44:48
|
Carlos, I have not tested it, but isn't it possible to modify the setup.py file? There is a line that lists the packages; that entry could be made dependent on the version of python, using the if sys.version_info[0:2] >= (2, 6): idiom? Ivan Carlos Tejo Alonso wrote: > We have received this feedback from Bruce D'Arcus and we would like to > share it. > >>> Quick comment after easy installing SPARQLWrapper: >>> >>> It installs simplejson, even though it's already in the standard >>> library (2.6 and later). Can you perhaps change that so it uses json >>> if present, and otherwise imports simplejson as "json"? >>> >>> Bruce >>> >> >> When you install sparql-wrapper, simplejson is downloaded, even when it >> is not needed (python version 2.6). >> >> But, right now, we have handle the use of the correct library >> > http://sourceforge.net/tracker/?func=detail&aid=2781984&group_id=217900&atid=1041487 > <http://sourceforge.net/tracker/?func=detail&aid=2781984&group_id=217900&atid=1041487> >> >> AFAIK, it is not possible to choose the library to download using the >> python version. > > Somebody knows how can avoid the download of simplejson if the version > of python is over 2.6 (using setuptools)? > > Regards, > > Carlos Tejo > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > > > ------------------------------------------------------------------------ > > _______________________________________________ > sparql-wrapper-devel mailing list > spa...@li... > https://lists.sourceforge.net/lists/listinfo/sparql-wrapper-devel -- Ivan Herman, W3C Semantic Web Activity Lead Home: http://www.w3.org/People/Ivan/ mobile: +31-641044153 PGP Key: http://www.ivan-herman.net/pgpkey.html FOAF: http://www.ivan-herman.net/foaf.rdf |
|
From: Pēteris C. <cu...@gm...> - 2009-08-13 11:24:18
|
Hi again,
Today I learned that json module that ships with Python 2.6 is based on
simplejson, so SparqlWrapper would benefit from using cjson on 2.6 as well.
Here's revised _convertJSON function:
def _convertJSON(self) :
"""
Convert a JSON result into a Python dict. This method can be
overwritten in a subclass
for a different conversion method.
@return: converted result
@rtype: Python dictionary
"""
# Try to use cjson module
try:
import cjson
return cjson.decode(self.response.read())
except ImportError:
pass
# If Python 2.6, use json module
if sys.version_info[0:2] >= (2, 6):
import json
return json.load(self.response)
# Fall back to simplejson
import simplejson
return simplejson.load(self.response)
2009/8/12 Pēteris Caune <cu...@gm...>
> Hi,
>
> I noticed that on python 2.5 SparqlWrapper uses simplejson even when cjson
> is available. With bigger JSON messages in response the performance hit is
> quite significant. I propose to extend QueryResult's _convertJSON to support
> cjson. My take:
>
> def _convertJSON(self) :
> """
> Convert a JSON result into a Python dict. This method can be
> overwritten in a subclass
> for a different conversion method.
> @return: converted result
> @rtype: Python dictionary
> """
>
> # If running on python 2.6, use json module
> if sys.version_info[0:2] >= (2, 6):
> import json
> return json.load(self.response)
>
> # If running on python 2.5, try to use cjson module
> if sys.version_info[0:2] == (2, 5):
> try:
> import cjson
> return cjson.decode(self.response.read())
> except ImportError:
> pass
>
> # Fall back to simplejson
> import simplejson
> return simplejson.load(self.response)
>
> Best regards,
> Peteris Caune
>
|
|
From: Pēteris C. <cu...@gm...> - 2009-08-12 14:42:27
|
Hi,
I noticed that on python 2.5 SparqlWrapper uses simplejson even when cjson
is available. With bigger JSON messages in response the performance hit is
quite significant. I propose to extend QueryResult's _convertJSON to support
cjson. My take:
def _convertJSON(self) :
"""
Convert a JSON result into a Python dict. This method can be
overwritten in a subclass
for a different conversion method.
@return: converted result
@rtype: Python dictionary
"""
# If running on python 2.6, use json module
if sys.version_info[0:2] >= (2, 6):
import json
return json.load(self.response)
# If running on python 2.5, try to use cjson module
if sys.version_info[0:2] == (2, 5):
try:
import cjson
return cjson.decode(self.response.read())
except ImportError:
pass
# Fall back to simplejson
import simplejson
return simplejson.load(self.response)
Best regards,
Peteris Caune
|
|
From: Carlos T. A. <car...@fu...> - 2009-08-10 19:40:39
|
We have received this feedback from Bruce D'Arcus and we would like to share it. >> Quick comment after easy installing SPARQLWrapper: >> >> It installs simplejson, even though it's already in the standard >> library (2.6 and later). Can you perhaps change that so it uses json >> if present, and otherwise imports simplejson as "json"? >> >> Bruce >> > > When you install sparql-wrapper, simplejson is downloaded, even when it > is not needed (python version 2.6). > > But, right now, we have handle the use of the correct library > http://sourceforge.net/tracker/?func=detail&aid=2781984&group_id=217900&atid=1041487 > > AFAIK, it is not possible to choose the library to download using the > python version. Somebody knows how can avoid the download of simplejson if the version of python is over 2.6 (using setuptools)? Regards, Carlos Tejo |
|
From: Sergio F. <ser...@fu...> - 2009-05-06 08:56:42
|
We've just publish a new release of the Python SPARQL Wrapper, including a new interface to add custom parameters that deprecates the old one (see feature request #2786514 for more details [1]). New packages have been uploaded to SourceForge [2] and to PyPI [3] for installing with easy install; on Debian package will be available in the following days. The documentation of the library has been also properly updated [4]. If you find any issue with this new release, please don't hesitate to contact us. Best regards, [1] http://sparql-wrapper.sourceforge.net/freq/2786514 [2] http://sourceforge.net/projects/sparql-wrapper/files [3] http://pypi.python.org/pypi/SPARQLWrapper/1.3.0 [4] http://sparql-wrapper.sourceforge.net/resources/doc/ -- Sergio Fernández - ser...@fu... R&D Deparment CTIC Foundation - www.fundacionctic.org Phone: +34 984 29 12 12 Fax: +34 984 39 06 12 Edificio Centros Tecnológicos Parque Científico Tecnológico 33203 Cabueñes - Gijón - Asturias - Spain |
|
From: Sergio F. <ser...@fu...> - 2009-05-06 08:12:15
|
William Waites (CCed) suggested to us to add authentication capabilities to the wrapper. He also submitted a prelimiar patch of how to do it with urllib2. Everything is registedred in the tracker: http://sparql-wrapper.sourceforge.net/freq/2787714 This feature is really interesting, but too complex and comes too late to be part of the release that we'll release during this morning. We'll start to work to have it in future releases. Thanks again to William Waites for his contribution. Cheers, William Waites wrote: > > Anyhow I've made a small modification to the library > to be able to use authenticated SPARQL endpoints such > as that that comes with virtuoso -- for doing INSERTS > and such. > > Patch attached. > > Cheers, > -w > -- Sergio Fernández - ser...@fu... R&D Deparment CTIC Foundation - www.fundacionctic.org Phone: +34 984 29 12 12 Fax: +34 984 39 06 12 Edificio Centros Tecnológicos Parque Científico Tecnológico 33203 Cabueñes - Gijón - Asturias - Spain |
|
From: Sergio F. <ser...@fu...> - 2009-05-05 14:33:25
|
Feature implemented in commit #70. If we don't find any issue, tomorrow I'll prepare a new release. Cheers, -- Sergio Fernández - ser...@fu... R&D Deparment CTIC Foundation - www.fundacionctic.org Phone: +34 984 29 12 12 Fax: +34 984 39 06 12 Edificio Centros Tecnológicos Parque Científico Tecnológico 33203 Cabueñes - Gijón - Asturias - Spain |
|
From: Ivan H. <iv...@w3...> - 2009-05-05 11:55:26
|
Sergio Fernández wrote: > On Tue, 2009-05-05 at 11:52 +0200, Ivan Herman wrote: >> I must admit I forgot about this, too. > > :-) > >> However... if it is there, what >> would be the reason of changing anything? The functionality is there, >> some people may use it (we don't know how many), so... as the Americans >> say: "ain't broken, don't fix it" :-) > > That's true, but... I've some reasons: > > 1) I've to admit that the current nomenclature looks not so clear, the > best example is that I didn't find it looking the documentation. > > 2) I don't really like the implementation, because it directly stores > the parameters url-encoded. IMO that format just be the final form that > it should take. > > 3) Currently the wrapper has two method (addDefaultGraph and > addNamedGraph) about non-standard features. > > I've the new implementation almost done, so if you agree, this is my > proposal: add the new implementation under a clearer name > (addCustomParameter, for instance), keep all old methods > (addExtraURITag, addDefaultGraph and addNamedGraph) changing their > implementation to use the new one, and mark that methods as deprecated > to be able to drop it in some future moment. What do you think? Ok. Go!:-) Ivan > > Cheers, > -- Ivan Herman, W3C Semantic Web Activity Lead Home: http://www.w3.org/People/Ivan/ mobile: +31-641044153 PGP Key: http://www.ivan-herman.net/pgpkey.html FOAF: http://www.ivan-herman.net/foaf.rdf |
|
From: Sergio F. <ser...@fu...> - 2009-05-05 11:06:17
|
On Tue, 2009-05-05 at 11:52 +0200, Ivan Herman wrote: > I must admit I forgot about this, too. :-) > However... if it is there, what > would be the reason of changing anything? The functionality is there, > some people may use it (we don't know how many), so... as the Americans > say: "ain't broken, don't fix it" :-) That's true, but... I've some reasons: 1) I've to admit that the current nomenclature looks not so clear, the best example is that I didn't find it looking the documentation. 2) I don't really like the implementation, because it directly stores the parameters url-encoded. IMO that format just be the final form that it should take. 3) Currently the wrapper has two method (addDefaultGraph and addNamedGraph) about non-standard features. I've the new implementation almost done, so if you agree, this is my proposal: add the new implementation under a clearer name (addCustomParameter, for instance), keep all old methods (addExtraURITag, addDefaultGraph and addNamedGraph) changing their implementation to use the new one, and mark that methods as deprecated to be able to drop it in some future moment. What do you think? Cheers, -- Sergio Fernández - ser...@fu... R&D Deparment CTIC Foundation - www.fundacionctic.org Phone: +34 984 29 12 12 Fax: +34 984 39 06 12 Edificio Centros Tecnológicos Parque Científico Tecnológico 33203 Cabueñes - Gijón - Asturias - Spain |
|
From: Ivan H. <iv...@w3...> - 2009-05-05 09:53:22
|
Hi Sergio,
I must admit I forgot about this, too. However... if it is there, what
would be the reason of changing anything? The functionality is there,
some people may use it (we don't know how many), so... as the Americans
say: "ain't broken, don't fix it" :-)
I may miss something here, though.
Ivan
Sergio Fernández wrote:
> On Mon, 2009-05-04 at 13:18 +0200, Ivan Herman wrote:
>> Sounds like a good idea!
>
> Actually it looks closely at the method addExtraURITag():
>
> def addExtraURITag(self,key,value) :
> """
> Some SPARQL endpoints require extra key value pairs.
> E.g., in virtuoso, one would add C{should-sponge=soft}
> to the query forcing virtuoso to retrieve graphs that
> are not stored in its local database.
> @param key: key of the query part
> @type key: string
> @param value: value of the query part
> @type value: string
> """
> self._querytext.append((key,value))
>
> I don't remeber that we already have it in the wrapper. That _querytext
> is appended before make the http request. And addDefaultGraph() and
> addNamedGraph() methods internally use it.
>
> So... I can manage to do want I want with the current API. But, do we
> want to keep the current API or do we want to change it? I'm not sure if
> people is using addExtraURITag()... and I'm not sure which one shoud be
> easier to use.
>
> Ivan, carlos, what do you think?
>
> Cheers,
>
--
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf
|
|
From: Carlos T. A. <car...@fu...> - 2009-05-05 09:42:35
|
Hello,
> Actually it looks closely at the method addExtraURITag():
>
> def addExtraURITag(self,key,value) :
> """
> Some SPARQL endpoints require extra key value pairs.
> E.g., in virtuoso, one would add C{should-sponge=soft}
> to the query forcing virtuoso to retrieve graphs that
> are not stored in its local database.
> @param key: key of the query part
> @type key: string
> @param value: value of the query part
> @type value: string
> """
> self._querytext.append((key,value))
>
> I don't remeber that we already have it in the wrapper. That
> _querytext
> is appended before make the http request. And addDefaultGraph() and
> addNamedGraph() methods internally use it.
>
> So... I can manage to do want I want with the current API. But, do we
> want to keep the current API or do we want to change it? I'm
> not sure if
> people is using addExtraURITag()... and I'm not sure which
> one shoud be
> easier to use.
>
> Ivan, carlos, what do you think?
IMHO, we could do Sergio's idea, so we can create a new method that MUST
be called by addExtraURITag and marks addExtraURITag method as
deprecated.
Regards,
-------------------------------------
Carlos Tejo Alonso
Research & Development Department
CTIC Foundation [Asturias, Spain]
www.fundacionctic.org
-------------------------------------
|
|
From: Sergio F. <ser...@fu...> - 2009-05-05 08:49:26
|
On Mon, 2009-05-04 at 13:18 +0200, Ivan Herman wrote:
> Sounds like a good idea!
Actually it looks closely at the method addExtraURITag():
def addExtraURITag(self,key,value) :
"""
Some SPARQL endpoints require extra key value pairs.
E.g., in virtuoso, one would add C{should-sponge=soft}
to the query forcing virtuoso to retrieve graphs that
are not stored in its local database.
@param key: key of the query part
@type key: string
@param value: value of the query part
@type value: string
"""
self._querytext.append((key,value))
I don't remeber that we already have it in the wrapper. That _querytext
is appended before make the http request. And addDefaultGraph() and
addNamedGraph() methods internally use it.
So... I can manage to do want I want with the current API. But, do we
want to keep the current API or do we want to change it? I'm not sure if
people is using addExtraURITag()... and I'm not sure which one shoud be
easier to use.
Ivan, carlos, what do you think?
Cheers,
--
Sergio Fernández - ser...@fu...
R&D Deparment
CTIC Foundation - www.fundacionctic.org
Phone: +34 984 29 12 12
Fax: +34 984 39 06 12
Edificio Centros Tecnológicos
Parque Científico Tecnológico
33203 Cabueñes - Gijón - Asturias - Spain
|
|
From: Ivan H. <iv...@w3...> - 2009-05-04 11:19:11
|
Sounds like a good idea! Ivan Sergio Fernández wrote: > Hi, > > Some SPARQL end-points allow to pass custom parameter (for instance, > sponger in virtuoso). That parameters can't be used with the current API > provided by the wrapper. I already registered this feature request: > > http://sparql-wrapper.sourceforge.net/freq/2786514 > > Since this kind of things are outside of the standard, I suggest that > the best thing that we should do is to add a generic interface to allow > users of the wrapper to set these custom parameters. Something like: > > sparql.addCustomParameter(name, value) > > Obviously filtering parameters already defined by the current standard > for the HTTP communication (such as "query"). > > If everybody agree with this feature could be interesting, I'll take > care of it during this week. > > Cheers, > -- Ivan Herman, W3C Semantic Web Activity Lead Home: http://www.w3.org/People/Ivan/ mobile: +31-641044153 PGP Key: http://www.ivan-herman.net/pgpkey.html FOAF: http://www.ivan-herman.net/foaf.rdf |
|
From: Sergio F. <ser...@fu...> - 2009-05-04 10:34:46
|
Hi, Some SPARQL end-points allow to pass custom parameter (for instance, sponger in virtuoso). That parameters can't be used with the current API provided by the wrapper. I already registered this feature request: http://sparql-wrapper.sourceforge.net/freq/2786514 Since this kind of things are outside of the standard, I suggest that the best thing that we should do is to add a generic interface to allow users of the wrapper to set these custom parameters. Something like: sparql.addCustomParameter(name, value) Obviously filtering parameters already defined by the current standard for the HTTP communication (such as "query"). If everybody agree with this feature could be interesting, I'll take care of it during this week. Cheers, -- Sergio Fernández - ser...@fu... R&D Deparment CTIC Foundation - www.fundacionctic.org Phone: +34 984 29 12 12 Fax: +34 984 39 06 12 Edificio Centros Tecnológicos Parque Científico Tecnológico 33203 Cabueñes - Gijón - Asturias - Spain |
|
From: Sergio F. <ser...@fu...> - 2009-04-27 10:37:49
|
Hi, we've just released version 1.2.1 that fixes the issue with JSON with Python >= 2.6. You can download the new release directly from SourceForge [1] or from PyPi using EasyInstall [2]. Thanks Arthur for the pointer to JSON issue, and thanks to Carlos for his work on the setuptools usage improvements done in this release. Best, [1] http://sourceforge.net/projects/sparql-wrapper/files [2] http://pypi.python.org/pypi/SPARQLWrapper -- Sergio Fernández - ser...@fu... R&D Deparment CTIC Foundation - www.fundacionctic.org Phone: +34 984 29 12 12 Fax: +34 984 39 06 12 Edificio Centros Tecnológicos Parque Científico Tecnológico 33203 Cabueñes - Gijón - Asturias - Spain |
8 messages has been excluded from this view by a project administrator.
