My grubby fingerprints are all over the commit record, agreed. But TBH,
it's all minor-league stuff: refactoring, shuffling code around and a few
straightforward bug fixes. I do almost no actual /development/ per se. By
"development", I mean the kind of thing that's currently being thrashed out
in the discussions of issue 211, preserving the lexical form of Literals.
This is why I tend to defer to others on approaches to the modelling.

you bravely restored the different stores, now,

Ironically, the zope-db store is one of the few stores that passes all of
the tests [1] (although it's a shame it's not py3compat and is unlikely
ever to be so).

The stores that are based on the AbstractSQLStore/FOPLRelationalModel all
exhibit the same three/four test failures, strongly suggesting a small set
of common issues in the underlying modelling classes which, if fixed, would
bring them all back into play as viable modules.

I'm also experimenting with a SQLAlchemy (dbapi2) version of the
now-obsolete SQLObject store that might well provide a useful abstraction,
allowing the straightforward use of a variety of DB backends supported by
SQLAlchemy [2] merely by switching config string - SQLAlchemy uses a
"dburi" scheme to achieve this, e.g.

mysqluri="mysql+mysqldb://user:password@host:port/dbname?extraconfig"
drizzleuri="drizzle+mysqldb:://user:password@host:port/dbname?extraconfig""
postgresqluri='postgresql+psycopg2://user:password@host:port/dbname"'

It's possibly a chimera because of the inevitable SQL variations between
the back-ends (MySQL vs SQLite for example) but worth investigating all the
same.

The key-value approach to modelling (e.g. Sleepycat, Kyoto Cabinet) offers
some interesting possibilities, e.g. adapting it to a Riak back-end looks
reasonably straightforward. The burgeoning number of "no-SQL" data stores
in most cases further enhances these possibilities.

jsonld was already mentioned as a suitable candidate for inclusion

This is where I tend to defer. My controversial take on it is that RDFLib
should offer just RDF/XML. The other parsers/serializers are optional
surface syntax additions and are not "core" RDF, so should be made
available as separate plugins. That would most likely break a lot of
existing code, so we're sort of stuck with the bloat. If it were up to me
(but it isn't) I'd resist any further intrusion of Notation3 syntax into
RDFLib core. I have yet to find any empirical support for the claim that n3
is much more readable than RDF/XML and I'm occasionally tempted to make the
argument that the claim is merely an unsupported conjecture about a issue
that is properly in the domain of cognitive psychology but I'm too jaded to
care overmuch. So I'm entirely sympathetic when you write that you have
little personal interest in devoting time to maintaining a zope-based store
because I'm exactly the same where n3 is concerned.

The -web stuff I would maybe split off as a separate package - it has

That would be useful. The flask dependency pulls in werkzeug which pins it
to Python 2 - although, as has been observed, using bottle would obviate
that version pin.

Soon my biggest issue is that now I have to really learn git - and I

Sorry about that, I'm in the same position but GitHub has a clear edge and,
according to the technical hardnoses, so goes git. I'll re-recommend
Smartgit, it can be used for non-commercial purposes. git's staging is
particularly useful for parking your working code, doing a pull from the
main repos and then unstaging your working code back over the top of what
was pulled. Very useful, I've found.

There's also the Hg-Git mercurial plugin - http://hg-git.github.com/ which
will allow you to use hg commands with a git repos. I found that it doesn't
handle branches terribly well though.

[1] http://bel-epa.com:8080/hudson/job/rdflib-zodb/
[2]
http://docs.sqlalchemy.org/en/latest/core/engines.html#supported-data...

Cheers,

Graham