[Zope3-dev] Re: RDFLib and Zope 3

[Michel Pelletier]

On Wed, 2005-08-24 at 12:39 -0400, Gary Poster wrote:

> The Zope 3 back end for RDFLib allows you to use any intid-registered  
> object as a resource, as long as they are adaptable to  
> rdflib.interfaces.IURIRef.  The Zope 3 back end package provides a  
> simple adapter for all Zope content objects that are stored in an  
> intid utility, which you may use directly or as a model.  For  
> instance, take two content objects, obj1 and obj2, that are unaware  
> of RDFLib but registered in the current site's intid utility.  We'll  
> also assume we have a RDFLib storage named 'store', a 'FOAF' rdflib  
> namespace and resource, and the default adapter to IURIRef already  
> registered.
> 
>      >>> obj1
>      <Dummy Persistent Object>
>      >>> obj2
>      <Dummy Persistent Object>
>      >>> from RDFLib.interfaces import IURIRef
>      >>> IURIRef(obj1).n3()
>      <zope:path/to/intid/utility#12345>
>      >>> IURIRef(obj2).n3()
>      <zope:path/to/intid/utility#67890>
>      >>> store.add((obj1, FOAF['isPrimaryTopicOf'], obj2))

Yes this is good.

>      >>> store.serialize(format="pretty-xml') # '...' is wildcard;  
> example is probably wrong anyway
>     ...zope:path/to/intid/ 
> utility#12345...isPrimaryTopicOf...zope:path/to/intid/utility#67890...
> 
> ------------
> 
> Since Dan is already using Twisted in his app server, maybe he'd be  
> willing to let RDFLib drink the Zope interface Kool-Aid along with us  
> and Twisted. 

I know he's looked at it, and previously he used zope.server before
twisted.  I think he might be out for a couple of days, so we'll wait to
see what he thinks.  I wonder how "lite" the component kernel can go.

In the mean time the adapters can live inside Zemantic, which is an
rdflib to zope bridge anyway.  Let me know if you want to send patches,
otherwise I'll probably get around to adding functionality like this
soon.

>  If he adapted his resources during serialization, that  
> would let us leverage his serializers.
> 
> The loading from file is a slightly harder bit in that story, if you  
> care about it.  The Zope 3 backend needs to know all of the possible  
> URI spellings that might match a content object.  Not too bad.
> 
> With this, then, you just need to add the ability to get raw results,  
> maybe as defined by a graph back end, from query results (we'd want  
> IFBTree data types); and a way to convert raw results to 'real'  
> results.  That wants further API discussion, but feels doable.

Yep.

> It gets us URIs when we want them, but doesn't make us bow to them  
> when all we want is the data structure.
> 
> I'm not familiar with the RDF query language yet, so it may introduce  
> some issues, but I think the adapter story can help with that too.

A lot of the time you don't need to worry about the subject or object
URI, you can have sparql bind these to variable names.  For example:

PREFIX  x: <http://example.org/ns#>
PREFIX dc:  <http://purl.org/dc/elements/1.1/>

SELECT ?title ?price
WHERE
   ( ?book dc:title ?title )
   OPTIONAL { ( ?book x:price ?price ) AND ?price < 15 }

The URI, bound to ?book, is not output, but is used in the query by
name.

-Michel