On Wednesday, 8 February 2012 20:04:34 UTC, Gunnar Aastrand Grimnes wrote:My grubby fingerprints are all over the commit record, agreed. But TBH,
> You do about 90% of the development at the moment :) - you should know
> and set the direction! :)
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,
> personally I have no interest in maintaining a zope-db store forIronically, the zope-db store is one of the few stores that passes all of
> instance, if it's in a separate project it'll be obvious if no one
> else has any interest either and it lying untouched for years
the tests  (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
I'm also experimenting with a SQLAlchemy (dbapi2) version of the
It's possibly a chimera because of the inevitable SQL variations between
The key-value approach to modelling (e.g. Sleepycat, Kyoto Cabinet) offers
jsonld was already mentioned as a suitable candidate for inclusion
> back into rdflib, at least when the json-ld spec goes stable.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
> lots of heavy dependencies.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
> only just started grokking merging in hg :)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
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.