On May 3, 2006, at 11:40 PM, Chimezie Ogbuji wrote:
I have some suggestions
I hoped you might... :>
I guess I wouldn't characterize this as poor but mostly inconvenient,
because it's a straight forward mapping.
I think the first and most important design goal for rdflib is to
*correctly* serialize RDF graphs into one or more literal syntaxes.
The really, really, really primitive datatyping support works against
this design goal.
I don't have any your ideas
/ patches (might have been before I switched to using rdflib instead
of 4Suite RDF), but (ironically - see below), such a binding is in the
Sparta code base:
Yeah, this is the totally obvious thing to do. It should be *in*
rdflib, not in some 3rd party pkg.
Probably makes better design sense to move it into a method on
Literal.
Why a method? Even easier, just have literal's constructor do a
Python type() of the constructor arg, map the Python type to the XSD
datatype URI, and use that. If there is no mapping, or it's
ambiguous, *then* make an untyped literal.
I should be able to do: Literal(1.3), Literal(True), and Literal
("string") and get datatyped literals.
4. no *real* query language support, though it seems Chimezie has
fixed this to some extent by allowing Versa querying... Would be
*really* nice to have that rolled into the next major release. SPARQL
would be nice too, but *any* query language is better than none.
This is tough one, because IMHO a decent, portable, *standalone* (I'm
a big fan of minimal software depency) SPARQL parser is all that's
needed to tie in the very effective sparql-q library that
unfortunately has to be used programatically.
Well, exactly right, and still no one's written a parser for it. And
there were Versa ports around and they never got integrated. rdflib
needs query language support if it's going to be useful and actually
used in serious applications.
Mostly, however I've been using rdflib via the 4Suite RDF API in order
to dispatch Versa queries as well as develop web applications using
4Suite repository and persisting RDF in rdflib - for production
projects. So, the querying support has been sufficient for me and
will be vastly improved with SPARQL support.
Great. But I want one library I can dl & install for RDF. Having to
chase around looking for other bits is inconvenient and doesn't
inspire confidence. I'm not suggesting rdflib should become Jena --
kitchen sink -- but it should become Jena-like.
5. Is there any inference support at all, even for just simple RDFS?
It's not clear what the state of play here is, and that's a problem
in addition to what appears to be the lack of support...
Inference support should be third-party or clearly seperated given how
open-ended RDF/RDFS entailment can be (i.e. what entailment rules do
you support, how do you implement them - forward or backward chaining,
when do you infer, do you persist what you infer?, etc..).
Eh, I don't agree. Many other RDF libraries solve these problems (by
making reasonable, default choices), and rdflib can do the same
thing. Both fwd & bkwd chaining reasoners are good, but one or the
other is much better than none. Jena has both. As for RDFS entailment
rules, there's a pretty well agreed upon core (no one sane uses the
dumb rules about inferring everything is a Resource, for example...)
and this is a pretty well-studied area too. In a world where we have
OWL, supporting RDFS is not optional, IMO.
Now, if this is a technically separate package that's (1) documented,
(2) easy to install, (3) supported, I don't care if it's technically
separate. Someone can make a sumo build and us *users* can get on w/
our lives and projects. :>
If you mix
and match inference behavior with a 'vanilla' RDF programming API, you
risk bloating your API in such a way that it's no longer portable or
agile
Eh. I don't agree. But, fine, keep it "separate", but it should
*exist* and be easy to find, install, and use. None of those is true
of rdflib today.
should be bound as closely to the host language as possible (__len__,
__contains__, etc..) and clearly seperated from the 'other' APIs
(Querying, Inference, Persistence,etc.).
Fine. Clearly separated is good. But my point is different: these
things can be clearly separated but users increasingly need (or so
I'm arguing based on my user sample of, well, myself! :>) these
features too. And we need them documented, easily installed, and well-
maintained.
I have a huge interest in rdflib as well, more from a web app
perspective than pure RDF processing.
FWIW, I've only ever used rdflib in web apps.
use it instead. Having a mailing list helps. It's a large body of
work to manage and it's made worse by the fact that RDF is so recent
on the programming scene that there aren't even any well known best
practices on APIs, programming conventions, etc.
I don't believe that's true at all. Sesame is seriously well-designed
code and offers a lot of ideas for rdflib folks to steal, despite the
fact that it's Java code (-wink-) -- Jena, while less well done IMO,
also offers plenty of ideas and conventions.
Cheers,
Kendall
_______________________________________________
Dev mailing list
[email protected]
http://rdflib.net/mailman/listinfo/dev
