I think you have to make up your mind about what you want here.

Are you trying to define a *general interface* to any sort of Datalog-type database?  If so, you need to give up specifying a SRFI-167 OKVS and accept any sort of connection string with implementation-dependent meaning.  (Note that if the back end is genuinely Datalog, then even though this API provides no way to specify a new rule, it's still possible to use this SRFI to read records that don't actually exist in the database but are discovered by applying those rules.)

Or are you trying to specify the behavior of a *useful library* that supports this specific kind of database on top of an OKVS accessible via SRFI 167?  If so, you need to also specify *how* the data is stored in the back end (the marshaling/unmarshaling protocol and how records are stored as key-value pairs for efficient search) so that multiple implementations of SRFI 158 can interoperate on the same OKVS.  A SRFI implementer shouldn't have to read anything but the SRFI to make an interoperable implementation.

This is a really fundamental choice, and you can't go on trying to bridge it: you need to choose.

John Cowan          http://vrici.lojban.org/~cowan        xxxxxx@ccil.org
"But I am the real Strider, fortunately," he said, looking down at them
with his face softened by a sudden smile.  "I am Aragorn son of Arathorn,
and if by life or death I can save you, I will."