[Zope3-dev] Re: RDFLib and Zope 3

[Gary Poster]

On Aug 23, 2005, at 8:07 PM, Michel Pelletier wrote:

> On Tue, 2005-08-23 at 18:04 -0400, Gary Poster wrote:
>
>
>> The relationship between ZODB content objects, their int id as
>> provided by the pertinent intid utility, and a (theoretical)
>> corresponding RDF URI is what I'm having a hard time not making hacky
>> in my mind.  I'll think about it some more.
>>
>
> They might not be that hacky, this might be the wrong direction to  
> take
> but URI's don't have to be visually meaningful, blank nodes, for
> example, are usually just '_:' concatenated to a random opaque string.
> If the URI were 'zope:XXXXXXXX' (maybe path/to/intid/util:XXXXXXXX)  
> that
> would work just as well, it would also be trival to transform into a
> feasible join key if the URI was also a URL that looked up, instead of
> some network resource, an intid.
>
> Actually being able to trivially transform an intid to an rdflib URI
> might be something to think about.  Thinking about it more, the  
> current
> Zemantic uses the physical path of the object as the rdf:about="" URI
> when an object adds itself, because honestly I could think of no other
> URI in Zope.  This is obviously wrong, but I didn't have a better  
> answer
> in paris.  Why not use the `intid` plus some URI sugar?  If the URI  
> and
> the intid can be easily converted from one to the other then that  
> should
> solve the whole problem, no?

I think this is on the right track, but I'd rather not have to deal  
with URIs except when it makes sense to deal with URIs.  I used the  
wrong phrasing when I asked about RDF "syntax": my question is why we  
need to tie ourselves to URIs, except at certain points in the  
software.  Intids are hardly portable across databases, so exporting  
and importing, using any flat file format, may be of limited value to  
us; therefore the URI limitation, needed for the standard RDF import/ 
export stories, is arguably of limited value.  (We don''t have to  
always use intids though, as intimated by my adapter story below.)

Imagine this doctest excerpt.

------------

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))
     >>> 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.  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.

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.

>> Another difficulty is that I like the RDF data model and the RDFLib
>> implementation, but I haven't found a compelling reason to care much
>> about the actual RDF format input and output.  Is there a practically
>> compelling defense of RDF as a format somewhere to which you can
>> point me?
>>
>
> I'm sure you're aware of this but for others: RDF does not specify a
> syntax, only the data model.  The most popular syntax, RDF/XML, is
> pretty bad, but rdflib also supports the NT syntax, which is a plain
> text format.  There are some other triple languages out there that may
> look even better, and support for them in rdflib would require writing
> only a parser and maybe a serializer if you want that format back out.
> I like SLIP but the parser needs some work:
>
> http://www.scottsweeney.com/projects/slip/
>
> and lastly I've been kicking around a new syntax based on SLIP I call
> SLIPR.  Unlike SLIP which is for any XML, SLIPR is RDF only.
>
> https://svn.cignex.com/public/slipr/data/pyinrdf.slpr
>
> I only have the syntax outlined right now, I'm still working on the
> parser.  This is my attempt to mix RDF with indented syntax.  It looks
> great in python-mode. ;)  Unfortunately this is low priority.  The  
> good
> news is the high priority is a SPARQL parser, which is coming along
> nicely.  Kudos to the fabulous pyparsing library. Hopefully we should
> have full sparql support by 2.4.

Cool.  I'll click around later today.

Gary