Digital Object Identifier DOI WWW 8 workshop WELCOME

Digital Object Identifier (DOI) WWW 8 workshop WELCOME 9/15/2020 1

Workshop Leaders • • Norman Paskin (IDF) John Erickson (Yankee) Godfrey Rust (Data Definitions) Andrew Stevens (Wiley) 2

Digital Object Identifier (DOI): progress and vision Norman Paskin The International DOI Foundation 3

Outline of presentation 1. 2. 3. 4. 5. 6. 7. 8. 9. Copyright management Persistent identification Resolution Scope and content typology Metadata Business model Applications Development path Issues, Q&A 4

1. Copyright management 9/15/2020 5

DOI aim: copyright management • First, uniquely and unambiguously identify what is managed (a persistent identifier) • Second, associate that with copyright management (publisher) • Simple start: resulted in a specified route to publishers web page (1 DOI 1 URL) • A start, but not the end-point 9/15/2020 6

1 DOI 1 URL is not enough • Also want to facilitate transactions and other uses independent of publisher • Transactions involve “stuff, people, deals” – not all within publishers control • Requires: Common infrastructure, shared techniques, interoperability 9/15/2020 7

Digital Object Identifier • A unique persistent identifier of a piece of content and • A system to resolve the identifier (= access that content digitally) • Consortium activity • Technology meets Content Management 9/15/2020 8

2. Persistent identification 9/15/2020 9

Persistent identification (source: IETF URN group) • global scope – means the same everywhere (does not imply a location) • uniqueness – the same Name will never be assigned to two different resources • persistence – lifetime is “permanent”; may outlast resource • scalability – can be assigned to any conceivable resource 9/15/2020 10

Persistent identification (continued) • legacy support – scheme must allow support of existing systems which fit these requirements • extensibility – any scheme for names must permit future extensions • independence – it is solely the responsibility of the name issuing authority to determine the conditions of issuing a name • sound principles which DOI endorses 9/15/2020 11

URN persistent identifiers • URI/URN not specifically web-based – telephone numbers – ISBN numbers – any namespace • DOI conforms to URN specification • URN definitions 1991 -1997 but…. • …why so few practical implementations? • “it can be done” does not mean “it will be done” 9/15/2020 12

Problems with URN (1) Availability of resolution mechanisms • Resolution discovery systems – NAPTR not widely deployed (DNS based) • Namespace registration schemes – URN: nid: nss • Browser support – must be able to type URN into browser window 9/15/2020 13

Problems with URN (2) Typology of content • Designation of names = content management • What should names be assigned to? – Formats? Versions? Citations? – What is the basis for a logical typology? – Any existing analyses? • Consistent (interoperable) framework needed 9/15/2020 14

Problems with URN (3) Single-point resolution is limited Name URL Content RESOLUTION 9/15/2020 15

Branching (multiple resolution) and nesting (DOIs to DOIs) Building blocks of a system: URL URN 9/15/2020 URN URL 16

3. Resolution 9/15/2020 17

DOI as a resolution system current implementation: 1 DOI 1 URL Handle (DOI) 10. 1004/abcde. 123456 Input 9/15/2020 DOI data URL http: //www. pub. com/. . Output 18

DOI future implementation: DOIs Resolve to Multiple Data Types DOI (Handle) 10. 1004/abcde 123456 Data type Handle data URL http: //www. pub 1. com/. URL http: //www. pub 2. com/. DLS loc/repository Extensible Data Types Identifier of content (name) 9/15/2020 XYZ 101011000 Digital services 19

DOI resolution • http proxy overcomes problem of resolution system availability – URN: DOI: 10. 1000/92 – URL: http: //dx. doi. org/10. 1000/92 • but limits to single point resolution – plug-in for native Handle available – working towards Browser support 9/15/2020 20

DOI resolution (cont. ) • currently similar to PURL but: – PURL is only single redirect, Handle is multiple – Handle is scalable – PURL is local, etc. • Registration processes – URI, URN namespaces and RDS - who, when? – ICANN ? 9/15/2020 21

4. Scope 9/15/2020 22

Scope: what a DOI identifies • • • “DOI identifies” versus “DOI resolves to” “If it takes me to it, it identifies it” NO! Example: ACS journals, current implementation Example: any multiple resolution model DOI persistently identifies “input” of resolver Names the resource not the service 9/15/2020 23

Scope: content typology (1) • A practical issue: from one dimension to many ·Information Identifiers by Norman Paskin ·Learned Publishing, 1997, Vol. 10 No. 2, pp 135 -156 ·http: //www. elsevier. nl/homepage/about/infoident ·same work, different manifestations (and rights) ·led to PII, ISWC-L • Precedents: – Music (CIS) – Library resource analysis (IFLA’s FRBR) 9/15/2020 24

