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

[Godfrey Rust <godfreyrust@dds.netkonect.co.uk>]

I agree with Tony's first para as one way of describing what the "underlying
abstract work" is. However, as DOI policy is that it can be assigned  to
anything,
unless the allocation rules are changed in a draconian way (with far
greater implications
than any syntax change), people will allocate DOIs to different digital or
physical manifestations 
as well as works, for all sorts of reasons. The allocation must allow for
this.

>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.

I don't agree with this conclusion. An identifier without secure reference
is meaningless.
If I use the name Tony Hammond and you later come along and tell me that it
really
refers to Eric Hellman, all transactions I have based on it are, or may be,
invalid. If
you give a DOI to something and I think its a digital manifestation and you
later
come along and tell me its a work, the same applies. The point of the
"kernel" was
to give DOIs some reliable meaning. If the number is dumb and the metadata is 
changeable, we have nothing but a dumb number and our own best guesses. I
realise
of course that in a local environment among people who generally mean the
same things
by what they say, this is not completely useless. But DOI's policy goes far
beyond that; and
even in the local environment of journal articles there seems to be
sufficient confusion
about what is or should be being identified that it makes sense to pin it
down and stick to a
few rules and guidelines. 

Godfrey



At 11:17 AM 3/23/99 +0000, tony_hammond@harcourtbrace.com wrote:
>
>
>
>
>
>
>
>
>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.)
>
>
>
>
>
>
>
>
>------------------------------------------------------
>Discuss-DOI maillist  -  Discuss-DOI@doi.org
>http://www.doi.org/mailman/listinfo/discuss-doi
>
>
Godfrey Rust
..........................................
Data Definitions
14 Gloucester Road
London W5 4JB
T (44) 181 567 1047
F (44) 181 579 0938
Mobile  07775 908398



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