Digital Object Identifier

1. Digital Object Identifier Norman Paskin The International DOI Foundation W3C DRM workshop January 22/23 2001 doi>

2. Perspective doi> • Content meets digital infrastructure • Digital Object Identifier (DOI), from • International DOI Foundation: a member of W3C • Topics covered: • issues • DOI

3. IDF Position paper doi> • See position paper for fuller details • During 3 years of development, we’ve encountered practical issues, in developing an identifier system within an architecture which recognises rights • Key influences: • INDECS analysis (see Godfrey Rust’s paper) • and implementations of it like our own, ONIX, etc • Digital Object infrastructure (see Larry Lannom’s paper) • and implementations of it such as Handle

4. Maximal extensibility is required doi> • DRM = Digital Management of Rights not Management of Digital Rights • DOI = Digital Identifier of “objects”(Creations, entities) • We must be able to deal with all relevant entities • because: practical rights management encompasses both digital and non-digital rights • The Web is not the end point of evolution

5. paper journal/volume/page Manuscript mss #ABC123 ISBN, ISSN, etc. doi> Not only digital things...

6. “intangible abstraction” “intangible abstraction” URL ISTC? MS Vol/page; ISBN; SICI, etc

7. Disambiguity is key doi> • Transactions require automation • Automation requires disambiguity • e.g “book” • Knowledge representation: “what is a book, work, etc?” • Practical: “What is a book in the context of…?” (namespaces, applications)  • <ISBN:book> <indecs:abstraction> <WIPO:work> • every entity should be uniquely defined within an identified namespace (indecs)

8.  There won’t be ONE model doi> • For the content communities: • indecs analysis • Practical sector implementations: • ONIX; SMPTE; MPEG21 ... • Interoperable principles Criteria... Strong underlying data model Multi-purpose Extensive, structured vocabulary Commercial critical mass Outward-looking

9. “Description” and “Rights” inseparable doi> • Any item of descriptive metadata could be used in a rights transaction • Cannot leave “rights” out of your architecture because it’s too difficult • But it does not need to be (and cannot be) complete - in fact it must be extensible • Corollary: simple resource discovery descriptions are insufficient (i.e. limited)

10. Unique identification is essential doi> • Every element of description must be precise • ISO language, territory, currency, time • Others needed: contributor codes, derivation types, forms, measures… • add: preferentially dumb identifiers • do not hard wire two data together

11. All metadata is just a view doi> E.g. an identifier for a published article may refer to... A manuscript The abstract work A draft A (class of) physical copy in a publication A (class of) digital copy (not in a publication) A (class of) digital copy in a publication A (class of) digital format A specific digital copy A (class of) paper copy A specific paper copy An edition A reprint A translation etc…and many combinations of the above • In each of role, different IDs and attributes. • True for any Creation in an application

12. Names and locations doi> • A name is a location in a defined namespace • so “all names are locations” is trivially true • Practical needs for “content” • multiple instances • persistence in the face of valid change • management of entities other than digital files • including classes, abstract rights • de-referencing, resolution • Contextualisation • e.g. “appropriate copy”; IETF • URN, URI, URL: ? • W3C URI activity should be consistent

13. Who should be responsible? doi> • Standards bodies, collectives? • EAN/UPC bar code system • ISBN system • URI scheme etc. have different methods, governance • There won’t be one place • e.g. Directory of Parties by... • e.g. ontology of “scientific article” by... • “By the people for the people” • relevant tasks should be done closest to the community of interest

14. Need for explanation doi> • Media convergence = people convergence • Formalisms are essential in their place • but must be explained • the danger of jargon and “common assumptions” • it’s not just the Web.

15. DOI Background doi> • Identifiers enable us to manage content • Physical world: • EAN/UPC Bar codes; ISBN, ISSN, ISMN, SICI, etc • good systems for publishers • Digital world: ? URL? • poor systems for publishers • how to use existing identifier systems?

16. DOI - organisation doi> • International DOI Foundation: founded 1998 • following demonstration of prototype in 1997 • Not-for-profit; paid membership support • similarities to W3C; Bar code system • Open to all interested parties • Democratic board elected from members • Full time staff • 45+ organisations (growing) • Content owners (text publishers, music, etc ) • Technology companies • Content intermediaries (etc)

17. DOI: aim doi> • Establish a way of identifying content in the digital environment • actionable identifier • Which can be the basis of rights management • extensible; can be developed further

18. NUMBERING Any form of identifier extensible doi> ACTION DESCRIPTION <indecs> framework: DOI can describe any form of intellectual property, at any level of granularity Handle resolution allows a DOI to link to any and multiple pieces of current data POLICIES

19. Conclusion: DOI doi> “DOI is the most ambitious identifier in the history of the world”.(G. Rust 1998) But now several things are becoming established... …it has a persistent, granular, flexible, unique identifier which can be a “wrapper” for other IDs. Not competitive - enhances legacy identifiers’ functionality in d-commerce. DOI as the integrating digital identifier? ...a strong, established metadata model and vocabulary. …a controlled but flexible development structure. …it does not confuse names with addresses. …allows multiple, standardised automated actions. Nothing else comes close...

20. n.paskin@doi.org http://www.doi.org Norman Paskin The International DOI Foundation doi>