Blog ( Section )
Login to submit a blog entry.
2.4.0 released
As a result of a great group group effort, with many people contributing, we are pleased to announce rdflib-2.4.0
The release contains improved literal support in regards to datatype and comparison bits, many sparql fixes and improvements, and a whole bunch of other fixes and improvements. As a result we've bumped the middle version number to reflect the level and extent of the changes. However, all indication of people upgrading so far have been good re: interface being stable.
Nacho Barrientos Arias, the debian package maintainer for rdflib, has told us: The 2.4.0 release will be hitting Debian unstable in a few hours and at the moment the source package is passing through the build daemons. Thank you Nacho!
Thank you all for your contributions and feedback.
Issues Functionality added to this Site
Hi all, just wanted to point out that we've added some basic issue tacking functionality to this site. Please do try and make use of it for entering and tracking rdflib issues. We'll be improving the functionality as needed so feel free to send along feature request you think will make the issue tracking more effective.
There's currently news feeds for the blog and comments that you can subscribe to and I'll add one for the issues. The respective pages point to their feeds so your news reader should pick up on them. Else append atom/ to the URLs, for example, http://rdflib.net/comments/atom/ is the URL for the comments feed. We can easily add other feed formats if anyone needs them.
Bug/typo in plugin.py wrt TurtleSerializer
Hi,
just trying out RDFLib for the first time, and came across this typo:
--- plugin.py~ 2006-10-05 18:37:43.000000000 +1000
+++ plugin.py 2006-11-01 14:46:06.000000000 +1100
@@ -53,7 +53,8 @@ register('nt', serializers.Serializer,
'rdflib.syntax.serializers.NTSerializer', 'NTSerializer')
register('turtle', serializers.Serializer,
- 'rdflib.syntax.serializers.TurtleSerializer', 'TurtleSerializeer')
+ 'rdflib.syntax.serializers.TurtleSerializer', 'TurtleSerializer')
+
register('n3', serializers.Serializer,
'rdflib.syntax.serializers.N3Serializer', 'N3Serializer')
Once this was fixed, I also got an exception thrown by TurtleSerializer. I'm not sure if it was a typo, but the following patch seems to get it working:
--- TurtleSerializer.py~ 2006-08-09 08:48:38.000000000 +1000
+++ TurtleSerializer.py 2006-11-01 15:05:36.000000000 +1100
@@ -108,7 +108,7 @@ class TurtleSerializer(RecursiveSerializ
return
for prefix, uri in ns_list:
- self.write('\n'+self.indent()+'@prefix %s: %s.'%(prefix, uri.n3()))
+ self.write('\n'+self.indent()+'@prefix %s: %s.'%(prefix, uri))
self.write('\n')
def endDocument(self):
Regards,
Ewan Klein
rdflib-2.3.3 released
A rdflib-2.3.3 release is now available.
rdflib-2.3.1 released
A number of bug fixes and minor feature additions are now available in the rdflib-2.3.1 release.
Should SPARQLGraph really refer to self.store
Hi
Looking at the implementation of SPARQLGraph I see that the methods all refer
to self.store for instance
def getPredicateSubject(self,p,v) :
"""Get a subject value for predicate and a value. Useful if
one knows that there may only be one... Returns None if no
value exists.
It is one of those situations that occur a lot, hence this
'macro' like utility.
@param p: predicate
@param v: value
@rtype: RDFLib Resource
@raise UniquenessError: the triple store contains more than one subject for the (p,v) pair
"""
retval = None
for s in self.store.subjects(p,v) :
if retval != None :
# this can happen only if the value is not unique!
raise UniquenessError(p,v)
else :
retval = s
return retval
However I am using the sleepycat backend which doesn't have a direct subjects method,
however the Graph using the sleepycat backend does and subjects method of a graph using sleeepycat backend works.
Should the SPARQLGraph methods use the graph instead?
i.e. the loop would instead read
for s in self.graph.subjects(p,v) :
if retval != None :
# this can happen only if the value is not unique!
raise UniquenessError(p,v)
else :
retval = s
return retval
Or am I missing something fundamental here ?
Rgds
Tim Hoffman
P.S. If it does I will log stuff in trac
Bug in MySQL store handling of literals' lang
The db column used for storing the language of a literal is a varchar(3) but the query for deleting literals is looking for language='None' so it never matches anything. Either the column should be a varchar(4) or the query should change.
Trac installation set up for RDFLib
After discussion on IRC last night, I've set up a basic Trac environment for use by RDFLib (and friends if friends are so inclinded) at
n3 support status
I've been working on integrating n3 support into rdflib as part of the paw/cwm dev work that's going on. This is work I'm involved with though my Mindlab work on the PAW project. And in particular this work will help integrate Pychinko better with rdflib.
rdflib-2.2.3 released
The rdflib-2.2.3 release fixes a few more minor bugs.
unittests?
I'm having trouble locating the unittests for v2.2.2 -- there was a "test/" directory in the v2.0.6 release that seems to have fallen off since then. Can someone point me in a suitable direction? Thanks...
rdflib-2.2.2 released
The rdflib-2.2.2 release fixes a number of bugs and also adds a backend, contributed by Chimezie, for accessing a 4Suite RDF model. Thank you to all who sent in bug reports and patches.
4Suite RDF as a backend for rdflib
mnot releases sparta.py 0.8
mnot has announced the release of sparta.py 0.8, his simple API for RDF. The 0.8 version requires rdflib 2.2.x.
zope.interface support
We're in the process of adding Interfaces to rdflib using Zope Interfaces and also replacing rdflib's home brewed plugin system. So far things are going well, but we've run across something we'd like to be able to do, namely, create an instance by calling the interface with no arguments. For example:
from zope.interface import Interface, implements
class Graph(Interface):
""" A Graph..."""
class DefaultGraph(object):
implements(Graph)
verifyClass(Graph, DefaultGraph)
from zope.interface.adapter import AdapterRegistry, Default
from zope.interface import providedBy
registry = AdapterRegistry()
def hook(provided, object):
adapter = registry.lookup1(providedBy(object), provided, '')
if object==Default:
return adapter()
else:
return adapter(object)
from zope.interface.interface import adapter_hooks
adapter_hooks.append(hook)
registry.register([Default], Graph, '', DefaultGraph)
g = Graph(Default) # currently
g = Graph() # This is what we'd like to be able to do to get an instance of DefaultGraph (since it's registered as the Default for Graph).
So far people seem to like the idea. So we're sending the idea along to the Zope developers.
rdflib-2.2.1 released
The bug preventing rdflib to work on Python2.3 has been fixed in the rdflib-2.2.1 release. Also, the release process now includes successfully running the tests against both Python2.3 and Python2.4 before the release is created ;)
rdflib and SPARQL
As some of you know rdflib has been slowly growing SPARQL support. It started when Ivan Herman from the W3C implemented the SPARQL query logic for rdflib and contributed it back to us. The bulk of his work is in the rdflib.sparql module. While not a complete sparql implementation, because it lacked a parser, it represented the bulk of the work necessary to implement a sparql query language, ie, the actual query logic. On the parser front I have made some progress. You can find it in rdflib.sparql.grammar in the current SVN. It depends on the excellent pyparsing library to parse sparql queries into a structured token object from which all of the relevant bits of data about a particular sparql query can be extracted. The grammar is still young and being tested and it doesn't work for all queries, but it's a start. I've written a script that applies the grammar to all of the standard SPARQL tests, so that over time I can keep working on it until all the tests pass. Once we have a working parser that parses all the known sparql test queries then we can implement the last peice, the thin glue layer between the parser and Ivan's query logic. I'm hoping that by rdflib 2.4 or 2.5 we can brag about having full sparql support as well as being able to successfully run and prove all of the standard tests. This would be a huge milestone for us as it would drive more developers to rdflib, if only because they want a framework against which to test and verify the spec: it encourages the existing sparql gurus out there to come our way because of the amazingly low barrier of entry rdflib provides by being pure-python.
Python2.3 compatibility issues
Thank you to all who have pointed out the rdflib-2.2.0's Python2.3 compatibility issues. There apears to be one or two issues that need to be resolved. I should be able to get to them within a few days (in the mean time patches are welcome). Sorry there was no testing against 2.3 before the release.
rdflib-2.2.0 released
I'm pleased to announce the rdflib-2.2.0 release, a new stable release. Projects that would like a bug fix only branch of rdflib to depend on should use this new stable branch. New development will now move to a 2.3.0 development branches.
Subscribe: Atom