[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Metadata] Version 3 of DOI discussion / consensus paper



A much revised iteration of the DOI discussion / consensus document
first posted in July will be posted to the DOI web site later today,
following incorporation of the changes suggested.  Version 3, August
1998,  is available from the Home page of the site (in pdf format)
(www.doi.org).  The document is now publicly available for information,
comment and debate and I am inviting criticisms from both Foundation
members and non-members, including all recipients of this discussion
mailer.  You are welcome to cross post this message to other relevant
lists.

Those who have been following the DOI discussion list will be aware of
the changes incorporated in this latest version which include scope
definition (all intellectual property, not just digital) and proposed expansion
to multiple resolution.

Although it is a lengthy paper, there is a one page summary/abstract
which I encourage you to read even if you go no further, which I have
also appended to this message as straight text.  Those of you who are
about to go vacation will be glad to have 32 pages of holiday reading ;-)

By consensus we have defined the scope of DOI to include non-digital
manifestations of content (so you can resolve to an order form for a
book, etc.).  There is also the existing key recommendation to work
towards expanding  the resolution process to allow multiple  resolutions.  

It may seem that this exercise is somewhat theoretical but I firmly believe
it is necessary to have a common agreed framework.  It has also
identified a key issue which we need to discuss.  A <killer application> of
the DOI has been viewed as reference linking (citation to article) using
metadata etc.  This remains the case and we are working on practical
ways to do this.  However it raises the issue of separably identifying a
Work citation and a specific digital version of the article (Object),
addressed in detail in the paper and first raised in the DOI discussion list.  
I would welcome continuing suggestions of how we achieve this.  As set
out in the paper, moving to full Handle implementation offers a long term
solution but is there an elegant short term solution?  (Putting intelligence in
the syntax; or restricting DOI handles to Works with qualifiers for
manifestations, have both been suggested as a means of doing this; are
these workable and enforceable? etc.)

Summary/abstract from the paper:

Sections 1-4 introduce a necessary common vocabulary and summarise
work to date; sections 5 is a scope statement; section 6 focuses on likely
future development; sections 7-11 on practical issues of implementation.  

There exists a commonly accepted architecture model for managing
information as digital objects (section 1.1); a component of this
architecture is the process of resolution (1.2).   There is no commonly
accepted equivalent model for intellectual content in general (irrespective
of medium) and the move to digital content management requires a
standard vocabulary to be defined (2.1) (including Creations, Works,
Packages and Objects) which makes a distinction in particular between
the identification of abstract works as in citations, for which standards
are still in development  (2.2) and the identification of tradeable digital
Objects manifesting  those works (2.3);  the DOI can be used to provide a
unique identification scheme useable with this data model.  It is also
necessary to give special consideration to identification of entities which
have a special relationship to those works, such as abstracts (2.4) and
dynamic collections of works (2.5).  In implementing a workable scheme it
is necessary to recognise that  some Creations are separably identifiable
but related and this must be discernible;  a key problem which remains is
the conflicting practical requirements of a Work identifier needed for
citations, and an Object  identifier needed for trading (2.6).  

The DOI initiative has received widespread support (3.1); the initial
implementation uses Handle technology (3.2) in a restricted sub set, with
few limitations on scope (3.3).  It is intended that the system be
developed further in a parallel tracks approach which will gradually
evolve an interoperable framework from early implementation experiments
(3.4).  The DOI is a system offered in conformance with existing and
evolving standards from both the content/information community (4.1) and
the technology/Internet community (4.2).  

The scope of the DOI is now defined as digital services offered against
Content, irrespective of whether the Content is digital or non-digital.  This
has the implication that whilst all digital Objects may have a DOI, not all
DOIs relate to digital Objects (5).

In order to develop the DOI further and offer DOI-based services, a
necessary distinction is drawn between content, services, and
mechanisms (6.1).  We make a new distinction of level 1 DOIs (using a
single data type value, as in the current implementation) and level 2 DOIs
(using multiple resolution values, necessary for more sophisticated uses)
which will require more sophisticated client tools  (6.2).  Metadata is
necessary to be associated with each entity assigned a DOI, in order to
create useful services (6.3).  Level 2 DOIs can be nested to create some
services (6.4).  Services could be provided against DOI identifiers in
several ways which are not yet defined in detail (6.5); practical steps to
achieve these services require definition of the services desired by
users, introduction of level 2 DOIs, appropriate support tools, definition of
DOI metadata set(s), and a means of grouping related identifiers (6.6).

The DOI system is already in use and will continue to evolve; some
guidelines can be given to facilitate common approaches: assign DOIs to
Creations, not Resources; assign separate DOIs to separate but related
Creations; treat services as a response page requiring manual user
intervention (possibly in a standard form) pending development of
automated services; do not assume that every portion of an existing Web
Presence should be associated with a DOI; and do not confuse what a
DOI identifies with what it resolves to (7).

The paper briefly discusses the assignment of DOI (8), usage (9) and
business model (10); each of these will need further expansion.  Section
11 provides a list of additional action points arising from the discussion
document.  








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