[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Metadata] Re[2]: [Discuss-DOI] Reference Linking: A Note on Syntax
It seems the Type Code puts information into the DOI string
about where the DOI might resolve to and I don't think it
should do that. Also, I don't think the Type Code would take
away the need for local systems to have, or refer to,
metadata. Also, I agree that we don't want to lock ourselves
into a convention like this to deal with a problem like local
resolution that might be solved in a totally different
manner.
My argument about context is that to use a DOI in a link, the
person (or system) creating the link will need some basic
metadata about what it is. In a library system, I don't just
see an ISBN, I see the title, author and maybe "Paperback,
ISBN xxxxx, Hardback, ISBN xxxxx". I don't think adding the
Type Code will take away the need to have this kind of
information.
Humans will be looking at DOIs on the screen but I don't
think a Type Code will give them any really valuable
information. Is the argument that the Type Code will give me
some indication about whether I can get at the object?
If I have a DOI with absolutely no other information - what
does "W", "P" or "D" really tell me?
Regards,
Ed
______________________________ Reply Separator _________________________________
Subject: Re: [Discuss-DOI] Reference Linking: A Note on Syntax
Author: Godfrey Rust <godfreyrust@dds.netkonect.co.uk> at ~internet
Date: 3/23/99 7:00 PM
>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.
>
>What we are trying to implement with the DOI is a 21st century identifier
(and
>beyond?). Instead we seem to be harking back to the baroque majesty of the
SICI
>code. Why W/P/D/R as a type code? Why the presumption of English in a URN?
Why
>capitalized? (I know that the Handle system may be indifferent to case but
the
>DOI is surely not limited to the Handle technology. And anyway capitals
>themselves are an older technology superseded by the lowercase, cursive
style -
>note also that the default case on most keyboards is lowercase.) Why the
>addition of a pair of parentheses? One (or none) is sufficient. We already
have
>the slash as a delimiter between prefix and suffix.
>
>I would further suggest that if we need to inspect the identifier it will
be at
>the machine level. No user is going to gaze on at the DOI string to elicit
>semantic evidences. If we really do need to incorporate this inline
intelligence
>then a single digit will suffice. (We have anyway always loosely talked about
>the DOI as a "number".) A digit would also be kinder on I18N. And a digit
lends
>itself more readily to extension as more categories may be conceptualized
later.
>(Of course, maintaining this intelligence in the associated metadata is
the more
>obvious route. Two years ago we didn't know about Works and
Manifestations. Two
>years hence, what other base types will we have discovered? Metadata can
always
>be augmented, the persistent identifier - the DOI - never.)
>
>For background it may be useful to consider Academic Press experience over 2
>years with the DOI which has been to decisively reject any intelligence in
the
>DOI suffix and to focus instead on metadata. In particular, the SICI
string was
>dicovered to be a non-viable identifier. For resolution discovery purposes
it is
>flawed both semantically and syntactically.
>
>Semantically, the identifier carries it's associated metadata inline and each
>and every piece of metadata must be known. A user cannot generate the string
>from standard bibliographic citations. To accommodate this shortcoming AP
>initially opted for minimal SICI codes where we retained only that minimal
set
>of metadata that could be derived from a citation. The next (and final)
step was
>to externalize the metadata. This allows us to make a citation match using
only
>a subset of the associated metadata.
>
>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.
>
>This has led AP to adopt their own production identifier as a viable suffx
>string, ie
>
> 10.1006/jmbi.1999.1234
>
>This is a robust identifier, primitive enough that it can survive in a wide
>range of environments without encoding. What it refers to will be evident
from
>its usage context. We have accepted that resolution discovery must be
metadata
>driven. The only intelligence in the "number" is that it is a URN (or
will be
>when registered as a NID) and that should be sufficient.
>
The form of Tony's suggestion seems fine to me: it's syntactic function
that counts,
not the specific character, and I accept the 21st century logic.
I would disagree on one point: I think people will be looking intelligently
at DOIs on
the screen. I think I recall Ed Pentz, in one argument for the current
syntax, saying
just the opposite - that he couldn't imagine a situation where people would
not be
looking at a screen and therefore be able to decide in context what it is.
I expect
the eventual truth lies between the two.
Godfrey
>
>
>
>
>------------------------------------------------------
>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
------------------------------------------------------
Discuss-DOI maillist - Discuss-DOI@doi.org
http://www.doi.org/mailman/listinfo/discuss-doi
Received: from frank.harcourtbrace.com (frank.harcourtbrace.com
[167.208.101.32]) by smtpgate.harcourtbrace.com with SMTP
(IMA Internet Exchange 3.11) id 00226149; Wed, 24 Mar 1999 22:03:23 -0500
Received: from cnri.reston.va.us (ns.CNRI.Reston.VA.US [132.151.1.1])
by frank.harcourtbrace.com (8.9.1/8.9.1) with ESMTP id WAA07752;
Wed, 24 Mar 1999 22:03:48 -0500 (EST)
Received: from www1.cnri.reston.va.us (www1 [132.151.1.143])
by cnri.reston.va.us (8.9.1a/8.9.1) with SMTP id VAA21360;
Wed, 24 Mar 1999 21:58:51 -0500 (EST)
Received: by www1.cnri.reston.va.us (SMI-8.6/SMI-SVR4)
id VAA27335; Wed, 24 Mar 1999 21:57:51 -0500
Received: from cnri.reston.va.us by www1.cnri.reston.va.us (SMI-8.6/SMI-SVR4)
id VAA27301; Wed, 24 Mar 1999 21:57:48 -0500
Received: from klingon.netkonect.co.uk (klingon.netkonect.net [194.62.44.11])
by cnri.reston.va.us (8.9.1a/8.9.1) with ESMTP id VAA21310;
Wed, 24 Mar 1999 21:57:46 -0500 (EST)
Received: from dds (dds [194.164.3.16])
by klingon.netkonect.co.uk (8.8.7/8.8.7) with SMTP id CAA11129;
Thu, 25 Mar 1999 02:44:14 GMT
Message-Id: <3.0.6.32.19990323190036.007ce3a0@mail.netkonect.co.uk>
X-Sender: godfreyrust@mail.netkonect.co.uk
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Tue, 23 Mar 1999 19:00:36 -0800
To: tony_hammond@harcourtbrace.com
From: Godfrey Rust <godfreyrust@dds.netkonect.co.uk>
Subject: Re: [Discuss-DOI] Reference Linking: A Note on Syntax
Cc: discuss-doi@doi.org, metadata@doi.org
In-Reply-To: <8525673C.004EEBED.00@harcourtbrace.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Errors-To: discuss-doi-admin@doi.org
X-BeenThere: discuss-doi@doi.org