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()
    >>> IURIRef(obj2).n3()
    >>> 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:


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.


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.

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to