[okfn-help] ORDF ticket #53: work with vanilla rdflib, remove 4store dependencies.

Rufus Pollock rufus.pollock at okfn.org
Tue Jun 15 14:44:55 UTC 2010


Thanks for this detailed update Graham which is extremely useful in
signposting the way. Some comments inline below.

On 15 June 2010 13:05, Graham Higgins <gjh at bel-epa.com> wrote:
> We have an existing ticket to "make semantic + ordf work with vanilla rdflib
> and remove the 4store dependencies":
>
> <http://knowledgeforge.net/pdw/trac/ticket/53>
>
> I have marked this as 'wontfix', at least for the present, as i) the change
> promises to prove costly in terms of providing support to users and ii) may
> well introduce instability in ORDF.

This seems a very reasonable answer :)

At the same time I'm wondering whether it would be possible to get
something partially workable based on 2.4.2 while await 3.0 to become
functional. While, I understand, as you detail below, that some bits
of 2.4.2 sparql are "dodgy" it may be "good enough" :)  (I also wonder
whether we couldn't utilize the sparql support of a given backend e.g.
4store when we are using that backend thereby avoiding the rdflib
sparql entirely in those cases ...)

[...]

> Some existing rdflib 2.4.2 SPARQL issues have been marked as "wontfix" in
> favour of rdflib 3.0. These include one that has significant impact on the
> execution time of SPARQL queries, logged as "querying a tiny Sleepycat db
> takes 30 seconds". I have been able to confirm that this issue also affects
> the pure Python implementation in rdfextras in that the provided sample
> "problematic" SPARQL query continues to take between 25s and 80s to execute
> (on a variety of back-end stores). I have raised a ticket to this effect for
> the rdfextras package [3].

While there are clear issues with 2.4.2 it does seem that it might be
good enough most of the time and would give us the huge benefit of not
being completely dependent on a specific store (4store atm).

I know Will has some ideas here and he may be able to get something
"hacked" in that will prove workable enough for us to get by until 3.0
gets fully operational!

@Will does that sound about right?

Rufus

[...]




More information about the okfn-help mailing list