A Standard Digital Identifier: - DOIs

A Standard Digital Identifier: 

the key to effective rights 

management 

Norman Paskin 

The International DOI Foundation 

doi> 

March, 2000 (c) 2000 Int DOI Foundation 1

• “Content” future is tied to “Internet” 

– shift to electronic dissemination 

– media types converge 

• Issue: name content in a digital environment 

– compatible with existing systems 

• International DOI Foundation 

– develop and implement an open standard: DOI 


Outline 

• DOI = Digital Object Identifier 

• The business case 

• The technology 

• The intellectual property framework 

• Deployment (making it happen) 

• Issues and next steps 


Outline 

• What is DOI? 







What is DOI? 

• A unique resolvable identifier…. 

• and multiple pieces of associated state data... 

• in an information management substrate. 

• Let’s expand that…... 


What is DOI? 

• A unique identifier…. 

- of a piece of intellectual property 

- defined by some key metadata 

- an opaque string e.g. DOI:10.1000/123 


What is DOI? 

• “resolvable..” 

- routing, via proven internet technology, 

• “to associated state data”…. 

- one or more pieces of associated data 

- which are the current value of 

specified types of data (e.g. URL); 

- these data may be, or link to, services 


What is DOI? 

• “in an information management substrate…” 

- once the data has been obtained, it can interoperate 

with other data 

- e.g. about context (entity + user data) 

- to construct services and transactions 

- because data follows a generic interoperable 

architecture 


What is DOI? 

“A unique resolvable identifier and multiple pieces 

of associated state data in an information 

management substrate” achieved by: 

• Technical implementation + policies 

• Technical tools: 

– resolution: Handle System 

– intellectual property: framework 


Outline 








What should an identifier do? 

1. Identify the resource (the entity) 

• not its location 

• if the location changes the DOI stays the same 

– persistence 

• the same resource can be at several locations 

• overcomes problems with URLs 

– relationships, multiple instances 


The problem illustrated on the Web 

1. URL is not a persistent identifier 

- it refers to Location, not content 

2. Same content at two different URLs has two 

different identifiers - cannot use as common reference 

Web Browser 

User 

URL 

URL 

? 

“404 not found” 

“...has moved to…” 


Identifiers on the Web 

1. Don’t change the URL; “persistence is a social, not 

a technology, problem” 

Web Browser 

URL 

User 

M People do change URLs 

M There are good reasons to change URLs 

M Does not deal with multiple copies 


Making Identifiers identifiers on the persistent Web 

2. Assign a Name and use http redirect 

Web Browser 

User 

name 

URL 

URL 

M http Bookmarks and caches 

save the end point, not 

the name 

(in current browsers) 

M does not deal with 

multiple copies 


Identifiers on the Web 

3. Assign a Name and use resolver 

Web Browser 

User 

doi> 

URL 

URL 

M DOI provides name 

M Multiple resolution 


1. DOI is a persistent identifier 

2. DOI identifies the content, irrespective of the location 

DOI initial implementation 

10.1000/123 

Web Browser 

doi> 

User 

Resolution 

URL 


Full DOI implementation 

Multiple 

Resolution 

10.1000/123 

URL2 

Web Browser 

doi> 

URL 

URL 

User 

Data 1 

Actionable identifier 

Identifier resolves to any piece of data 

Data 2 

etc. 


Specified 

Action 

Resolution 

service 

10.1000/123 

URL2 

Web Browser 

doi> 

URL 

URL 

User 

Data 1 

Actionable identifier 

Service 1 @ 10.1000/123 

Data 2 

etc. 



2. An open standard system 

• Anyone can use it 

• Free at point of end use 

• Cost (small) paid when DOI is assigned 

• Local systems can be integrated 

– e.g. “local copy” 



3. A fully managed system 

• DOI assignment by content owner 

– agencies as intermediaries 

• conforming to overall policy rules 

