[redland-dev] How to manage the 'subject'

[Christopher Schmidt]

On Wed, Aug 17, 2005 at 01:11:40PM +0200, Yann Klis wrote:
> Hi Folks,
> 
> Another noob question.
> In a database table, to identify a specific data in the data set, you 
> generally use an "id". That "id" could be auto incremented. And 
> generally you let the database handle that "id".
> In the RDF world, that id is reprsented by the subject part of a 
> statement (correct me if I'm wrong). Of course, in the RDF world you can 
> do much more powerful things with a triple.
> But, you, real people, how do you manage the subject part of a triple? 
> You manage an id in your program? You do better things?

That ID has to be managed at some level above the RDF api, yes. If there
is some unique resource for the node, however, there is no need to use
the typical database ID (Which is numeric). Say, for example that my
unique username on a website is crschmidt: then, instead of using a
numeric ID attached to some URI, I can instead just coin a URI:

http://example.com/users/crschmidt

Then, so long as that last part is unique (no two users named crschmidt),
I can use this subject node as an identifier, or a unique key. This
could also be done with something like an md5 hash of some subset of 
the data, or even a significantly random value, depending on your 
exact use case.

Another alternative is to store the highest value used so far as a key
in the storage: (r1234r1) myapp:primaryKey "5", as well as storing it at
the application level, perhaps in some temporary cache. This saves you
the work of finding the previous primaryKey every time you want to add a
new value: however, be aware that threaded applications may cause this
to not work quite as you expected if your "increment this variable"
function is non-blocking. (Perhaps http://danga.org/memcached/ would be
a good solution if you're under high load: the incr function is atomic,
meaning you could store the key in a small memory instance with no
concerns.)

-- 
Christopher Schmidt

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.gnomehack.com/pipermail/redland-dev/attachments/20050817/fb31cb84/attachment.pgp