OpenRDF as Store
Dominique Guardiola Falco
In this case, is there an example of the specific settings to be used to connect to a local server ?
Dominique
Christoph Burgmer
If you check plugins/surf.sesame2/sesame2/test/test_sesame2.py you can find the
following settings used:
kwargs = {"reader": "sesame2",
"writer" : "sesame2",
"server" : "localhost",
"port" : 8080,
"root_path" : "/openrdf-sesame",
"repository" : "test"}
You would have to create the "test" repository before though (here:
http://localhost:8080/openrdf-workbench/). This settings above run locally
without changes for a Jetty installation. For tomcat you might have a different
port.
I should probably blog about the steps used to install OpenRDF & sesame &
surf.
-Christoph
Dominique Guardiola Falco
store.clear() works
adding resources one by one using resource.save() works too
what doesn't is loading RDF directly :
store.load_triples(source = "http://www.w3.org/People/Berners-Lee/card")
in Jetty log it says :
127.0.0.1 - - [11/mai/2011:20:59:19 +0000] "POST /openrdf-sesame/repositories/test/load?rdf=None HTTP/1.1" 404 1402
The URL called seems OK except that I don't see mention of a "/load" path in Sesame2 HTTP protocol doc (example 8.5.1.4),
looks like it should use "/statements" . I did not find the relevant code in the plugin source though...
Christoph Burgmer
> what doesn't is loading RDF directly :
> store.load_triples(source = "http://www.w3.org/People/Berners-Lee/card")
>
> in Jetty log it says :
> 127.0.0.1 - - [11/mai/2011:20:59:19 +0000] "POST
> /openrdf-sesame/repositories/test/load?rdf=None HTTP/1.1" 404 1402
Reading older bug reports it seems that the origins of the sesame2 plugin in
SuRF lie with AllegroGraph. Many of its features only work with extensions
provided by AllegroGraph and are not available with OpenRDF.
Doing a quick search on Sesame2 + load doesn't turn up any good hits so I
believe there is no direct way of doing the same with OpenRDF. A solution
though is to do the following:
from surf.rdf import Graph
function load(source, format='xml', context=None):
g = Graph()
g.parse(source=source, format=format)
for s, p, o in g:
store.add_triple(s, p, o, context=context)
This gets the file locally, parses it and then adds all triples to the remote
store.
I filed a bug report to track this issue
(http://code.google.com/p/surfrdf/issues/detail?id=71), but I believe there's
not much we can do than to mark this method as unsupported.
A fact I learned about just now is that OpenRDF supports SPARQL (not SPARUL
though it seems) so we could try to support OpenRDF through the
sparql_protocol or something similar.
-Christoph
Christoph Burgmer
> A fact I learned about just now is that OpenRDF supports SPARQL (not SPARUL
> though it seems) so we could try to support OpenRDF through the
> sparql_protocol or something similar.
Correction. Of course SuRF uses SPARQL on OpenRDF but we could check if
there's a more generic way of doing the connection bits.
Dominique Guardiola Falco
Le 12 mai 11 à 00:11, Christoph Burgmer a écrit :
> Reading older bug reports it seems that the origins of the sesame2
> plugin in
> SuRF lie with AllegroGraph. Many of its features only work with
> extensions
> provided by AllegroGraph and are not available with OpenRDF.
Ok, i see
> from surf.rdf import Graph
>
> function load(source, format='xml', context=None):
> g = Graph()
> g.parse(source=source, format=format)
> for s, p, o in g:store.add_triple(s, p, o, context=context)
thanks for this workaround Christoph,
just a pity that it gets back to RDFlib parser, or xmlreader in rdflib
and doesn't like literals
MALFORMED DATA: Expected '.', found: " [line 1]
Perhaps Sesame would have eaten the timbl FOAF profile without
complaining...
> A fact I learned about just now is that OpenRDF supports SPARQL (not
> SPARUL
> though it seems) so we could try to support OpenRDF through the
> sparql_protocol or something similar.
I'll try the SPARQL access and dig into the sesame2 code if I find
time to.
Is it still important to maintain its compatibility with allegro since
allegro has its own plugin ?
Cosmin Basca
of using the AllegroGraph HTTP Sesame extensions just as Christoph
mentioned. At the tim e I first created it, the AllegroGraph team did
not release a python API yet so all had to be done via their HTTP
extension.
However the load feature you are talking about is supported by Sesame2
in the protocol:
"POST /openrdf-sesame/repositories/mem-rdf/statements HTTP/1.1
Host: localhost
Content-Type: application/rdf+xml;charset=UTF-8
[RDF/XML ENCODED RDF DATA]" (an extract from
http://www.openrdf.org/doc/sesame2/system/ch08.html#d0e304)
which would imply a read of the contents of the file (remote or local)
pasted in a simple HTTP post later on. I will try to have a look at
it, but unfortunately I am swamped with project work and may only have
time during the weekend to look over this. Anyhow the source of the
problem in the plugin source is the "Allegro" object, all should be
migrated to a "Sesame2" instance, and the methods adapted accordingly.
Cheers,
Cosmin
On May 11, 10:58 pm, Dominique Guardiola Falco
Christoph Burgmer
> and doesn't like literals
> MALFORMED DATA: Expected '.', found: " [line 1]
> Perhaps Sesame would have eaten the timbl FOAF profile without
> complaining...
If I find some time I'll have a look at the rdflib code there.
> I'll try the SPARQL access and dig into the sesame2 code if I find
> time to.
> Is it still important to maintain its compatibility with allegro since
> allegro has its own plugin ?
The Allegro specific bits are provided as an extra class on top of the Sesame2
code. It seems though that a better separation is needed. I believe the code
there is one of the oldest parts of SuRF so cleaning up is needed. If you find
time to look into this, cool.
Btw, I created another issue report to extend the test cases so that your
issue is found by unittesting:
http://code.google.com/p/surfrdf/issues/detail?id=72
I'll have this on my radar.
-Christoph
Christoph Burgmer
> > and doesn't like literals
> > MALFORMED DATA: Expected '.', found: " [line 1]
> > Perhaps Sesame would have eaten the timbl FOAF profile without
> > complaining...
>
> If I find some time I'll have a look at the rdflib code there.
Do you have a file/URL where this error occurs? I thought you meant
http://www.w3.org/People/Berners-Lee/card but this is parsed correctly under
rdflib 3.1.0
-Christoph
Dominique Guardiola Falco
What I just found is that if I switch my test to a IOMemory rdflib_store, there's no problem, like you ...
So the problem may caused by a specific handling of store.add_triple() when used with a sesame2 store
I'm afraid you won't be able to reproduce it without Jetty + Sesame
Here is my test code :
from surf import Store, Session
from surf.rdf import Graph
store = Store( reader = "sesame2",
writer = "sesame2",
server = "localhost",
port = 8080,
root_path = "/openrdf-sesame",
repository = "test")
session = Session(store)
g = Graph()
g.parse(source="http://www.w3.org/People/Berners-Lee/card")
for s, p, o in g:
store.add_triple(s, p, o)
store.clear()
when I run the above code I got (snipped non-problematic lines):
<class 'rdflib.term.BNode'> <class 'rdflib.term.URIRef'> <class 'rdflib.term.Literal'> c111fbc68eccad2021acc16533fb7b81
73505931694c476346c3254cf9706553
......
....
MALFORMED DATA: Expected '.', found: " [line 1]