[Zope-Moz] RDF Use cases

[Brian Lloyd]

> RDF is indeed a standard for describing metadata. So you can say that
> you have a resource, an object (the "subject", in RDF jargon), and
> this object has a property (the "predicate"), and this property has a
> value (the "object"). The value can be either another resource, or a
> literal value. In RDF this is depicted either by a triple ({pred,
> subj, obj}), or by a directed graph (watch it, ASCII art):
> 
> 
>    .-~~~~~-.  predicate   +--------+
>   | subject |------------>| object |
>    ~._____.~              +--------+
> 
> With this datamodel, you can describe very complex structures,
> including an OODB. The subject can be anything that has a URI (URLs
> are a type of URI), so a Zope object will do fine. The subject could
> be http://www.zope.org/, the predicate RDF:type, and the object
> http://www.zope.org/Resources/ZopeRDFSchema#Application. With
> additional graphs, we can then also say what Zope properties are
> defined on the object, what security settings it has, and what
> subobjects it contains. And with a properly thought out Schema, we can
> also declare what classes Application inherits from.
> 
> This RDF datamodel can then be serialized in XML. XML is the default
> serialization syntax, but not the only one. The RDF Recommendation
> only describes the datamodel, not how to manipulate it, or how to
> propagate changes in the RDF model back to Zope.
> 
> But we can pull the RDF into Mozilla, and Mozilla allows you to query
> the RDF datamodel, and manipulate it. With XUL, the cross-platform
> user interface modeling language implemented in Mozilla, we can then
> display the data in the RDF, and allow a user to interact with it.
> Changes to the RDF datamodel can be detected, and then we can act upon
> those changes, by for example sending an XML-RPC call to the Zope
> server. This could be a way of implementing Visual Zope. We will
> however, think about how we would propagate changes in Zope (by other
> users or processes), into the datamodel in the browser.
> 
> The above description of the use of RDF in Zope is but one example,
> albeit an extensive and far reaching one. Zope would not actually be
> "doing" any RDF, it would only generate XML to represent a RDF
> datamodel.

I would disagree with that - at least at this point. While we may
decide in the end that supporting abstract RDF data model handling
in Zope may be more than we want to tackle right now, we shouldn't
prejudice our requirements process by ruling it out just yet.

I could imagine, for instance, an architecture where Zope 
provides a way of working with RDF Model objects, and a
developer could implement a new RDF vocabulary by building 
an appropriate Model object. There could be standard machinery
(maybe even in the Model object) for serializing the Model to
xml. Perhaps it would even be possible to do controlled 
intersections and unions of Model objects so that developers 
could easily build compound datasources by just joining together
some existing vocabularies and then serializing it.


> SC> Also, why not have the Zope Studio also query and 
> manipulate the Zope
> SC> objects through RDF only (vs having some other interface).
> 
> Because we want to keep Zope as open as possible. RDF would be one way
> of representing Zope data. WebDAV another. XML-RPC is one way of
> manipulating Zope, SOAP another.

They are not mutually exclusive though. My 2 cents on this is
that right now the first priority is RDF _production_, and 
that object manipulation from RDF is not within the scope of
the current effort. That said, an important tenet of our 
development process is that we try to design a stable 
architecture at the outset that will not only solve the 
immediate problem but that we also think will be able to 
handle future needs. So while _implementing_ manipulation 
from RDF is not within the scope of this project, it sounds
like making sure that our architecture does not preclude that 
possibility _is_ within the scope of the project.




Brian Lloyd        brian@digicool.com
Software Engineer  540.371.6909              
Digital Creations  http://www.digicool.com