• managed technology system 

• provides key information 



4. Can be applied to any i.p. entity 

• any (arbitrary) granularity 

• but predictable because of key data 

• does not replace existing systems but works 

with them 

– (ISBN, ISRC, etc) 

• a unifying identifier 

• deals with media convergence 



5. Associated metadata is structured 

• can express relationships between entities 

• interact with data from other sources 

– e.g. context 

• enables services (automated, predictable) to 

be constructed 



6. Extensible 

• resolution system has capability for trusted 

transactions 

• metadata framework has capability for full 

rights management architecture 


Why use identifiers? 


The business background 

• Digital world enables both use and protection 

• Aim is to maximise value of information objects 

(see Shapiro/Varian: Information Rules) 

- reduce copy infringement and 

- increase accessibility; 

- need to identify what it is you are managing 

• Mass production → mass customisation 

- components must be clearly identifiable 

- and terms defined 


The technology background 

(see Kahn/Cerf, www.internetpolicy.org) 

• Communication centric view (now) 

• Information centric view (future) 

• Information object as a “first class citizen” 

• interpretable by all participating systems 


The intellectual property background 

• Identifiers of what? 

• Instances and classes 

• Related entities 

– Intellectual property entities may be derived or 

composite 

– e.g. excerpt, modification, compilation, 

performance…. 

• Enties may be tangible or intangible 


Physical manifestation of intangible work 

Manuscript 

mss #ABC123 

paper 

journal/volume/page 


URL 

“intangible Work” 

MS 

Vol/page; ISBN; 

SICI, etc 

“intangible 

Work” 


Not just digital 

• E-commerce of intellectual property: 

– transaction of i.p.; and/or 

– transaction of rights about i.p. 

• Therefore “DRM” implies: 

– management of digital rights; and/or 

– digital management of rights 

• Similarly: DOI implies: 

– identifier of digital object; and/or 

– digital identifier of object 

(DOI’d entities may be tangible or intangible) 



DOI: development in three tracks 

Metadata 

Single redirection 

Multiple resolution 

Other initiatives 

Initial 

implementation 

Full 


Standards 

tracking 


Outline 








Handle System ® 

• Open Standard 

• Distributed, scalable 

• Enforces unique names (in our case, DOIs) 

• Conforms to standards e.g. URN/URI syntax 

• Associates a name with “values” (e.g. URL) 

• Optimized for speed and reliability 

• Provides infrastructure for application domains, 

e.g., digital libraries, electronic publishing…. 

• In use now 


Some Handle system initiatives 

• DOI (International DOI Foundation) 

• Library of Congress 

– National Digital Library Program 

– U.S. Copyright Office 

• NCSTRL (Networked Computer Science 

Technical Reports Library) 

• DTIC (Defense Technical Information Center) 

• USIA (U.S. Information Agency) 

• NMPA (National Music Publishers’ Association) 


Using Handle, DOIs Resolve 

to Multiple Data Types 

Handle (DOI) 

Data type 

DOI data 

10.1004/123456abc.html URL http://www.pub.com/. 

URL http://www.pub2.com/. 

DLS loc/repository 

Extensible Data Types XYZ 1001110011110 


Outline 








Intellectual property entities are 

described by metadata 

• a prerequisite of applications other than simple 

routing to one URL 

• e.g. go to “appropriate” copy 

– local copy; choose alternative source 

• e.g. “transact this item”; services about the item 

• e.g. relationships between items 

• makes DOI an “actionable identifier” 

= identifier + resolution + supporting data access 

• enables more complex applications 


DOI metadata requirements 

• “Resource description” (any “Creation”) 

• and Rights description (transactions, services) 

• Use existing systems (identifiers, data) 

– Do not reinvent the wheel 

• No ambiguity (“well- formed”); automation 

• 

DOI development 

Metadata 

Single URN 



Initial 


Full 



tracking 

