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

--
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
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to