Scope: content typology (2) • Analysis DOI aims: intellectual property • Creations: something in which Intellectual Property rights may exist: – Manifestations (tangible objects: atoms or bits) – Performances (spatio-temporal events) – Works (abstract creation revealed through performance or manifestation) • recall that URNs/URIs can also refer to abstract entities 9/15/2020 25

5. Metadata 9/15/2020 26

Why does metadata matter? • Background: URC discussions led to RDF etc; many metadata initiatives • If a DOI is just a 1 1 route to a publisher site, it does not matter! • But it does for wider uses: – – 9/15/2020 intelligent multiple redirection interoperable commerce what it’s called + what it is physical inspection may be inconvenient or impossible 27

So what metadata? • Sufficient to go from “what it is” to “what it’s called” – “reverse look up” (like a phone number) • some basic information about the entity… – interoperability across all sectors – future proof • Is there a logical design basis? 9/15/2020 28

Principles for Metadata (source: INDECS) • • • unique identification functional granularity designated authority application independence appropriate access • not yet as widely accepted as Naming principles 9/15/2020 29

Metadata requirements in DOI context • Unique identification: – Everything must be uniquely identified within an identified namespace (INDECS) – “a unique identifier for content” • Functional granularity: – stuff needs to be identified only when there is a need to distinguish it (INDECS) – “what the DOI identifies is up to the registrant” 9/15/2020 30

DOI kernel metadata 9/15/2020 31

Kernel, extension, genre • Concept suggested from INDECS work • DOI kernel elements are applied in some form to every DOI • For some particular content types we define a Genre which may extend the kernel for those DOIs only • extension means: addition or qualification 9/15/2020 32

DOI metadata for a Genre 9/15/2020 33

Don’t re-invent the wheel • • DOI has used existing solutions where they are appropriate: Identifier: URN Resolver: Handle Metadata: INDECS etc. 9/15/2020 34

INDECS • comprehensive framework – integrates descriptive, rights and transaction metadata, provides guiding principles • complete content typology • ability to express metadata at different levels – label, class, relationship, event – other approaches consistent (e. g. DC data model? ) 9/15/2020 35

INDECS • = Interoperability of Data in E-Commerce Systems • Nov 1998 - Jan 2000 • London July 1999, Washington Nov 1999 (November with US Copyright office) • www. indecs. org (April 1999) 9/15/2020 36

INDECS aims to bring commonality to “acronym hell” • Technical: XML, RDF, URN, ISO 11179 • Audiovisual: MPEG 7, UMID, ISAN • Commerce based: DOI, ISWC, ISRC, EPICS, INDECS • Library/academic based: IMS, LOM, FRBR • Web discovery: DC, GILS • All of the above still in development 9/15/2020 37

DOI and INDECS together • • • Tool not tyranny A framework for thinking Data model gives interoperable framework Very practical aims Large buy-in from wide community 9/15/2020 38

6. Business model 9/15/2020 39

DOI Business model DOI adds value but incurs costs: • Registration – Prefix issuance, validation, maintenance, guidance, metadata declaration • Infrastructure – Resolution service, scaling, development • Governance 9/15/2020 40

DOI Business model (2) Aim is for cost recovery • Funded by registrants • Registration outsourced – Economies of scale, market competition • Infrastructure outsourced • Governance remains with IDF – funded by operators or separately? 9/15/2020 41

DOI Business model (3) • Currently funded by “governance” model • Comparable models exist: – ISBN – EAN/UPC • Web environment? – Registration of names, namespaces, resolution services. Commercialisation? ? • Alternatives: telephone model? ? 9/15/2020 42

7. Applications 9/15/2020 43

Applications • Future developments offer attractive options but we need something now • Killer applications made ISBN, EAN/UPC – URN has no killer applications – can DOI provide some? • Persistent linking – persistent name 9/15/2020 44

8. Development path 9/15/2020 45

DOI development path Current implementation 1 URL = 1 DOI Metadata Further development Multiple resolution Services definition Standards tracking INDECS/ISO/ IETF/W 3 C &c Standard services Workflow tools Full DOI services implementation Library service tools

Targets 1999 • Key issues – Scope – Metadata – Services – Local resolution – Standards – Registration schemes – User guidelines and policies • Implementations • Future financial and operational basis • Increase involvement 9/15/2020 47

9. Issues 9/15/2020 48

Issues • • Supporting the process Obtaining wider support Not stopping at the current point Web infrastructure – Handle and other issues • Business model implementation 9/15/2020 49

Further information • www. doi. org • www. handle. net • www. indecs. org • n. paskin@doi. org • Article at www. dlib. org (May issue)