From: William W. <ww...@st...> - 2010-09-18 10:54:44
Attachments:
signature.asc
|
Hello, I'm a new subscriber to this list, and have looked through the documentation and archives to no avail, so apologies if this has been answered before. I'm working on back-ends for both SQLAlchemy and RDFLib to support Virtuoso. The SQLAlchemy one is minimally functional [0], but I am having some trouble with RDFLib. The python API for RDFLib looks something like this, g = Graph(identifier=URIRef("xyz...")) for statement in g.triples((None, None, None)): print statement The call to g.triples() would translate into a SPARQL statement like, SELECT ?s ?p ?o WHERE { GRAPH <xyz...> { ?s ?p ?o } } which is more or less how I implemented it when I made a 4store back-end for RDFLib. The trouble is, we are expected to have the return values instantiated in python objects, URIRef, BNode, Literal, etc.. Resolving ?s and ?p unambiguously is easy enough, by doing 'define output:valmode "LONG"' and then doing __ro2sq on the result. However when ?o comes back and is a literal with a language or a datatype, it just comes as a VARCHAR and there is no way that is obvious to me to find out what its language and datatype are. This leads to a situation where I can insert something with "foo"@en into the store and get back "foo" which is not the same. One alternative would be to (manually) do sparql_to_sql_text() and tweak the resulting queries to also return the extra information but that seems to rely too much on what should be internal implementation details. A second alternative would be to use one of the serialisations but that means (1) queries must return all rows immediately instead of using a cursor and (2) I have to deal with deserialisation. I guess the problem might be solved if I could do 'define output:valmode "SHORT"' but this appears to no be supported. Any help or guidance appreciated. Cheers, -w [0] http://packages.python.org/virtuoso -- William Waites <ww...@st...> Mob: +44 789 798 9965 Fax: +44 131 464 4948 CD70 0498 8AE4 36EA 1CD7 281C 427A 3F36 2130 E9F5 |
From: Hugh W. <hwi...@op...> - 2010-09-18 16:03:50
|
Hi William, Have you looked at the Virtuoso ODBC extensions for SPASQL, which enable applications to query meta information on SPASQL queries, as detailed at: http://docs.openlinksw.com/virtuoso/virtodbcsparql.html#virtodbcsparqlexample These extensions enable the determination of the types of returned literals as indicated in the example provided ... Best Regards Hugh Williams Professional Services OpenLink Software Web: http://www.openlinksw.com Support: http://support.openlinksw.com Forums: http://boards.openlinksw.com/support Twitter: http://twitter.com/OpenLink On 18 Sep 2010, at 11:53, William Waites wrote: > Hello, I'm a new subscriber to this list, and have > looked through the documentation and archives to no > avail, so apologies if this has been answered before. > > I'm working on back-ends for both SQLAlchemy and > RDFLib to support Virtuoso. The SQLAlchemy one is > minimally functional [0], but I am having some trouble > with RDFLib. > > The python API for RDFLib looks something like this, > > g = Graph(identifier=URIRef("xyz...")) > for statement in g.triples((None, None, None)): > print statement > > The call to g.triples() would translate into a SPARQL > statement like, > > SELECT ?s ?p ?o WHERE { > GRAPH <xyz...> { ?s ?p ?o } > } > > which is more or less how I implemented it when I made > a 4store back-end for RDFLib. > > The trouble is, we are expected to have the return > values instantiated in python objects, URIRef, BNode, > Literal, etc.. Resolving ?s and ?p unambiguously is > easy enough, by doing 'define output:valmode "LONG"' > and then doing __ro2sq on the result. > > However when ?o comes back and is a literal with a > language or a datatype, it just comes as a VARCHAR > and there is no way that is obvious to me to find out > what its language and datatype are. > > This leads to a situation where I can insert something > with "foo"@en into the store and get back "foo" which > is not the same. > > One alternative would be to (manually) do > sparql_to_sql_text() and tweak the resulting queries > to also return the extra information but that seems > to rely too much on what should be internal implementation > details. > > A second alternative would be to use one of the > serialisations but that means (1) queries must return > all rows immediately instead of using a cursor and (2) > I have to deal with deserialisation. > > I guess the problem might be solved if I could do > 'define output:valmode "SHORT"' but this appears to > no be supported. > > Any help or guidance appreciated. > > Cheers, > -w > > > [0] http://packages.python.org/virtuoso > -- > William Waites <ww...@st...> > Mob: +44 789 798 9965 > Fax: +44 131 464 4948 > CD70 0498 8AE4 36EA 1CD7 281C 427A 3F36 2130 E9F5 > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev_______________________________________________ > Virtuoso-users mailing list > Vir...@li... > https://lists.sourceforge.net/lists/listinfo/virtuoso-users |
From: William W. <ww...@st...> - 2010-09-18 16:41:28
Attachments:
signature.asc
|
On 10-09-18 17:00, Hugh Williams wrote: > > Have you looked at the Virtuoso ODBC extensions for SPASQL, > which enable applications to query meta information on SPASQL > queries, as detailed at: Hi Hugh, that's helpful, thank you. Unfortunately not as straightforward as I would have liked - it looks like it would require extending pyodbc since it doesn't expose things like SQLGetDescField to python. To complicate matters, when you have a row in Python it won't have any reference to the cursor (or statement handle), apparently this design decision was made so that you could keep a row around while the cursor was closed or reused for another query. So to do this, one would have to (1) check that the database is Virtuoso, (2) check that the query was SPASQL (3) pre-emptively go and collect type information before returning each row. Is there a straightforward way to do (1) and (2) at all? More C++ coding than I'd like (pyodbc is written in C++) but not the end of the world... Cheers, -w -- William Waites <ww...@st...> Mob: +44 789 798 9965 Fax: +44 131 464 4948 CD70 0498 8AE4 36EA 1CD7 281C 427A 3F36 2130 E9F5 |
From: Hugh W. <hwi...@op...> - 2010-09-19 22:23:54
|
Hi William, If pyodbc is the interface being used then it would need to be extended to support these calls. The ODBC SQLGetInfo(SQL_DBMS_NAME,...) function can be used to determine the database being connected to is Virtuoso: SQLGetInfo: In: ConnectionHandle = 0x003C1720, InfoType = SQL_DBMS_NAME=17, InfoValuePtr = 0x00169258, BufferLength = 300, StringLengthPtr = 0x00165790, Information Value Type = SQL_C_CHAR=1 Return: SQL_SUCCESS=0 Out: *InfoValuePtr = "OpenLink Virtuoso", *StringLengthPtr = 17 SPASQL is simply the ability to execute SPARQL queries via a SQL interface like ODBC, JDBC, ADO.Net etc. so once you have determine the database to be Virtuoso with the above call any SPARQL query passed prepended with the keyword "sparql" is SPASQL ... Best Regards Hugh Williams Professional Services OpenLink Software Web: http://www.openlinksw.com Support: http://support.openlinksw.com Forums: http://boards.openlinksw.com/support Twitter: http://twitter.com/OpenLink On 18 Sep 2010, at 17:40, William Waites wrote: > On 10-09-18 17:00, Hugh Williams wrote: >> >> Have you looked at the Virtuoso ODBC extensions for SPASQL, >> which enable applications to query meta information on SPASQL >> queries, as detailed at: > > Hi Hugh, that's helpful, thank you. Unfortunately not > as straightforward as I would have liked - it looks > like it would require extending pyodbc since it doesn't > expose things like SQLGetDescField to python. > > To complicate matters, when you have a row in Python > it won't have any reference to the cursor (or statement > handle), apparently this design decision was made so > that you could keep a row around while the cursor > was closed or reused for another query. So to do this, > one would have to (1) check that the database is Virtuoso, > (2) check that the query was SPASQL (3) pre-emptively > go and collect type information before returning each > row. > > Is there a straightforward way to do (1) and (2) at all? > > More C++ coding than I'd like (pyodbc is written in C++) > but not the end of the world... > > Cheers, > -w > -- > William Waites <ww...@st...> > Mob: +44 789 798 9965 > Fax: +44 131 464 4948 > CD70 0498 8AE4 36EA 1CD7 281C 427A 3F36 2130 E9F5 > |
From: Tim H. <th...@op...> - 2010-09-20 16:53:15
|
On 18/09/2010 17:40, William Waites wrote: > (1) check that the database is Virtuoso, > (2) check that the query was SPASQL (3) pre-emptively > go and collect type information before returning each > row. > > Is there a straightforward way to do (1) and (2) at all? Hi, pyodbc supports SQLGetInfo(): > In [35]: import pyodbc > > In [36]: conn=pyodbc.connect("DSN=virtdiscussion") > > In [37]: conn.getinfo(pyodbc.SQL_DBMS_NAME) > Out[37]: 'OpenLink Virtuoso' Presumably the obvious way to check a query for SPASQL is to see if the first word in the query is "sparql": > In [38]: import re > > In [39]: re.search("^\s*sparql ", "SPARQL select distinct * where { ?s ?p ?o . };", re.I) > Out[39]: <_sre.SRE_Match object at 0x1053d55e0> > > In [40]: type(re.search("^\s*sparql ", "select distinct * where { ?s ?p ?o . };")) > Out[41]: <type 'NoneType'> HTH, ~Tim -- Tim Haynes Product Development Consultant OpenLink Software <http://www.openlinksw.com/> <http://twitter.com/openlink> |