March, 2000 (c) 2000 Int DOI Foundation 39 

4

• EC info 2000 

– 50% funding 

• Book industry standards 

EDItEUR 

• Record industry 

IFPI 

• Multimedia rights 

Kopiosto, Finland 

CAL, Australia 

CEDAR, Netherlands 

• Music rights 

MCPS/PRS, UK 

• Audiovisual rights 

SACD, France 

• Literary rights 

ALCS, UK 

• Visual rights 

BILD-KUNST, Germany 

• Database provider 

Muze Inc/Ltd, US/UK 

• DOI 

International DOI Foundation 

• Text sector 

IPA, STM, FEP 

ISBN, ISSN 

• Copyright sector 

CISAC, IFRRO 

US Copyright Office 

• Music sector 

RIAA, ICMP, 

IPD, RICI 

• Audiovisual sector 

SMPTE, BBC 

• Libraries 

IFLA/UBCIM, LC 

• International 

WIPO 

40

Metadata framework 

• Generic for all types of content 

– convergence renders differentiation meaningless 

• Focus is intellectual property management 

– but does not force one specific model of management 

• Enabling, not replacing, other schemes 

– creating an interface from specific sectors 

• Broad in scope 

– identification, description, transaction 

• Based on tested “real world” models 

–CIS; IFLA 


Practical way forward 

• a powerful analysis tool 

– e.g. one work/several formats (relationships) 

• practical results 

– e.g. EPICS, MerchEnt 

–XML/RDF expressions 

– common data dictionaries etc. 

•indecs ran from Nov 98-Mar 00 

– but used as a basis by IDF since early 1999 


Generic Data Model 

Commerce 

Data 

Dictionary 

Legal 

Data 

Dictionary 

Proposal 

Rights 

Transaction 

Model 

Directory 

of 

Parties 

Proposal 

Local maps 

Local maps 

RDF/XML 

Interchange 

EPICS, DOI, 

MerchEnt 

RDF/XML 

Interchange 


DOI framework for applications 

• Small set of “kernel” data for each DOI 

– Depending on intellectual property type 

– But interoperable (underlying data model) 

– Minimal data, commonly available 

• Define “genres” to describe each 

intellectual property type 

– e.g. journal article, image, video clip... 

• XML and terms 

– being launched now 


Outline 








DOI Deployment 

• IDF to provide governance layer only 

– using a federation of registration agencies 

• IDF sets out minimum criteria for 

registration agencies: 

– technical; information management; $ 

• Does not prescribe details of individual 

businesses 

• Comparable models we are examining: 

– EAN/UPC; Visa; ISBN etc. 


IP 1 IP 2 IP 3 IP 4 IP 4 IP 5 IP 6 

IP owners 

RA 0 RA 1 RA 2 RA 3 

RA layer 

•Registration Services 

•MD Collection 

•Provision to VAS 

•etc. 

IDF 

Site 1 Site 2 Site 3 Site 4 Site 5 

47


IP owners 

DOI operational roles 



VAS 

VAS 

RA layer 




•etc. 

IDF 

minimal common agreements 

•DOI resolution 

•Service integrity 

•Orphans 

•Type Registries 

•Policies e.g. Archiving? 

IP owners: register DOIs with agency 



IP owners 




VAS 

VAS 

RA layer 




•etc. 

IDF 




•Orphans 



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 



IP owners 




VAS 

VAS 

RA layer 




•etc. 

IDF 




•Orphans 



IDF: minimal common agreements 

- DOI resolution service 

- service integrity 

- Data Type Registries 

- Policies e.g. archiving, testing, etc 


DOI development 

Metadata 

Single URN 



Applications 

Initial 


Full 



tracking 

Oct 13, 1999 DOI 4 

DOI already in use : current implementation 

e.g. American Chemical Society: 

DOI as common identifier for a work, 

➜ page offers delivery options (formats etc) 

Now further applications - generic, interoperable, 

