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: Sergio F. <ser...@fu...> - 2009-04-27 09:01:32
|
On Mon, 2009-04-27 at 00:02 +0200, Obey Arthur Liu wrote: > SPARQLWrapper doesn't work with Python 2.6+ because simplejson is now > integrated into the standard library and renamed 'json'. SPARQLWrapper > should probably rely on the standard library instead of on a legacy > library when run with python 2.6+. Thanks a lot for the pointer, Arthur; we didn't know such as change on the package name. Based on your patch, I fix the code and now it properly works on python 2.6. I tested with the example at the webpage and works fine. Everything is stored in the bug report [1]. During the day we'll publish a new release solving that issue. Cheers, [1] http://sparql-wrapper.sourceforge.net/bugs/2781984 -- 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-04-27 08:27:09
|
Thanks a lot Arthur! We will have to make an update with that soon. Sincerely Ivan Obey Arthur Liu wrote: > Hi, > > SPARQLWrapper doesn't work with Python 2.6+ because simplejson is now > integrated into the standard library and renamed 'json'. SPARQLWrapper > should probably rely on the standard library instead of on a legacy > library when run with python 2.6+. > > I attached a patch to detect this. > > Cheers > > Arthur > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensign option that enables unlimited > royalty-free distribution of the report engine for externally facing > server and web deployment. > http://p.sf.net/sfu/businessobjects > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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: Obey A. L. <ar...@mi...> - 2009-04-26 22:19:39
|
Hi, SPARQLWrapper doesn't work with Python 2.6+ because simplejson is now integrated into the standard library and renamed 'json'. SPARQLWrapper should probably rely on the standard library instead of on a legacy library when run with python 2.6+. I attached a patch to detect this. Cheers Arthur -- Obey Arthur Liu <http://www.milliways.fr> |
|
From: Niklas L. <lin...@gm...> - 2009-03-13 23:21:05
|
On Fri, Mar 13, 2009 at 12:15 PM, Sergio Fernández <ser...@fu...> wrote: > > I'm not sure if I undestood your question... but the wrapper will > request xml is you set it before make the query: > > sparql.setReturnFormat(XML) > > That will parse the results returned as XML and return and instance with > a DOM document (xml.dom python module). Personally I prefer JSON while > is easier to use it. Ah, yes; but I was thinking of a feature to convert XML results to a python dictionary looking just like the one resulting from simplejson parsing SPARQL-JSON. Which I agree it's much easier to use. :) Anyway it's not critical for me, and if it'll become so I'll take a stab at it (probably using the elementtree stream API or similar). But I wonder if you find such a feature (returning a similar object, i.e. dict, regardless of result format) suitable for the sparql-wrapper? If not I'll probably put it in the SPARQLTree code base (which is probably good since it is about transforming results anyway). (And as said, I agree with your concerns and I intend move the use of SPARQLWrapper from the core, to make that independent of execution method (in a step towards e.g. using rdflib sparql results in-process as well).) Best regards, Niklas |
|
From: Sergio F. <ser...@fu...> - 2009-03-13 11:16:03
|
On Fri, 2009-03-13 at 11:45 +0100, Niklas Lindström wrote: > I certainly agree. `oort.sparqltree.autotree` contains a > `treeify_results` function which in *theory* should be used for any > results (not the least RDFLib-results, which is next on my schedule; > to handle direct "rdf-source->sparql->tree" processing). But I had the > intent of actually asking you if SparqlWrapper can be used to > "massage" xml-results as well into a python object, isomorphic to the > parsed JSON object? Currently, sparqltree can't use XML-only endpoints > directly (since it receives a pyxml-object in those cases). I'm not sure if I undestood your question... but the wrapper will request xml is you set it before make the query: sparql.setReturnFormat(XML) That will parse the results returned as XML and return and instance with a DOM document (xml.dom python module). Personally I prefer JSON while is easier to use it. Best, -- 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: Niklas L. <lin...@gm...> - 2009-03-13 10:45:23
|
Hi Sergio, all, I certainly agree. `oort.sparqltree.autotree` contains a `treeify_results` function which in *theory* should be used for any results (not the least RDFLib-results, which is next on my schedule; to handle direct "rdf-source->sparql->tree" processing). But I had the intent of actually asking you if SparqlWrapper can be used to "massage" xml-results as well into a python object, isomorphic to the parsed JSON object? Currently, sparqltree can't use XML-only endpoints directly (since it receives a pyxml-object in those cases). Your point is still very valid of course, but perhaps this "parse results to the same kind of object" could be delegated to SparqlWrapper (or split out to a small module of its own)? In any case, sparqltree should as you say be usable with any form query execution the user requires. SPARQLTree is still very young, so I'd love more feedback if you give it a go. And thanks for SparqlWrapper! Best regards, Niklas On Fri, Mar 13, 2009 at 11:14 AM, Sergio Fernández <ser...@fu...> wrote: > Nice idea about how to manage the SPARQL result vocabulary. > > When I looked it to see how it could handler the output ot the > SPARQLWrapper, I discovered that actually it internally uses the > wrapper: > > http://code.google.com/p/oort/source/browse/SparqlTree/trunk/python/oort/sparqltree/autotree.py > > Personally I think that it'd be better to do delegate the query > execution (in any library) and just use something like SPARQLTree to > parse the output of the query. I CCed the author of SPARQLTree to > discuss this. > > Anyway it's always nice to see how the wrapper is starting to be used by > the SemWeb community :-) > > Best, > > > -------- Forwarded Message -------- > From: Niklas Lindström <lin...@gm...> > To: Semantic Web <sem...@w3...> > Subject: ANN: SPARQLTree > Date: Thu, 12 Mar 2009 20:32:36 +0100 > > Dear all, > > I'm happy to announce SPARQLTree [1]: a solution for turning > SPARQL-results into more manageable trees of data. If you find > regular, "flat" SPARQL results cumbersome to work with, this might be > for you. > > SPARQLTree uses a simple convention on variable names, which are > grouped together into "condensed" object trees, suitable for common > ("OO") programming languages to handle efficiently (think JSON). > > The current implementation is in Python, which can be used > programmatically, or to convert regular results on the fly into > "idiomatic" JSON, intended to be much easier to work with. > > This solution is very lightweight, so I expect porting the core (~60 > lines of Python) to other languages will be straightforward. There is > also an implementation in XSLT (+ a dash of exslt) which uses a mix of > "SPARQL in XML" to achieve a similar result (but in "raw" XML). > > Read the initial documentation at [1], and continue to check out the > source repository [2] to get a sense of the details. > > I'd love to hear comments, opinions and feature requests. Either here > (if appropriate), to the Oort google group [3], or to me personally. > > Best regards, > Niklas Lindström > > [1] <http://code.google.com/p/oort/wiki/SparqlTree> > [2] <http://code.google.com/p/oort/source/browse/SparqlTree/trunk/> > [3] <http://groups.google.com/group/oort> > > > -- > 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-03-13 10:14:41
|
Nice idea about how to manage the SPARQL result vocabulary. When I looked it to see how it could handler the output ot the SPARQLWrapper, I discovered that actually it internally uses the wrapper: http://code.google.com/p/oort/source/browse/SparqlTree/trunk/python/oort/sparqltree/autotree.py Personally I think that it'd be better to do delegate the query execution (in any library) and just use something like SPARQLTree to parse the output of the query. I CCed the author of SPARQLTree to discuss this. Anyway it's always nice to see how the wrapper is starting to be used by the SemWeb community :-) Best, -------- Forwarded Message -------- From: Niklas Lindström <lin...@gm...> To: Semantic Web <sem...@w3...> Subject: ANN: SPARQLTree Date: Thu, 12 Mar 2009 20:32:36 +0100 Dear all, I'm happy to announce SPARQLTree [1]: a solution for turning SPARQL-results into more manageable trees of data. If you find regular, "flat" SPARQL results cumbersome to work with, this might be for you. SPARQLTree uses a simple convention on variable names, which are grouped together into "condensed" object trees, suitable for common ("OO") programming languages to handle efficiently (think JSON). The current implementation is in Python, which can be used programmatically, or to convert regular results on the fly into "idiomatic" JSON, intended to be much easier to work with. This solution is very lightweight, so I expect porting the core (~60 lines of Python) to other languages will be straightforward. There is also an implementation in XSLT (+ a dash of exslt) which uses a mix of "SPARQL in XML" to achieve a similar result (but in "raw" XML). Read the initial documentation at [1], and continue to check out the source repository [2] to get a sense of the details. I'd love to hear comments, opinions and feature requests. Either here (if appropriate), to the Oort google group [3], or to me personally. Best regards, Niklas Lindström [1] <http://code.google.com/p/oort/wiki/SparqlTree> [2] <http://code.google.com/p/oort/source/browse/SparqlTree/trunk/> [3] <http://groups.google.com/group/oort> -- 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: Zach D. <zd...@gm...> - 2009-03-06 15:32:46
|
The response from the Joseki team.
---------- Forwarded message ----------
From: Seaborne, Andy <and...@hp...>
Date: Mar 6, 2009 9:14 AM
Subject: Re: [Jena-devel] [sparql-wrapper-devel] SPARQL/Update http post
parameter
To: Sergio Fernández <ser...@fu...>, "
spa...@li..." <
spa...@li...>, Ivan Herman <iv...@w3...>
Cc: "jen...@li..." <jen...@li...>
Zach - many thanks for the patch. If there are no side-effects to existing
installations, I'll probably incorporate it. I happen to think split
update/query is better as discussed below.
> -----Original Message-----
> From: Sergio Fernández [mailto:ser...@fu...]
> Sent: 06 March 2009 08:36
> To: spa...@li...
> Cc: jen...@li...
> Subject: Re: [Jena-devel] [sparql-wrapper-devel] SPARQL/Update http post
> parameter
>
> On Thu, 2009-03-05 at 23:21 -0600, Zach Dwiel wrote:
> > I'm trying to use the python-sparqlwrapper library to run
> > SPARQL/Update operations. In the sparql-wrapper code, the update
> > query is bound to the 'query' parameter in the HTML post. In Joseki's
> > implementation, the query is expected to be bound to the parameter
> > 'request'.
>
> AFAIK, SPARUL [1] is just an extension for SPARQL Query Language [2].
> The name of that HTTP parameter is defined by other specification, the
> SPARQL protocol [3].
Not quite true I'm afraid - it might so that way. It's a separate language
with it's own characteristics reusing the syntax of SPARQL. It may end up
merged in to SPARQL, it may end up as separate language along side the query
language. In ARQ, it's one parser but separate entry points.
Using "request=" is a device to distinguish request to the same endpoint
although I recommend not having the query and update on the same URL but
treat them as separate services over the same datastore. As two endpoints,
the security mechanaism of whatever web container is being used can be
applied to incoming HTPP requests. At least with parameter names, the
service can switch before having to parse (Example1: a large update from a
know source is reasonable but might want to limit the incoming size of
general queries. Example2: a machine that does not request the query but
forwards it as a gateway to a backend system)
The protocol design was in early versions of SPARQL/Update but there was
more debate in that area - there were good points about how best to do this
in web architecture - so we focused on the language part which is useful in
its own right.
My hope is that the newly started working group will quickly establish which
direction to go in.
Andy
(I'm not on spa...@li... - could someone
please forward this message? Thanks).
>
> > Otherwise, maybe something could be changed on the sparql-wrapper side
> > to make this possible. Previously, I have dealt with this by changing
> > the library to make the query parameter changable ... What do you
> > think?
>
> While the wrapper uses the mandatory name, I don't want to patch that
> side. But I think it would be nice to propose your patch to Joseki guys,
> in order to align it with other implementations.
>
> Cheers,
>
> [1] http://www.w3.org/Submission/2008/SUBM-SPARQL-Update-20080715/
> [2] http://www.w3.org/TR/rdf-sparql-query/
> [3] http://www.w3.org/TR/rdf-sparql-protocol/
>
> --
> 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
>
>
>
----------------------------------------------------------------------------
> --
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco,
CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the
Enterprise
> -Strategies to boost innovation and cut costs with open source
participation
> -Receive a $600 discount off the registration fee with the source code:
SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Jena-devel mailing list
> Jen...@li...
> https://lists.sourceforge.net/lists/listinfo/jena-devel
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Jena-devel mailing list
Jen...@li...
https://lists.sourceforge.net/lists/listinfo/jena-devel
|
|
From: Seaborne, A. <and...@hp...> - 2009-03-06 15:15:18
|
Zach - many thanks for the patch. If there are no side-effects to existing installations, I'll probably incorporate it. I happen to think split update/query is better as discussed below. > -----Original Message----- > From: Sergio Fernández [mailto:ser...@fu...] > Sent: 06 March 2009 08:36 > To: spa...@li... > Cc: jen...@li... > Subject: Re: [Jena-devel] [sparql-wrapper-devel] SPARQL/Update http post > parameter > > On Thu, 2009-03-05 at 23:21 -0600, Zach Dwiel wrote: > > I'm trying to use the python-sparqlwrapper library to run > > SPARQL/Update operations. In the sparql-wrapper code, the update > > query is bound to the 'query' parameter in the HTML post. In Joseki's > > implementation, the query is expected to be bound to the parameter > > 'request'. > > AFAIK, SPARUL [1] is just an extension for SPARQL Query Language [2]. > The name of that HTTP parameter is defined by other specification, the > SPARQL protocol [3]. Not quite true I'm afraid - it might so that way. It's a separate language with it's own characteristics reusing the syntax of SPARQL. It may end up merged in to SPARQL, it may end up as separate language along side the query language. In ARQ, it's one parser but separate entry points. Using "request=" is a device to distinguish request to the same endpoint although I recommend not having the query and update on the same URL but treat them as separate services over the same datastore. As two endpoints, the security mechanaism of whatever web container is being used can be applied to incoming HTPP requests. At least with parameter names, the service can switch before having to parse (Example1: a large update from a know source is reasonable but might want to limit the incoming size of general queries. Example2: a machine that does not request the query but forwards it as a gateway to a backend system) The protocol design was in early versions of SPARQL/Update but there was more debate in that area - there were good points about how best to do this in web architecture - so we focused on the language part which is useful in its own right. My hope is that the newly started working group will quickly establish which direction to go in. Andy (I'm not on spa...@li... - could someone please forward this message? Thanks). > > > Otherwise, maybe something could be changed on the sparql-wrapper side > > to make this possible. Previously, I have dealt with this by changing > > the library to make the query parameter changable ... What do you > > think? > > While the wrapper uses the mandatory name, I don't want to patch that > side. But I think it would be nice to propose your patch to Joseki guys, > in order to align it with other implementations. > > Cheers, > > [1] http://www.w3.org/Submission/2008/SUBM-SPARQL-Update-20080715/ > [2] http://www.w3.org/TR/rdf-sparql-query/ > [3] http://www.w3.org/TR/rdf-sparql-protocol/ > > -- > 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 > > > ---------------------------------------------------------------------------- > -- > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Jena-devel mailing list > Jen...@li... > https://lists.sourceforge.net/lists/listinfo/jena-devel |
|
From: Sergio F. <ser...@fu...> - 2009-03-06 10:30:04
|
On Fri, 2009-03-06 at 09:44 +0100, Ivan Herman wrote: > I agree. It would become quite unmanageable if we began to chase all > different implementations that do not abide to standards... After all, > that is why standards are for! Exactly :-) Thank Zach Dwiel for raise the issue. Please, keep us informed about the decision taken by Joseki's team. -- Sergio Fernández - ser...@fu... Departamento I+D+i Fundación CTIC - www.fundacionctic.org Tlfn: +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-03-06 09:05:03
|
Sergio Fernández wrote: > On Thu, 2009-03-05 at 23:21 -0600, Zach Dwiel wrote: >> I'm trying to use the python-sparqlwrapper library to run >> SPARQL/Update operations. In the sparql-wrapper code, the update >> query is bound to the 'query' parameter in the HTML post. In Joseki's >> implementation, the query is expected to be bound to the parameter >> 'request'. > > AFAIK, SPARUL [1] is just an extension for SPARQL Query Language [2]. > The name of that HTTP parameter is defined by other specification, the > SPARQL protocol [3]. > >> Otherwise, maybe something could be changed on the sparql-wrapper side >> to make this possible. Previously, I have dealt with this by changing >> the library to make the query parameter changable ... What do you >> think? > > While the wrapper uses the mandatory name, I don't want to patch that > side. But I think it would be nice to propose your patch to Joseki guys, > in order to align it with other implementations. > I agree. It would become quite unmanageable if we began to chase all different implementations that do not abide to standards... After all, that is why standards are for! Ivan > Cheers, > > [1] http://www.w3.org/Submission/2008/SUBM-SPARQL-Update-20080715/ > [2] http://www.w3.org/TR/rdf-sparql-query/ > [3] http://www.w3.org/TR/rdf-sparql-protocol/ > -- 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-03-06 08:35:40
|
On Thu, 2009-03-05 at 23:21 -0600, Zach Dwiel wrote: > I'm trying to use the python-sparqlwrapper library to run > SPARQL/Update operations. In the sparql-wrapper code, the update > query is bound to the 'query' parameter in the HTML post. In Joseki's > implementation, the query is expected to be bound to the parameter > 'request'. AFAIK, SPARUL [1] is just an extension for SPARQL Query Language [2]. The name of that HTTP parameter is defined by other specification, the SPARQL protocol [3]. > Otherwise, maybe something could be changed on the sparql-wrapper side > to make this possible. Previously, I have dealt with this by changing > the library to make the query parameter changable ... What do you > think? While the wrapper uses the mandatory name, I don't want to patch that side. But I think it would be nice to propose your patch to Joseki guys, in order to align it with other implementations. Cheers, [1] http://www.w3.org/Submission/2008/SUBM-SPARQL-Update-20080715/ [2] http://www.w3.org/TR/rdf-sparql-query/ [3] http://www.w3.org/TR/rdf-sparql-protocol/ -- 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: Zach D. <zd...@gm...> - 2009-03-06 05:21:31
|
Hello, I'm trying to use the python-sparqlwrapper library to run SPARQL/Update operations. In the sparql-wrapper code, the update query is bound to the 'query' parameter in the HTML post. In Joseki's implementation, the query is expected to be bound to the parameter 'request'. On the sparql-wrapper-devel mailing list it sounds like the person who added the patch to make SPARUL work tested it with Virtuoso. I don't have a Virtuoso server handy to test this on (nor can I find a live demo which has write support - go figure). I'm not sure how you guys want to handle this since its not an official standard yet anyway ... though It would be nice if the two could communicate without patches. Is adding support to Joseki to allow a query parameter an acceptable solution? If so, I have a patch attached. Otherwise, maybe something could be changed on the sparql-wrapper side to make this possible. Previously, I have dealt with this by changing the library to make the query parameter changable ... What do you think? cheers Zach Dwiel |
|
From: Sergio F. <ser...@fu...> - 2008-08-22 07:19:54
|
[2008-08-03] sparql-wrapper-python 1.2.0-1 MIGRATED to testing http://packages.qa.debian.org/s/sparql-wrapper-python/news/20080803T163919Z.html > ----- Forwarded message from Debian Installer > <ins...@ft...> ----- > > Date: Wed, 23 Jul 2008 11:17:06 +0000 > From: Debian Installer <ins...@ft...> > Subject: sparql-wrapper-python_1.2.0-1_amd64.changes ACCEPTED > To: Nacho Barrientos Arias <na...@de...> > > Accepted: python-sparqlwrapper_1.2.0-1_all.deb > > (...) > > Thank you for your contribution to Debian. > > ----- End forwarded message ----- -- 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...> - 2008-07-23 19:33:19
|
--------- Forwarded message -------- De: Nacho Barrientos Arias <na...@cr...> Para: ser...@fu... Asunto: [ins...@ft...: sparql-wrapper-python_1.2.0-1_amd64.changes ACCEPTED] Fecha: Wed, 23 Jul 2008 15:18:35 +0200 ----- Forwarded message from Debian Installer <ins...@ft...> ----- Date: Wed, 23 Jul 2008 11:17:06 +0000 From: Debian Installer <ins...@ft...> Subject: sparql-wrapper-python_1.2.0-1_amd64.changes ACCEPTED To: Nacho Barrientos Arias <na...@de...> Accepted: python-sparqlwrapper_1.2.0-1_all.deb to pool/main/s/sparql-wrapper-python/python-sparqlwrapper_1.2.0-1_all.deb sparql-wrapper-python_1.2.0-1.diff.gz to pool/main/s/sparql-wrapper-python/sparql-wrapper-python_1.2.0-1.diff.gz sparql-wrapper-python_1.2.0-1.dsc to pool/main/s/sparql-wrapper-python/sparql-wrapper-python_1.2.0-1.dsc sparql-wrapper-python_1.2.0.orig.tar.gz to pool/main/s/sparql-wrapper-python/sparql-wrapper-python_1.2.0.orig.tar.gz Override entries for your package: python-sparqlwrapper_1.2.0-1_all.deb - optional python sparql-wrapper-python_1.2.0-1.dsc - source python Announcing to deb...@li... Thank you for your contribution to Debian. ----- End forwarded message ----- -- 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...> - 2008-07-10 15:40:00
|
Hi folks, after some days out of the office, I remembered that we didn't released a version with the changes about SPARUL that we discussed some time ago. This afternoon Carlos and me were working to review the changes, and we released the version 1.2.0 [1], that now it's available to download in SourceForge [2]. Please, if you find any error/suggestion, don't hesitate to contact us using this mailing list. Cheers, [1] http://sourceforge.net/forum/forum.php?forum_id=844943 [2] http://sourceforge.net/project/showfiles.php?group_id=217900 -- 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...> - 2008-06-18 12:57:06
|
Sergio Fernández wrote: > On Wed, 2008-06-18 at 14:11 +0200, Ivan Herman wrote: >> Sergio, > > Hi Ivan, > >> That is a good idea. Have missed this functionality in your own >> application, or have there been explicit requests for that? > > Yes, it's a functionality that we missed in one of our expermients. So > we'd say that is our own request. > >> I would _hope_ that W3C would be able to start a new working group >> relatively soon. > > That are really good news :-) > >> All this to say that SPARUL is not such a bad option. I have a slight >> preference to this than to the open ended options you propose under (2). >> But that may be only me... > > No, it's a interesting point of view. Open it has some risks, I know. > But I don't like to patch the wrapper with operators that are not yet > official. So I propose you to do the following: let's go now with patch > #2, and let's wait for something more official. What do you think? > O.k. Ivan >> I have no idea about Sesame... > > AFAIK Sesame doesn't support SPARUL, you can delete only using its Java > API and its Web interface. > > Cheers, > -- Ivan Herman, W3C Semantic Web Activity Lead Home: http://www.w3.org/People/Ivan/ PGP Key: http://www.ivan-herman.net/pgpkey.html FOAF: http://www.ivan-herman.net/foaf.rdf |
|
From: Sergio F. <ser...@fu...> - 2008-06-18 12:45:42
|
On Wed, 2008-06-18 at 14:11 +0200, Ivan Herman wrote: > Sergio, Hi Ivan, > That is a good idea. Have missed this functionality in your own > application, or have there been explicit requests for that? Yes, it's a functionality that we missed in one of our expermients. So we'd say that is our own request. > I would _hope_ that W3C would be able to start a new working group > relatively soon. That are really good news :-) > All this to say that SPARUL is not such a bad option. I have a slight > preference to this than to the open ended options you propose under (2). > But that may be only me... No, it's a interesting point of view. Open it has some risks, I know. But I don't like to patch the wrapper with operators that are not yet official. So I propose you to do the following: let's go now with patch #2, and let's wait for something more official. What do you think? > I have no idea about Sesame... AFAIK Sesame doesn't support SPARUL, you can delete only using its Java API and its Web interface. Cheers, -- Sergio Fernández - ser...@fu... Departamento I+D+i Fundación CTIC - www.fundacionctic.org Tlfn: +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...> - 2008-06-18 12:12:03
|
Sergio, That is a good idea. Have missed this functionality in your own application, or have there been explicit requests for that? AFAIK, HP wants to submit a SPARUL as a W3C member submission; I am not sure when, but I would not be surprised to get it at any minute. This would give it a _somewhat_ more official status (not much, I agree...). There has also been a small birth-of-a-feather meeting in Beijing on SPARQL 'Next', where SPARUL is clearly listed. I would _hope_ that W3C would be able to start a new working group relatively soon. All this to say that SPARUL is not such a bad option. I have a slight preference to this than to the open ended options you propose under (2). But that may be only me... AFAIK, Virtuoso implements SPARUL. Ie, the implementation can be tested on both. I have no idea about Sesame... Ivan Sergio Fernández wrote: > Hi, > > as you know at the moment SPARQL doesn't support modification > capabilities. There are some (unofficial) proposals to do this, such as > SPARUL [1], but nothing official. > > And version 1.1.0 of our python wrapper doesn't allow the users to use > SPARUL operations (see traceback attached), since we added a regex to > know which type of query we are executing in order to send the > appropiate http headers. > > So if we want to allow users to use SPARUL we need to fix this issue. I > think we've two ways to do it: > > 1) Extend our regex with new operators from SPARUL (preliminar patch > attached). > > 2) Treat unofficial operators as a default query type (SELECT, for > example) for the http headers (for example Virtuoso returns sparql > results syntaxes in the response). This (patch also attached) works > fine, because we delegate in the server side the management of syntax > errors. > > Personally I prefer the second one, because it's more generic and we > don't add explicitly support of unofficial stuff. What do you think? > > Cheers, > > [1] http://jena.hpl.hp.com/~afs/SPARQL-Update.html > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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/ PGP Key: http://www.ivan-herman.net/pgpkey.html FOAF: http://www.ivan-herman.net/foaf.rdf |
|
From: Sergio F. <ser...@fu...> - 2008-06-18 11:05:38
|
Hi, as you know at the moment SPARQL doesn't support modification capabilities. There are some (unofficial) proposals to do this, such as SPARUL [1], but nothing official. And version 1.1.0 of our python wrapper doesn't allow the users to use SPARUL operations (see traceback attached), since we added a regex to know which type of query we are executing in order to send the appropiate http headers. So if we want to allow users to use SPARUL we need to fix this issue. I think we've two ways to do it: 1) Extend our regex with new operators from SPARUL (preliminar patch attached). 2) Treat unofficial operators as a default query type (SELECT, for example) for the http headers (for example Virtuoso returns sparql results syntaxes in the response). This (patch also attached) works fine, because we delegate in the server side the management of syntax errors. Personally I prefer the second one, because it's more generic and we don't add explicitly support of unofficial stuff. What do you think? Cheers, [1] http://jena.hpl.hp.com/~afs/SPARQL-Update.html -- 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...> - 2008-04-21 11:11:34
|
And now also in testing (aka lenny): http://packages.qa.debian.org/s/sparql-wrapper-python/news/20080418T223921Z.html :-) -- 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...> - 2008-04-16 11:43:04
|
Great news! Thanks Rob! On Tue, 2008-04-15 at 13:23 -0700, Rob Cakebread wrote: > Hello, > > Gentoo users can get sparql-wrapper from my developer overlay: > > layman -a pythonhead > emerge dev-python/sparql-wrapper > > After more testing I'll add it to the official tree. > > Rob -- 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: Rob C. <ro...@do...> - 2008-04-15 20:23:39
|
Hello, Gentoo users can get sparql-wrapper from my developer overlay: layman -a pythonhead emerge dev-python/sparql-wrapper After more testing I'll add it to the official tree. Rob |
|
From: Sergio F. <ser...@fu...> - 2008-04-10 09:41:14
|
> BTW, Why is different the name of the file .deb than the other > files .diff.gz, .dsc and .tar.gz ? [I am newbie in Debian :*] That files come from our tarball (our tar.gz), but the package in Debian (.deb) should be named according their policies [1]: "Public modules should be packaged with a name of python-foo, where foo is the name of the module." That was the reason because we needed to rename the package, because a package called only python-sparql could be confusing. Cheers, [1] http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html -- 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: Carlos T. A. <car...@fu...> - 2008-04-10 07:33:43
|
Good morning! Thanks for your work! BTW, Why is different the name of the file .deb than the other files .diff.gz, .dsc and .tar.gz ? [I am newbie in Debian :*] Cheers, Carlos Tejo Alonso Departamento de I+D+i - Fundación CTIC Parque Científico Tecnológico Gijón, Asturias (Spain) www.fundacionctic.org > -----Original Message----- > From: spa...@li... > [mailto:spa...@li...] > On Behalf Of Nacho Barrientos Arias > Sent: Tuesday, April 08, 2008 9:47 PM > To: spa...@li... > Subject: > [sparql-wrapper-devel][ins...@ft...: > sparql-wrapper-python_1.1.0-1_amd64.changesACCEPTED] > > ----- Forwarded message from Debian Installer > <ins...@ft...> ----- > > Date: Mon, 07 Apr 2008 19:35:10 +0000 > From: Debian Installer <ins...@ft...> > Subject: sparql-wrapper-python_1.1.0-1_amd64.changes ACCEPTED > To: Nacho Barrientos Arias <na...@de...> > > > Accepted: > python-sparqlwrapper_1.1.0-1_all.deb > to > pool/main/s/sparql-wrapper-python/python-sparqlwrapper_1.1.0-1_all.deb > sparql-wrapper-python_1.1.0-1.diff.gz > to > pool/main/s/sparql-wrapper-python/sparql-wrapper-python_1.1.0- 1.diff.gz > sparql-wrapper-python_1.1.0-1.dsc > to > pool/main/s/sparql-wrapper-python/sparql-wrapper-python_1.1.0-1.dsc > sparql-wrapper-python_1.1.0.orig.tar.gz > to > pool/main/s/sparql-wrapper-python/sparql-wrapper-python_1.1.0. orig.tar.gz > > > Override entries for your package: > python-sparqlwrapper_1.1.0-1_all.deb - optional python > sparql-wrapper-python_1.1.0-1.dsc - optional python > > Announcing to deb...@li... > Closing bugs: 469980 > > > Thank you for your contribution to Debian. > > > ----- End forwarded message ----- > > -- > bye, > - Nacho > |
8 messages has been excluded from this view by a project administrator.
