It is a toolkit for accessing RDF graphs as regular objects.
Oort provides classes and functions used to define RDF queries and selectors. These are class declarations defining how to pick properties and associated sub-queries from a chosen resource. This is similar to how many ORM-toolkits work (e.g. SQLObject, SQLAlchemy).
Oort sits between the Graph and the code (mainly templates), serving as a boundary layer where aspects of the statements of resources become plain objects to work with. This is for separation and for making it easier to specify which data should be available to the application code (and how).
Sparta is an execellent tool for working against RDFLib Graphs as if they were python object graphs. Oort is similar, but uses a more declarative approach to retrieval of specific parts.
It is not mainly intended for general querying. It is possible to use RdfQuery in conjunction with e.g. SPARQL, Versa etc., trough the mechanisms available in RDFLib.
Basically through the ongoing work with combining RDFLib and 4Suite. I see no problems (and great prospects) in using a 4Suite Server storage as a back-end for an Oort application.
On the other hand, there is more of a confirmative relation between 4Suite (Server) and many ideas that has led to Oort. The future may bring ease of graph management based on this. The architecture of 4Suite Server in many ways made me realize that I was on to something (and not heading down a fictious path).
I won't go into details until they have been worked through, but it's basically about how to manage a Graph in the form of regular files and folders (constituting sub-graphs) using contexts. Quite simple stuff (take a look at oort.util.graphs for some rudimentary code).
Mainly to create web sites which display contents from an RDF Graph. Thus, one can see Oort as a toolkit for building CMS-like applications. It facilitates the mapping of URIs to URLs on a site, taking care of matching rdf:type to specific templates, and of the retrieval of values from statements about the selected resource(s).
Yes and no. OortPub itself only eases the part of (R)ead. You have to do the rest directly with the RDFLib API (which is very good in itself though).
I.e., currently development with Oort requires applications to have their own way of managing the Graph.
(There are some ideas concerning making the RdfQuery class capable of Create, Update and Delete as well, but that's currently not developed on.)
More of the latter than the former, as far as I know. Large graphs will be a pain to work against live at runtime, wherefore caching should be a good idea for such sites.
There are some seed ideas for caching queries instead of the entire output, which should benefit interactive apps who still desire to be data (RDF) driven in their composition (as I believe they should be). This may be more suitable for a model/template proxy thing though (I do believe the model knows more about the volatility of data than any other layer though).
Basically by making you focus on having your data as RDF. This makes it unnecessary to write syndication of content ad-hoc, while at the same time making you focus on how to create and handle RDF data, which I think is a good thing. How much of this you expose, and by what means (embedded in web pages or accessible through a SPAQRL service) isn't much facilitated today (although the RdfAspect may be helpful). This may be done better by exposing a SPAQRL interface to your data storage directly. Still, it may be within the scope of Oort to assist in this.
An auxiliary goal is to show that RDF isn't nearly as academic and difficult to understand as it may first appear. Oort lets you use it immediately with no complexity penalties, even less so than many other data layers ranging from internal object trees/graphs to SQL tables.