Digital Object Identifier Norman Paskin The International DOI

Digital Object Identifier Norman Paskin The International DOI Foundation W 3 C DRM workshop January 22/23 2001 doi>

Perspective doi> • Content meets digital infrastructure • Digital Object Identifier (DOI), from • International DOI Foundation: a member of W 3 C • Topics covered: – issues – DOI

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

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

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

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

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)

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

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

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

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

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: ? – W 3 C URI activity should be consistent

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

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.

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?

DOI - organisation doi> • International DOI Foundation: founded 1998 – following demonstration of prototype in 1997 • Not-for-profit; paid membership support • • – similarities to W 3 C; 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)

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

doi> NUMBERING extensible 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

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. . .

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