Design Notes. I've been reading the postings to OSAF's design mailing list. It is incredibly heartening to be getting so much high-quality... [Mitch Kapor's Weblog]
For those interested in Chandler, I recommend reading Mitch's post in its entirety, as he definitely does put some meat on the bones of Chandler's architecture. Perhaps this could have been intuited by former Agenda users. Unfortunately, I am not one, so I benefit greatly from Mitch's exposition.
Mitch makes quite clear that Chandler will use RDF, and that its use of RDF will be central, in the sense that not only will items be represented using RDF, but that queries and views will be conducted and created in terms of RDF. I think this is excellent, but I'd love to see some more information about how this is expected to be done. Although RDF per se has been around for a couple of years now, the RDF query language space is still intensely competitive. So, for that matter, is the RDF API space. In Python, it seems to me from cursory research that you at least have 4Suite and Redland to choose between for APIs. The Redland site indicates that no RDF query language is currently supported. It's unclear from my quick look at 4Suite whether any RDF query language is supported by 4Suite.
So I'm very curious about this extremely important aspect of Chandler's architecture, and as I've mentioned on the Chandler design mailing list, I think that a combination of e4Graph and RQL, exposed as a Python module, would fit the bill nicely. In particular, RQL's uniform treatment of data and schema queries will support precisely the kind of automatic classification tasks, among other things, that Chandler is expected to offer.
But perhaps the Chandler team already has something else in mind. Regardless, I'd love to hear about it.
5:48:53 PM 
|
|
