Download DOI workshop: Registration Agencies

Registration agencies: DOI deployment
doi>
doi>
NUMBERING
Any form of
identifier
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 pieces
of current data
POLICIES
DOI adds value
To do this incurs costs:
• Number registration
– validation, maintenance, metadata, guidance
• Infrastructure
– resolution service, scaling, development
• Governance
– rules, further development
DOI deployment; principles
• 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: advantages
• 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”?
IDF
Site 1
Site 2
RA 0
IP1
Site 3
RA 1
IP2
IP3
Site 4
Site 5
RA 2
IP4
IP4
RA 3
IP5
IP6
RA layer
•Registration Services
•MD Collection
•Provision to VAS
•etc.
IP owners
IDF
DOI operational roles
Site 1
Site 2
RA 0
IP1
Site 3
RA 1
IP2
IP3
Site 4
Site 5
RA 2
IP4
IP4
RA 3
IP5
IP6
IP owners: register DOIs with agency
RA layer
•Registration Services
•MD C ollection
•Provision to VAS
•etc.
IP owners
IDF
DOI operational roles
Site 1
Site 2
RA 0
IP1
Site 3
RA 1
IP2
IP3
Site 4
Site 5
RA 2
IP4
IP4
RA 3
IP5
IP6
RA layer
•Registration Services
•MD C ollection
•Provision to VAS
•etc.
IP owners
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
IDF
DOI operational roles
Site 1
Site 2
RA 0
IP1
Site 3
RA 1
IP2
IP3
Site 4
Site 5
RA 2
IP4
IP4
RA 3
IP5
IP6
RA layer
•Registration Services
•MD C ollection
•Provision to VAS
•etc.
IP owners
IDF: minimal common agreements
- DOI resolution service
- service integrity
- Data Type Registries
- Policies e.g. archiving, testing, etc
Registration agencies run the system
Operating costs
$
Operating
Federation
(all the RAs)
$
Costs/N
RA
$
IP
DOI deployment: organisation
development spend
cost-reduction
Operating
Federation
IDF
M
&
RA
IP
DOI deployment: organisation
IDF
M
RA
c
Registration agencies and IDF representation
• Appoint RA membership to elected board
– initial 3/12 seats (25%)
– first RA seat allocated
• possible target: % seats = % income?
• future evolution of the organisation
DOI deployment: initial organisation
IDF
75%
M
25%
RA
IP
Terms between Registration agencies and IDF
• 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
Issues (1): Functional v national
• 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 (2): Value of metadata
• 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 (3): Make metadata available (syntax)
• 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 (4): Which metadata? (semantics)
• 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
DOI Genre 1
Compulsory kernel metadata for any DOI
Compulsory metadata for this Genre
All metadata in well-formed structure
Issues (5): Mis-use
• 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 (6): Explaining
• “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 (7): Building on incomplete foundations
• 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 (8): quality control
• 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 (9): Business models
• 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
IDF / Operating Federation
RA
RA
C
C
RA
C
Issues (10): relation to existing schemes?
• 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 (11): management of standards
• 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)
Registration Agencies
• Basis for Deployment outlined (end of 1999)
– cost recovery
• RA Working Group: initially 3 members/RAs
Terms document - now available
Letter 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
IDF in relation to 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