Registration agencies: DOI deployment

doi>

POLICIES

Any form of identifier

NUMBERING

DESCRIPTION

<indecs> framework:DOI can describe any form of intellectual property, at any level of granularity

ACTION

Handle resolution allows a DOI to link to any and multiple piecesof current data

doi>

To do this incurs costs:• Number registration

– validation, maintenance, metadata, guidance

• Infrastructure– resolution service, scaling, development

• Governance– rules, further development

DOI adds value

• DOI free at point of use• Costs of assignment paid by assigner• Allow different business models

– allow anyone to do what they want

• Distributed system– agencies

DOI deployment; principles

• IDF to provide governance layer only– using a federation of registration

agencies• IDF sets out minimum criteria for

registration agencies:– rules of the road: not journey maps– technical; information management; $

• Does not prescribe details of individual businesses

• Comparable models work well:– EAN/UPC; Visa; ISBN etc.

DOI deployment; principles

• Variety of potential business models– currently $1000 per prefix one off– one size does not fit all; need more

flexibility• Variety of naming authority models

– currently one per registrant– move to appropriate level; e.g. journals– allow subdivision (10.1000.2/123)

• RA’s will probably offer applications– number registration alone not a “business”?

DOI deployment: advantages

Site 1 Site 2 Site 3 Site 4 Site 5

IDF

IP1 IP2 IP3 IP4 IP4 IP5 IP6IP owners

RA 0 RA 1 RA 2 RA 3RA layer•Registration Services•MD Collection•Provision to VAS•etc.

DOI operational roles

IP owners: register DOIs with agency

RA 0 RA 1 RA 2 RA 3RA layer•Registration Services•MD Collection•Provision to VAS•etc.

Site 1 Site 2 Site 3 Site 4 Site 5

IDF

IP1 IP2 IP3 IP4 IP4 IP5 IP6IP owners

DOI operational roles

Registration agency:- agreements with IP owners*- registration with DOI system (IDF terms)- metadata collection /added value*- provision of, or to, Value Added Services

by agreement*, etc

* specific to each RA

RA 0 RA 1 RA 2 RA 3RA layer•Registration Services•MD Collection•Provision to VAS•etc.

Site 1 Site 2 Site 3 Site 4 Site 5

IDF

IP1 IP2 IP3 IP4 IP4 IP5 IP6IP owners

DOI operational roles

IDF: minimal common agreements- DOI resolution service- service integrity- Data Type Registries- Policies e.g. archiving, testing, etc

RA 0 RA 1 RA 2 RA 3RA layer•Registration Services•MD Collection•Provision to VAS•etc.

Site 1 Site 2 Site 3 Site 4 Site 5

IDF

IP1 IP2 IP3 IP4 IP4 IP5 IP6IP owners

Registration agencies run the system

Operating Federation

(all the RAs)

RA

IP

Operating costs

Costs/N

$

$

$

DOI deployment: organisation

Operating Federation

RA

IP

IDF

M &

cost-reduction development spend

DOI deployment: organisation

IDF

M RA

c

• Appoint RA membership to elected board– initial 3/12 seats (25%)– first RA seat allocated

• possible target: % seats = % income?

• future evolution of the organisation

Registration agencies and IDF representation

DOI deployment: initial organisation

IDF

M RA

75%

25%

IP

• Common agreement– level playing field– recognise differences in scale

• Franchise model• Initial financial model (2001)

– 2 cents per DOI allocated– membership of IDF – minimum $20K in 2001

• Initial working group– Terms– Letter of Intent (now available)– add more members

Terms between Registration agencies and IDF

• Functional (application) agencies– applications across borders (e.g. CrossRef)

• National/regional DOI agencies – local services– language documentation– integration with other agencies e.g. ISBN

Issues (1): Functional v national

• DOI metadata is a small basic set– likely not to be of commercial value

alone• Resolution provides “known item”

– DOI look up only• Metadata is not held in DOI system

