[Metadata] Re: [Discuss-DOI] Reference Linking: A Note on Syntax

[tony_hammond@harcourtbrace.com]

At 2:23 PM +0000 3/22/99, tony_hammond@harcourtbrace.com wrote:
   >Appendix 2 of the paper "DOIs used for reference linking"  introduces a
   >syntactic convention which purports to simplify the use of DOIs. Leaving
   aside >the thornier issue of whether we really need to assign DOIs to
   Creations (or >Works) - virtual things (ghosts?) which have no tangible
   existence and hence >cannot be experienced/consumed/enjoyed or in any sense
   known, I would like to >suggest that the proposed syntax is imperfectly
   conceived.


   I agree with Tony here. The distinction between a digital, physical, and
   abstract works (aren't we forgetting "Spiritual"?) is increasingly
   arbitrary.

Eric - Suddenly thought yesterday that I had said the wrong thing about Works
and Manifestations - not the syntax, mind, that is lousy - because the last
thing we want to do at this stage is to assign a DOI to each separate digital
manifestation (eg PDF, TeX, PostScript, etc). And yet, it's also true that an
abstract work by definition has no existence either. And this morning I'm
thinking that what we really want to identify is that set of (digital/physical?)
manifestations which have a functionally equivalent intellectual property
content - which I suppose is what is intended by the work in the abstract. Maybe
it's a question of terminology. Better though if it were grounded in some
vestige of reality.

I guess we see the DOI as the key to accessing in a networked context a piece of
intellectual property. This is not going to be a simple GET - the thing we are
after has an intrinsic value, hence the need to identify that property within a
controlled and managed resolution discovery system. There will need to be a
negotiation between content provider and content consumer (possibly automated,
although initially likely to take the form of an intermediate page). As far as
the syntax goes, we can't keep changing the locks, although we can alter the
contents of the safe and the inventory. The one thing that must be inviolate as
far as any _practical_ implementation is concerned is the identification string
itself - descriptions of what is actually being identified can always be
rejigged as required. The one known in implementing the DOI is the
identification string itself (at least, we thought we had even that!) -
associated metadata can be backfilled.

   >Syntactically, the SICI is a disaster. While version 2 was standardized in
   >1996,
   >it really belongs to an older time. It is based on ASCII. It is written in
   >English. It is true that it can be transported via SMTP, but it requires hex
   >encoding if used as a URI in HTTP, and it requires entifying if packaged
   >within
   >SGML/XML instances. The SICI is over-specialized.

   Tony, I recently finished implementing SICI-1 and SICI-2 in Java. Or at
   least I implemented thase parts of SICI which are implementable. With that
   experience, I would say the same things as you say, but I would say them
   less politely.


The only thing I miss about the SICI is my cute Perl routine to compute the
modulus 37 check character. There was a certainty about the process. (Computing
title codes was just a chore and broke down irretrievably at math - What is a
word, etc? Can't be done, like squaring a circle.)









------------------------------------------------------
Metadata maillist  -  Metadata@doi.org
http://www.doi.org/mailman/listinfo/metadata