developing more sophisticated tools 

metadata framework 

multiple resolution possibilities 


Outline 








Issues (1) 

Metadata has value; why declare it? 

• 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) 

How to make metadata available? 

• tags in html 

– 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) 

Which metadata elements? 

• DOI approach based on early work 

• “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 

• Needs further articulation and guidelines 


Issues (4) 

Rules will be mis-used 

• 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) 

Concepts need to explained and promoted 

• “missionary work” 

– identifiers, well-formed metadata; functional 

granularity 

• who will pay for this? 

• what can we learn from other efforts? 

– e.g. Java? 

• Best explained by example: applications 

• Encouraging signs of take off 

– e.g recent New York DRM conference) 


Issues (6) 

Building on some areas of sand 

• DOI only now going from “zero genre” to 

compulsory Genre metadata 

– causes some misunderstanding 

• Resolution technology not ubiquitous 

– plug-ins and proxies are work arounds 

• RDF etc still not firm enough to build on? 

•Who “owns” compliance? 

• Guidelines are incomplete/evolving 


Issues (7) 

Metadata costs money 

• Who defines Genres and mappings, ensures 

conformance? 

– e.g. DOI-X, Crossref (journal articles) 

– IDF/indecs “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) 

Business models for implementation 

• DOI Registration Agencies 

– based on similar models e.g. bar codes, ISBN 

• Relationships between: 

– agencies and IDF 

– agencies and customers 

– agencies and agencies 


IDF / Operating Federation 

RA 

RA 

RA 

C 

C 

C 


Issues (9) 

Relationship with 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 (10) 

Management of standards 

• DOI and indecs based on open standards 

• If there is no clear sponsor, who directs evolution? 

– governance structure, maintenance agency 

– 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) 


Next steps 

• Registration agencies 

– business models, contracts 

• Applications and prototypes 

– new areas 

– multiple resolution 

• Further development 

– e.g. standardising services 


Next steps 

• Standards activities 

– W3C, ISOTC46, MPEG7, MPEG21, SDMI, 

NISO, IETF 

– avoid “Stereo AM” 

• Related activities 

– indecs framework, Handle 

• Finance activities to retain momentum 

– new round of marketing 


Summing up 

•“A unique resolvable identifier and multiple 

pieces of associated state data in an information 

management substrate” 

• Open development activity, moving to further 

deployment now 

• Much has been achieved, much to do 


Summing up 

• Identify any piece of intellectual property 

• An open standard 

• Fully managed system with associated data 

• Enable building of services 

• Extensible 

• Open technology: Handle, indecs 


Thanks to members 1998 - 2000 

Academic Press/Harcourt 

Addison Wesley Longman 

American Chemical Society 

American Mathematical Society 

Association of American Publishers 

Association for Computing Machinery 

Associazione Italiana Editori 

Authors Licensing and Collecting Society 

Baker & Taylor 

BioImage 

Blackwell Science 

Bokforlaget Natur Och Kultur 

Copyright Clearance Center 

EDP Sciences 

Elsevier Science 

European Music Rights Alliance 

Houghton Mifflin 

IEEE 

International Publishers Association 

ISI 

ISBN International 

JISC (UK) 

John Wiley & Sons 

Korean Publishers Association 

Kluwer Academic 

Microsoft 

National Music Publishers Association 

New England Journal of Medicine 

OCLC 

Publishers Licensing Society 

RCP Publishing Solutions 

SilverPlatter Information 

Springer Verlag 

STM Association 

Thomson Labs 

Xerox 


Further information 

• Conference paper 

• “DOI Annual Review” and “DOI Deployment” 

– www.doi.org 

• indecs “Building blocks” 

doi> 

– www.indecs.org 

• Handle system 

– www.handle.net 

• n.paskin@doi.org

A Standard Digital Identifier: - DOIs

Create successful ePaper yourself

Delete template?

Save as template?