– only a pointer to it• Metadata promotion maximises value

– like a catalogue

Issues (2): Value of metadata

• On a web page; <meta> tag; etc– easy to do, unstructured

• XML (Extensible Markup Language)– logical syntax, wide support, needs more to guarantee

interoperability

• RDF (Resource Description Framework)– Syntax for interoperable semantics; standard still

evolving. Questions as to acceptability

• Separate database– easy but raises issues of access

• Pointer entry (data type) in DOI record– best guarantee of commonality; likely to be introduced

Issues (3): Make metadata available (syntax)

• DOI approach based on <indecs> work– practical implementation ONIX etc

• “DOI Genre” for each i.p. type– functionally (arbitrarily) defined

• Incorporates a common DOI kernel:– DOI; DOI genre; Identifier (legacy); Title– Type (work, manifestation, etc)– Origination (original, derivative, replica, etc)– Primary agent and agent role

• Further articulation and guidelines

Issues (4): Which metadata? (semantics)

DOI Genre 1

Compulsory metadata for this Genre

DOI Genre 2

D

OI G

enre

3

Compulsory kernel metadata for any DOI

All metadata in well-formed structure

• Seen already:– duplication of prefix; DOIs not entered

into directory; citing of early DOIs• Who will determine rules?

– May be different guidelines for different areas

• and who will police them?• Some checks can be built into system

– e.g. attempted duplication

Issues (5): Mis-use

• “missionary work”– identifiers: precision about what is

identified (ISO TC46?)– functional granularity; well-formed

metadata, etc.• who will pay for this?• what can we learn from other efforts?

– e.g. ISBN• Best explained by examples: applications• Encouraging signs of take off

– e.g. E Books

Issues (6): Explaining

• DOI only now going from “zero genre” to compulsory Genre metadata – pioneering difficulties

• Resolution technology not ubiquitous– plug-ins and proxies are work arounds

• Who “owns” <indecs> compliance? • Guidelines are incomplete/evolving

Issues (7): Building on incomplete foundations

• Who defines Genres and mappings, ensures conformance?– e.g. DOI-X, Crossref (journal articles)– IDF “testing service” at cost?

• Who ensures quality control of content?• Who is the authority for each element?• What are the business model

implications?

Issues (8): quality control

• DOI Registration Agencies– based on similar models – e.g. UPC/EAN bar codes, ISBN

• Relationships between:– agencies and IDF– agencies and customers– agencies and agencies

Issues (9): Business models

IDF / Operating Federation

RA

CC C

RA RA

• Many ISO entities have metadata records– ISBN, ISSN, etc - widely used

• May not be consistent with each other• May not be consistent with indecs

mapping• May not be available for DOI registration

on ideal “do it once” basis– commercial considerations of those

agencies• Can metadata be shared?

Issues (10): relation to existing schemes?

• DOI and indecs based on open standards• Who directs evolution?

– governance structure, maintenance agency (NISO standard)

– likely not to be of commercial value alone• Who will invest the resources necessary to

make improvements and prevent stagnation?– IDF set up as collaborative forum– Long term funding and sustainability?– Funding through use (like bar codes)

Issues (11): management of standards

• Basis for Deployment outlined (end of 1999)– cost recovery

• RA Working Group: initially 3 members/RAsTerms document - now availableLetter of Intent - now available

• CrossRef first RA to sign up• 10-15 other RA candidates discussing with

IDF• RAs will be part of the Foundation

– governance and close collaboration

Registration Agencies

• does not own or direct– RAs are independent businesses, members of the

Foundation, part of agreed operating federation

• does not compete with existing agencies – (e.g. ISBN): we mandate declaration of ISBN etc.

• does not determine business models– needs to be done by the sector

• does not enforce one single metadata standard– just principles

• neither “privatises” nor “liberates” data– only a minimal kernel (like book title)

• provides community focus and consensus

IDF in relation to Registration Agencies