Re: [Scrollkeeper-devel] Unique identifiers

[Ali A. <ali...@au...>]

* Dan Mueth (d-...@uc...) wrote at 23:54 on 28/11/00:
> 
> On Tue, 28 Nov 2000, Ali Abdin wrote:
> 
> > * Dan Mueth (d-...@uc...) wrote at 01:20 on 28/11/00:
> > > > We talked about this issue previously and we thought about an ISBN like
> > > > ID generated by a server available throughout the internet. This server
> > > > would generate unique IDs on request by document creators.
> > > 
> > > Alan and Daniel were kind enough to pop in on IRC to discuss scrollkeeper
> > > yesterday and the conversation quickly moved to UUID's.  They recommended
> > > (as Ali does) creating a UUID for each unique document.  Here a unique
> > > document is probably a {doc, version, language, format} quadruplet, or
> > > possibly even a superset of this.  It should uniquely specify the
> > > resource.  We will need to decide where this belongs in the OMF, perhaps
> > > an attribute to IDENTIFIER (ie. IDENTIFIER.UUID).  The UUID will be the
> > > database key.  To make things simple, we can ship a script which generates
> > > a UUID with scrollkeeper.  For systems with uuidgen, it will use that.  
> > > For other systems, we may want it to request one from a server which runs
> > > uuidgen (as suggested by Ali).  
> > 
> > It is important to point out that the UUID should not change for each
> > /version/ of a doc. If you have a doc and then update it, it will have the
> > _SAME_ uuid but a diff. version number, in my opinion. (by default, if you
> > just use UUID you will get the "latest" doc.)
> > 
> > Also - different formats should have the same UUID. They are the same
> > document, so they will have the same _METADATA_ (i.e. same author, same
> > version, same category, etc.)
> 
> One of the reasons we want a UUID is as a database key.  So it needs to be
> unique between multiple versions, formats, or languages of a document. 
> 
> We also want to guarantee that any two resources with the same UUID are in
> fact the same.  I'm not sure how we will want to handle multiple
> references to the same resource, but we will want to know if two resources
> are identical or not. This will be particularly important if we are ever
> merging multiple databases because you will have situations where both
> databases will refer to the exact same resource (although they may have
> different IDENTIFIERs.)  This is the reason for modifying the UUID for
> each version.

I think duplicates (i.e. "collisions") in of keys should be handled. I still
think that Documents that are the "same" (but diff. version) should have the
same UUID. If you want "further distinction" then you also use the version
key (and possibly file format).

If version and/or format is not specified then you just use the default
(latest version and some sort of priority-based format).
 
> I don't know if we would ever want to have duplicates of a resource in a
> database. (eg. http://www.foo.org/faq.sgml and
> file:/<stuff>/faq.sgml)  If this were the case, the database would need to
> use a key which combined UUID with a code generated from the IDENTIFIER.

No, just use the same UUID and allow the API to be a bit intelligent (i.e. by
specific version, format, wether to only return files installed locally, etc.)

You are saying that the UUID should be /always/ unique. I am saying there can
be duplicates.

Look at .oafinfo files, they do not changed their ID just because the oafinfo
file changes (I think).

> This is leaning slightly back to my original idea of basing the database
> key on the URL, but Alan and DV insisted that URL was not a good key and
> that we should use UUID's instead.

I agree with them :) and even if I didn't, I would still agree with them cos
they are better experts at this stuff.

Regards,
Ali