From: Meltsner, Kenneth (Kenneth.Meltsner@ca.com)
Date: Wed Jun 28 2000 - 17:39:46 PDT
And of course, as in the book publishing world, the unique ID number for
each CD probably isn't unique. ISBNs (and the magazine equivalent, ISSNs)
are nearly unique for each book and format, but publishers make mistakes and
they are reused for different works or a single book gets two ISBNs by
accident, etc.
Same thing with alloy compositions -- the unique identifier for all alloys
and national specs often has a single number assigned to multiple alloy
specs.
It appears to be a universal fact: all schemes to assign unique identifiers
to each work (even disregarding additional issues like multiple printings,
with some corrections between print runs, that are often given a single
ISBN) are doomed to failure if you require true, relational DB-quality
uniqueness. Same with Dun and Bradstreet numbers, kind of, although it's
often the opposite problem: a single organization with too many IDs due to
mergers.
I think it's even happened with social security numbers. The only schemes
that appear to work (modulo typos) are the delegated admin numbering schemes
like OIDs.
There's probably a lesson or two here: Delegate numbering to the group
nearest the product. Don't expect perfect catalogs, but at least try to
keep track of the naming authority (to some manageable level of precision).
Don't use "unique" identifiers for database keys (or URNs?) since someday
you'll find the exceptions to the rule.
"Adam L. Beberg" wrote:
> So...
>
> You want to locate user created variants (different encoders) with
> arbitrary user entered labels (name, artist, ...)
>
> Good luck.
>
> You fix this by assigning unique ID's to bands, albums, songs, etc.
> Oddly enough they've already done this. There's a little bar code on
> every CD ever stamped out. Song have strait ASCII names (which _should_
> be unicode) right on the CD, and the filler has info on every other
> tidbit.
>
> So the problem was solved ages ago. The error is that noone uses that
> solution, but users type in whatever they want instead. But then, it is
> a system designed for theft, so dont expect much public coordination.
> It's like asking all the burglars to use the window in the southeast
> corner and always at 3:27AM.
>
> The larger fix is cryptographic hashes of the song of course. But you
> need a legal and centralized database for that, so only the MPAA can
> pull that one off very well, and then the questions is why they would
> do such a thing.
>
> I doubt napster and friends will easily expand beyond MP3's, other types
> of digital content have more years of experience combatting online
> piracy, like the SPA and friends. Not to mention legal things are
> already well served with established protocols.
>
> *sigh* Of course the whole thing just needs a good DFS :)
>
> - Adam L. Beberg
> Mithral Communications & Design, Inc.
> The Cosm Project - http://cosm.mithral.com/
> beberg@mithral.com - http://www.iit.edu/~beberg/
This archive was generated by hypermail 2b29 : Wed Jun 28 2000 - 17:51:21 PDT