Gary Poster wrote:
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?
Here's another way to work with intids that I think could work:
In rdflib in some backends like IOMemory, and internal id is found for a
subject (or predicate or object) to use in the internal storage
datastructures. rdflib uses some randid() for that.
I propose that instead of calling randid(), it called self.assignid(subject)
which would be pluggable. By default this would be the default randid, but
you could allow Zope to create a graph with an assignid that assigned ids
based on the intid service.
Then if a subject or object passed to rdflib is an integer instead of a URI,
it would be used directly. In effect you'd give access to the internal ids.
(There are more details to solve (assignid needs to check for collisions
sometimes), but I think that's a good starting point).
Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
Zope3-dev mailing list