[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Metadata] Re: [Discuss-DOI] DOI for reference linking
Sally:
Looks like you've hit on a key point. We're not just talking about the
difference between bits and atoms. We've also got to differentiate between
networked bits and non-networked bits. What is the difference between a physical
and a digital manifestation if they're both disconnected from the rest of the
world? And yet that PDF on the CD-ROM is identical to the PDF on the Web, only
not accessible. And this impacts on resolution discovery.
Also your assumption of intermediate pages which a DOI will resolve to is likely
to be the norm in the complex and managed resolution system that is the DOI
system. DOIs are not generally going to be assigned to freebies. The "URI
Discussion Paper" by Titia van der Werf-Davelaar is very informative here with
the notion that different identifiers will coexist (ie PURLs, and DOIs) with
different purposes.
Tony
From: "Sally Morris" <sally@morris-assocs.demon.co.uk> AT ~internet on 18/03/99
21:53 EST
To: "Norman Paskin" <n.paskin@doi.org> AT ~internet@CCMAIL
cc: "Metadata list" <metadata@doi.org> AT ~internet@CCMAIL, "DOI"
<discuss-doi@doi.org> AT ~internet@CCMAIL (bcc: Tony
Hammond/AP/LDN/HARCOURT)
Subject: [Discuss-DOI] DOI for reference linking
Very interesting paper - the clarification of the need to identify the Work
itself, as well as any Manifestations of it, is invaluable.
A couple of things which could need further thought:
Manifestations, both physical and digital, and performances, may all have
'intermediate' pages to which a DOI can resolve (information, order form or
whatever). That is in fact all that physical manifestations and performances
can resolve to in the digital environment, although digital manifestations can
also resolve to the object itself (although they will not do so, in the absence
of an 'e-commerce in IP' infrastructure, unless it is available free of charge).
Works, on the other hand, I don't think do have such intermediate pages since
you cannot actually order/obtain a work.
All of the above do permit resolution of a DOI to a metadata record, and in fact
this is likely to be an extremely useful resolution for all sorts of purposes
and services.
In the case of journal article citations, one very likely (perhaps the most
likely) scenario is that the citation link will first resolve to the article
abstract. I don't think it is correct to see this simply as metadata
(Description); it can be very much a tradeable entity in its own right, whether
it is created by the author, the publisher or a third party (e.g. A&I service).
The abstract then links to the full article, normally subject to specific
commercial hurdles (e.g. 'are you a subscriber'). This may therefore need to
be built into your model of how citation linking works (and this implies that
the abstract will require its own DOI).
The perhaps unwelcome conclusion is that one journal article will need several
DOIs with supporting metadata - work, physical manifestation(s) (print),
physical manifestation(s) (CD-rom), digital manifestation(s), and the same again
for the abstract. How to make this palatable to publishers is an interesting
dilemma!
A couple of points of detail:
You refer interchangeably to 'Physical' and 'Print' manifestations. This is
not strictly correct - a CD-rom is, in the INDECS model, a physical and NOT a
digital manifestation.
Your diagrammatic classification of 'Type' would, I think, be better if Work,
Manifestation and Performance were all on one logical level, and the
alternatives Physical and Digital (for Work only) on the next level down.
All Type values, apart from Work, need to refer to the Work
All Origination values, apart from Original, should refer (shouldn't they?) to
the foregoing Work(s) to which they relate
Kernel elements for all DOI genres cannot, I think, make it normally mandatory
to include an identifier from one or more other schemes. Only if it exists
already - to create a new ISBN, ISSN or whatever purely for these purposes would
be nonsensical, surely?
URL resolution cannot be mandatory - work does not resolve to a URL; physical
manifestations, performances can only resolve to an intermediate URL.
Journal article kernel needs to state Form - Type may be Manifestation:
Physical but this does not tell you if it's print or CD-rom, and this is
necessary
Publication date may not be a meaningful concept when an article is first
mounted in digital form - this may be before it has been allocated a 'place' in
a journal issue (e.g. 'As soon as publishable' service).
Online-only journals may not have issues at all, and certainly won't have pages.
I still can't see what need there is for a Publisher field in a citation linking
service
'First (xxx) manifestation' might be better named 'primary' since the language
does not then necessarily imply that it is chronologically first (for example,
the 'first manifestation' of a journal article initially mounted in the 'As soon
as publishable' service might, functionally, be the formally published one with
pagination etc.)
You tend to refer throughout to the 'Publisher' assigning the DOI etc. While
this is an understandable assumption for ex-publishers like you and me to make,
it is not necessarily the case. Language needs to be scrupulously neutral to
avoid alienating other players in the information chain.
One operational matter still concerns me. While I absolutely see the value of
creating citation linking services as soon as possible, as a positive
demonstration to all concerned that the DOI can deliver services of value to the
information chain, I am unconvinced that this should properly be operated by or
even under the auspices of DOI. Creating a standards and technical
infrastructure to make it possible - yes, absolutely! But actually operating
it - dangerous. I think this could be seen as monopolistic, or a least
distinctly anti-competitive, and is more properly left to commercial players in
the marketplace, of which there are plenty.
Sally Morris
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META content=text/html;charset=iso-8859-1 http-equiv=Content-Type>
<META content='"MSHTML 4.72.3110.7"' name=GENERATOR>
</HEAD>
<BODY bgColor=#b8b8b8>
<DIV><FONT color=#000000 size=2>Very interesting paper - the clarification of
the need to identify the Work itself, as well as any Manifestations of it, is
invaluable.</FONT></DIV>
<DIV><FONT color=#000000 size=2></FONT> </DIV>
<DIV><FONT color=#000000 size=2>A couple of things which could need further
thought:</FONT></DIV>
<DIV><FONT color=#000000 size=2></FONT> </DIV>
<DIV><FONT size=2>Manifestations, both physical and digital, and performances,
may all have 'intermediate' pages to which a DOI can resolve (information, order
form or whatever). That is in fact all that physical manifestations
and performances can resolve to in the digital environment, although digital
manifestations can also resolve to the object itself (although they will not do
so, in the absence of an 'e-commerce in IP' infrastructure, unless it is
available free of charge). Works, on the other hand, I don't think
do have such intermediate pages since you cannot actually order/obtain a
work.</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>All of the above do permit resolution of a DOI to a metadata
record, and in fact this is likely to be an extremely useful resolution for all
sorts of purposes and services.</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>In the case of journal article citations, one very likely
(perhaps the most likely) scenario is that the citation link will first resolve
to the article abstract. I don't think it is correct to see this
simply as metadata (Description); it can be very much a tradeable entity
in its own right, whether it is created by the author, the publisher or a third
party (e.g. A&I service). The abstract then links to the full
article, normally subject to specific commercial hurdles (e.g. 'are you a
subscriber'). This may therefore need to be built into your model of
how citation linking works (and this implies that the abstract will require its
own DOI).</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV>
<DIV><FONT size=2>The perhaps unwelcome conclusion is that one journal article
will need several DOIs with supporting metadata - work, physical
manifestation(s) (print), physical manifestation(s) (CD-rom), digital
manifestation(s), and the same again for the abstract. How to make
this palatable to publishers is an interesting dilemma!</FONT></DIV></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>A couple of points of detail:</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>You refer interchangeably to 'Physical' and 'Print'
manifestations. This is not strictly correct - a CD-rom is, in the
INDECS model, a physical and NOT a digital manifestation.</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>Your diagrammatic classification of 'Type' would, I think, be
better if Work, Manifestation and Performance were all on one logical level, and
the alternatives Physical and Digital (for Work only) on the next level
down.</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>All Type values, apart from Work, need to refer to the
Work</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>All Origination values, apart from Original, should refer
(shouldn't they?) to the foregoing Work(s) to which they relate</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>Kernel elements for all DOI genres cannot, I think, make it
normally mandatory to include an identifier from one or more other
schemes. Only if it exists already - to create a new ISBN, ISSN or
whatever purely for these purposes would be nonsensical, surely?</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>URL resolution cannot be mandatory - work does not resolve to
a URL; physical manifestations, performances can only resolve to an
intermediate URL.</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>Journal article kernel needs to state Form - Type may be
Manifestation: Physical but this does not tell you if it's print or
CD-rom, and this is necessary</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>Publication date may not be a meaningful concept when an
article is first mounted in digital form - this may be before it has been
allocated a 'place' in a journal issue (e.g. 'As soon as publishable'
service). </FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>Online-only journals may not have issues at all, and certainly
won't have pages.</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>I still can't see what need there is for a Publisher field in
a citation linking service </FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>'First (xxx) manifestation' might be better named 'primary'
since the language does not then necessarily imply that it is chronologically
first (for example, the 'first manifestation' of a journal article initially
mounted in the 'As soon as publishable' service might, functionally, be the
formally published one with pagination etc.)</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>You tend to refer throughout to the 'Publisher' assigning the
DOI etc. While this is an understandable assumption for
ex-publishers like you and me to make, it is not necessarily the
case. Language needs to be scrupulously neutral to avoid alienating
other players in the information chain.</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>One operational matter still concerns me. While I
absolutely see the value of creating citation linking services as soon as
possible, as a positive demonstration to all concerned that the DOI can deliver
services of value to the information chain, I am unconvinced that this should
properly be operated by or even under the auspices of DOI. Creating
a standards and technical infrastructure to make it possible - yes,
absolutely! But actually operating it - dangerous. I
think this could be seen as monopolistic, or a least distinctly
anti-competitive, and is more properly left to commercial players in the
marketplace, of which there are plenty.</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV> </DIV>
<DIV><FONT color=#000000 size=2>Sally Morris</FONT></DIV>
<DIV> </DIV></BODY></HTML>
Received: from frank.harcourtbrace.com (frank.harcourtbrace.com
[167.208.101.32]) by smtpgate.harcourtbrace.com with SMTP
(IMA Internet Exchange 3.11) id 0021B27F; Thu, 18 Mar 1999 17:09:42 -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 RAA21972;
Thu, 18 Mar 1999 17:10:00 -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 QAA25652;
Thu, 18 Mar 1999 16:59:47 -0500 (EST)
Received: by www1.cnri.reston.va.us (SMI-8.6/SMI-SVR4)
id QAA11235; Thu, 18 Mar 1999 16:58:29 -0500
Received: from cnri.reston.va.us by www1.cnri.reston.va.us (SMI-8.6/SMI-SVR4)
id QAA11202; Thu, 18 Mar 1999 16:58:26 -0500
Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net
[194.217.242.38])
by cnri.reston.va.us (8.9.1a/8.9.1) with ESMTP id QAA25584;
Thu, 18 Mar 1999 16:54:35 -0500 (EST)
Received: from [212.228.177.7] (helo=oemcomputer)
by finch-post-10.mail.demon.net with smtp (Exim 2.12 #1)
id 10NkkJ-00062d-0A; Thu, 18 Mar 1999 21:54:32 +0000
Message-ID: <007e01be7189$e74b90e0$07b1e4d4@oemcomputer>
From: "Sally Morris" <sally@morris-assocs.demon.co.uk>
To: "Norman Paskin" <n.paskin@doi.org>
Cc: "Metadata list" <metadata@doi.org>, "DOI" <discuss-doi@doi.org>
Subject: [Discuss-DOI] DOI for reference linking
Date: Thu, 18 Mar 1999 21:53:47 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative;
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Errors-To: discuss-doi-admin@doi.org
X-BeenThere: discuss-doi@doi.org