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                       <[email protected]>
Mob: +44 789 798 9965
Fax: +44 131 464 4948
CD70 0498 8AE4 36EA 1CD7  281C 427A 3F36 2130 E9F5

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to