[Dev] RDF vs Python Objects

David McCusker david at treedragon.com
Tue Nov 26 14:35:58 PST 2002


Katie, Morgen, and I had a meeting to go other the plan for general
interaction between Python objects and RDF, and objects and RDFS
(for RDF schemas).  I was going to write something vague, but now
I can write something more specific after I draw an image I can post
on a web page for reference.

The general situation is this.  Python is _really_ dynamic.  We can
generate Python objects from RDFS and vice versa.  When we import
RDFS, we can load the corresponding .py files (if any) to get the
app writers preferred implementation when one exists.  And if no
.py version is found, we can generate classes at runtime instead.

And when the .py files are missing things present in the RDFS schemas,
we can add the parts missing from the Python code.  Actual conflicts
between RDFS and Python code can be reported as warnings when running
under development mode.  (We should not bother end users with conflicts
other than perhaps notes in a processing log.)

The import from RDF and RDFS to Python will be mediated by Python
objects with some interface to be designed (real soon now), and the
export from Python to RDF and RDFS will by mediated by other Python
objects in the other direction.

Import from RDF for data implies a SAX parser for streaming, so no
arbitrarily large DOM structure lives in memory before import of
data can execute.

The opposite direction from Python to RDF probably involves another
streaming interface of some kind.  (What is the general stream API
in Python which is satisfied by files, sockets, and in-memory buffers?)

Import from RDFS to create schema objects can create an in-memory
data structure (either DOM or some friendly native Python form),
because schemas will not generally be so large that a stream parse
with a SAX parser is needed.

I'll write more after I draw a diagram.

--David McCusker




More information about the Dev mailing list