[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Metadata] Re: [Discuss-DOI] DOI for reference linking
At 02:52 PM 3/22/99 -0500, Tony Hammond wrote:
>
>
>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.
>
I agree that whether someone would ever want or need to differentiate two
otherwise identical
PDFs with different DOIs simply according to context (web or CD-ROM) is an
important point. It is
only an example of the wider question of allocation of DOIs for local
resolution. In theory,
every occurrence of every otherwise identical item (physical, digital or
abstract) could be given
a DOI (that's my understanding of the extreme flexibility of IDF policy).
The controlling principle
is simply functional granularity: does it serve a purpose?
In the parallel print world, there seems general agreement that when giving
identifiers to printed articles the
context (i.e. the volume/issue/page number) is taken to be an element which
would make a creation
unique, so the appearance of the same article in another journal would
inevitably result in another DOI.
There is no reason why a similar practice might not develop for digital
media, although for contrast
in the record industry the appearance of the same track on different CDs
doesn't merit a new ISRC.
My point is that levels of granularity will be determined genre by genre,
and that the DOI mechanism
must be able to support it any level which business requires with precision.
I'm not quite sure what your conclusion is. My reading is that because DOI
can be anything to anyone,
it needs some clear rules about how people declare what it actually is in
any given environment.
Godfrey
>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
>
>
>
>
>
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