handle - technical update

Corporation For NationalResearch Initiatives

Handle - Technical Update

Larry Lannom

CNRI

Sept 20, 2002


Technical Developments: 2001/02 Maturation

Increase in numbers - 5M+ DOIs– New backend db– New admin facilities

Increased scope of application areas– Learning objects– Images

Increased scope of research interest– Identity management– Grid - handles for events– Laws & Regs (DTIC/TSO)– Network storage


Technical Developments: 2001/02 Maturation

Admin Tools– GUI installer, server splitter– SQL backend– Servlets for web based admin– Administration Manual

Development Tools– Python library (not yet licensed)– New hdllib example programs (net.handle.apps.simple)

Responding to dot com jitters– Exodus bankruptcy - added additional GHS, DOI LHS and proxy at CNRI

Support for encrypted communication between clients and servers Support for Java 1.4 Lots more….


Other Efforts

OpenURL– ‘Fat URL’ coming out of Library community

– Used to solve the Appropriate Copy problem

– Being proposed as a general interface to DOI world

Interparty– Interop across rights clearinghouses, library authority files, etc

Internet Digital Rights Management (IDRM) Group


Technical Developments: DOI Evolving Functionality

Parameter passing– Carrying information in the http://dx.doi.org URL– Crossref prototype– OpenURL

Debate on data models and service architecture– Great potential flexibility

Given an ID, what can you get How do you understand what you get

– Moving targets Web services, semantic web, Grid computing XML DTD, XML Schema, RELAX NG

Adobe focus– Move forward with prototype, get RA buy-in

http://dx.doi.org/


DOI as Enabling Framework for Managing Content Simple Goal: Build a framework for coherent management of content in an

evolving digital realm– Make sure your intended audience can find it– Associate related information and services both now and later– Maintain integrity of original content

Complicated World: Years and even centuries of practice disrupted by technology– Content no longer physically fixed, but in motion and highly mutable– Digital entities have value, in the creation, but can be duplicated and disseminated at no

cost– Digital convergence pushing content out of its familiar boundaries– Technology is accelerating

Persistent, manageable, and actionable identifier is a foundation of the needed framework

– Basic mechanisms in place: id assignment, management, resolution plus associated metadata creation framework

– Need common data models and architectures for extended use of what we have


Acrobat Plug-in Project as Focus

Use DOI embedded in PDF to extend functionality– Show DOI as useful for item in hand as well as for links

– Provide user with new functions/services as they evolve

Handle plug-in made aware of special DOI facilities Resolve handle/DOI upon rendering New functions/services driven by resolution result User interface through customization of tool bar, menu

items, dialog boxes

.

Demo 1 – Version

Tool Bar

Demo 1 – Version

XMP

Tool Bar

Demo 1 – Version

cnri.test.jsn/pdf

TYPE DATA

http://host-4-211/book-newversion.pdfurl

last_modified 2002-06-13T14:06:03-03:00

DOI

Handle Record

2002-06-13T14:06:03-03:00

http://host-4-211/book-newversion.pdf

Internet

Handle System

Tool Bar

Demo 1 – Version

Demo 2 – MultiRes

Demo 2 – MultiRes

XMP

Demo 2 – MultiRes

url http:/www.penguinbooks.com/0-465-03032-7

doi.multires <?xml version=“1.0”?><!DOCTYPE multires SYSTEM “multires.dtd”><multires> <node label=“Publisher’s Catalog Page” href=“http://www.mcgrawhill.com”/><node label=“Read a Free Excerpt” href=“http://www.mcgrawhill.com/excerpt”/><node label=“Buy This Book”> <node label=“Microsoft Reader”> <node label=“Amazon.com” href=http://www.amazon.com/isbn=120319”/> <node label=“Barnes & Noble href=http://www.amazon.com/isbn=120319/> <nod label=“Contentville” href=http://www.contentville.com/>

doi.kmd <?xml version=“1.0”?><!DOCTYPE Kernel SYSTEM “doikernel-1.0.dtd”><Kernel xmlns:doi=http://www.doi.org/namespace/> <Identifier>cnri.rest.jsn/multires</Identifier> <Assertor> <Registrant id=“publishers:123321”>Penguin Books</Registrant><Date>October 16, 2001</Date></Assertor><Entity> <Type>intangible manifestation</Type><Mode>visual</Mode><Title> <Language>en</Language><TitleValue>A Tale of Two DOIs</TitleValue><Agent id=“authors:223453”> <Person>Charles Dickens</Person> <Role>Author</Role></Agent></Entity></Kernel>

cnri.test.jsn/multires

Internet

http://www.mcgrawhill.com/






http://www.a/

http://www.amazon.com/isbn=120319





http://www.contentville.com/



Demo 2 – MultiRes

XMP

Demo 2 – MultiRes





Internet







Demo 2 – MultiRes

Demo 2 – MultiRes





Internet

Demo 2 – MultiRes

Demo 3 – CrossRef

Tool Bar

Demo 3 – CrossRef

XMP

Tool Bar

Demo 2 – CrossRef

Handle System

cnri.test.jsn/crossref

TYPE DATA

doi.xref

DOI

Handle Record

Internet

Tool Bar

Demo 3 – CrossRef

XMP

Tool Bar

Demo 3 – CrossRef

Demo 4 – Rights

Tool Bar

Demo 4 – Rights

XMP

Demo 4 – Rights

Handle System

cnri.test.jsn/doi.rights

TYPE DATA

http://kaluha/~jpetrone/doi_rights.htmldoi.rights

DOI

Handle Record

Internet

Tool Bar

Demo 4 – Rights

XMP

Tool Bar

Demo 4 – Rights


What Have We Done

Put the DOI data in functional units in the handle record and the knowledge of what to do with them in the client

Demonstrated with an end-user client (Acrobat) but equally applicable to middleware

No constraints on adding additional functional units to a given DOI– Added flexibility and simplicity

– Reduced ability to verify integrity across functional units No attempts at on-the-fly bootstrapping for introducing new

functionality to existing clients– Will require an updating process for clients


A Namespace for DOI Functions

0.TYPE/doi.multires INDEX TYPE *DESCRIPTION*

view_doi-uri_template http://host-4-211/doi/multires_proxy.py?doi=%DOI

mime

mime

text/plain | <description of multires>

text/xml | <XML Schema for multires data format >

1

2

3

0.TYPE/doi.kmd

url

mime

mime

INDEX TYPE *DESCRIPTION*

http://dx.doi.org/10.1000/182

text/plain | <Description of DOI kernel metadata>

text/xml | <XML Schema for kernel metadata>

1

2

3


A Note on XMP

XMP access hooks in Acrobat but not Reader

– Considered too much bloat for Reader

– Presumably could change over time

Two choices

– Put the DOI someplace else -- PDF metadata

– Create our own hooks

We’ve tried both

– Demos based on Acrobat

– Also developed a version that reads non-XMP metadata


What Next

Bring together the RA tech reps to roll out significant prototype– Need experience with additional data, real users

– Decision on XMP

– Go beyond PDF

Package it up and roll it out– License

– Management of new functions: some sort of vetting process

handle - technical update

Documents