Annotation of worldwide-digilib/worldwide-digilib.tex, revision 1.1
1.1 ! casties 1: \documentclass[a4paper]{article}
! 2:
! 3: \usepackage[latin1]{inputenc}
! 4: \usepackage[T1]{fontenc}
! 5: \usepackage{ae}
! 6:
! 7: \usepackage{url}
! 8: %\usepackage{hyperref}
! 9:
! 10: %% for latex2rtf :-(
! 11: % remember to replace "%" in URL!
! 12: %\newcommand{\url}[1]{\verb!#1!}
! 13: %\renewenvironment{footnotesize}{}{}
! 14:
! 15:
! 16: \newcommand{\digilib}{\texttt{digilib}}
! 17:
! 18: \title{Draft: World Wide digilib -- Resource Identifier in ECHO}
! 19:
! 20: \author{Robert Casties\thanks{IT-Group, Max Planck Institute for the
! 21: history of science}}
! 22:
! 23: \date{Version~0.6 of \today}
! 24:
! 25: \begin{document}
! 26:
! 27: \maketitle
! 28:
! 29: \tableofcontents
! 30:
! 31: \section{Digital Resource Identifier DRI}
! 32:
! 33: The \emph{Digital Resource Identifier} is a worldwide unique
! 34: identifier for a digital resource. The resource may be an electronic
! 35: text, single or multiple digital images, an audiovisual media file or
! 36: other type of electronic resource that is accessible over the
! 37: Internet.
! 38:
! 39: The identifier provides a stable point of reference for digital
! 40: resources in the Internet. The identifier is therefore independent
! 41: from the address, implementation and directory layout of the location
! 42: of the resource. The identifier is unique and constant and it can be
! 43: used in other documents to reference the resource without the risk of
! 44: having a broken reference in the future because the address or filename
! 45: of the resource has changed.
! 46:
! 47: The identifier supports infrastructure for the ``sustainability'' of
! 48: digital resources to guarantee that not only the identifier always
! 49: points to the same resource but also the resource stays available in
! 50: the Internet. The infrastructure supports backup copies and load
! 51: balancing mechanisms. The implementation and enduring support of the
! 52: actual servers and digital resources is in itself mostly an
! 53: organisational and social challenge that cannot be solved by
! 54: technological measures alone.
! 55:
! 56:
! 57:
! 58: \subsection{Structure of the DRI}
! 59: \label{sec:structure-dri}
! 60:
! 61: The \emph{Digital Resource Identifier} has the following properties:
! 62:
! 63: \begin{itemize}
! 64: \item Total address space of 70 bit, partitioned into a million
! 65: subspaces of 50 bit for $10^{15}$ or 1125 billion different
! 66: resources per subspace.
! 67:
! 68: \item The identifier contains only (uppercase) letters and digits.
! 69:
! 70: \item The identifier is composed of a 4 character \emph{subspace} or
! 71: \emph{namespace identifier}, a 10 character \emph{resource
! 72: identifier} and a 1 character checksum, giving a total of 15
! 73: characters for the full DRI.
! 74: \end{itemize}
! 75:
! 76:
! 77:
! 78:
! 79: \subsection{Character set}
! 80: \label{sec:charset}
! 81:
! 82: The identifier is composed only of letters and digits. Uppercase and
! 83: lowercase letters are not distinguished. The resulting character set
! 84: has $26+10=36$ characters. Four characters with ambiguous shapes that
! 85: might lead to errors are omitted: ``O'' (vs. ``0''), ``I'' (vs. ``1''
! 86: or ``l''), ``L'' (vs. ``1'' or ``I''), and ``J'' (vs ``1'' or ``I'').
! 87: The resulting set of 32 characters can be used to represent 5 bit of
! 88: information.
! 89:
! 90: \begin{table}[htbp]
! 91: \centering
! 92: \begin{footnotesize}
! 93: \begin{tabular}{cc|cc|cc|cc}
! 94: character & value & character & value & character & value &
! 95: character & value \\ \hline
! 96: 0 & 0 & A & 10 & N & 20 & Y & 30 \\
! 97: 1 & 1 & B & 11 & P & 21 & Z & 31 \\
! 98: 2 & 2 & C & 12 & Q & 22 \\
! 99: 3 & 3 & D & 13 & R & 23 \\
! 100: 4 & 4 & E & 14 & S & 24 \\
! 101: 5 & 5 & F & 15 & T & 25 \\
! 102: 6 & 6 & G & 16 & U & 26 \\
! 103: 7 & 7 & H & 17 & V & 27 \\
! 104: 8 & 8 & K & 18 & W & 28 \\
! 105: 9 & 9 & M & 19 & X & 29 \\
! 106: \end{tabular}
! 107: \end{footnotesize}
! 108: \caption{Character set for identifier}
! 109: \label{tab:chartable}
! 110: \end{table}
! 111:
! 112: The 50 bit of the chosen address for the resource is divided into ten
! 113: pieces of 5 bit. The pieces are each encoded into one character
! 114: according to the character table in table~\ref{tab:chartable}. The
! 115: resulting string of 10 characters is called the \emph{resource
! 116: address}.
! 117:
! 118:
! 119:
! 120:
! 121: \subsection{Namespaces}
! 122: \label{sec:namespaces}
! 123:
! 124: The total address space of 70 bit is divided into $2^{20}$ (1048576)
! 125: subspaces of 50 bit. These subspaces, also called namespaces, can be
! 126: assigned to institutions that wish to implement their own allocation
! 127: of resource identifiers for reasons of efficiency and maintenance. All
! 128: resulting resource identifiers are only valid once they are registered
! 129: with the central \emph{resource registry}.
! 130:
! 131: Each subspace is identified by a four-character \emph{name
! 132: space identifier}. The 10 character \emph{resource address} is
! 133: prefixed with the \emph{name space identifier}, resulting in a 14
! 134: character \emph{unique address} for each resource.
! 135:
! 136: Subspaces and their name space identifier are registered by the
! 137: central resource registry. An institution or project that wishes to
! 138: implement its own allocation of resource identifiers contacts the
! 139: resource registry and receives a name space identifier for a currently
! 140: unused subspace. The subspace is then marked as being used by this
! 141: institution or project. New resource identifiers in this subspace can
! 142: only be assigned by the institution or project that owns the subspace.
! 143:
! 144: The central resource registry allocates and registers resource
! 145: identifiers for institutions, projects and individuals that do not
! 146: want to maintain their own subspace. Resource identifiers allocated by
! 147: the central resource registry are in the \texttt{ECHO} namespace.
! 148:
! 149: The namespaces \texttt{0000}, \texttt{TEMP} and \texttt{ECHO} are
! 150: reserved for use with the central resource registry.
! 151:
! 152:
! 153: \subsection{Checksum}
! 154: \label{sec:checksum}
! 155:
! 156: A checksum of one character (5 bit) is calculated over the 14
! 157: characters (70 bit) of the \emph{unique address}. The checksumming method is
! 158: similar to the method used for ISBN (International Standard Book
! 159: Number). The differences are the number system, which is base-32 for
! 160: the DRI (ISBN: base-10) and the modulus, which is 31 for the DRI
! 161: (ISBN: 11).
! 162:
! 163: The checksum number is calculated with the formula
! 164: \begin{displaymath}
! 165: c = \sum_{i=1..14} i x_i \pmod{31}
! 166: \end{displaymath}
! 167:
! 168: The resulting checksum number $c$ is converted to a character
! 169: according to table~\ref{tab:chartable} and appended to the end of the
! 170: \emph{unique address} giving the full \emph{Digital Resource
! 171: Identifier}.
! 172:
! 173: The DRI is only valid if the checksum calculated over the unique
! 174: address part of the identifier (the first 14 characters) matches the
! 175: checksum value (the last character).
! 176:
! 177:
! 178:
! 179:
! 180: \section{Central resource registry}
! 181: \label{sec:central-registry}
! 182:
! 183: The central resource registry is the keystone in the concept of stable
! 184: and sustainable digital resource identifiers and references. Resources
! 185: can be moved and renamed on local servers, duplicated onto other
! 186: servers and servers can even be shut down (given the resource had been
! 187: duplicated) without resources getting lost or breaking links or
! 188: references to the resource.
! 189:
! 190: The resource registry server acts as a switchboard between the user
! 191: requests for a resource and local servers providing the resource. URLs
! 192: and other so called ``global'' references to a resource via its DRI
! 193: access the resource registry server that dispatches the request to the
! 194: local server. In this way only the resource registry server's address
! 195: has to remain stable.
! 196:
! 197: This places a high burden of availability on the registry server. This
! 198: challenge can be met on a technical level with standard technology
! 199: (transparent replication and load balancing) and scaled to higher
! 200: performance levels when the demand rises. More importantly a durable
! 201: solution has to be established on the organizational and social level
! 202: for running the server.
! 203:
! 204: The resource registry maintains the mapping database between the
! 205: digital resource identifiers and the location of the resources on the
! 206: local servers. In this way it has a list of all known resource
! 207: identifiers and ensures that all resource identifiers are unique.
! 208:
! 209: The database on the resource registry server can additionally store a
! 210: set of minimal meta informations on the resources and provide
! 211: searches in this metadata. One item of this minimal meta information
! 212: should be a URL to further information on the resource.
! 213:
! 214: The resource registry server provides a HTTP redirect function for
! 215: transparent HTTP access to resources and optionally other webservice
! 216: access (XML-RPC, SOAP).
! 217:
! 218: Special client software for accessing resources can harvest and cache
! 219: DRI mappings from the central registry for short times to improve
! 220: performance or offline work.
! 221:
! 222: As mentioned in chapter~\ref{sec:namespaces} parts of the resource
! 223: identifier address space can be assigned to institutions or projects
! 224: to implement their own allocation of resource identifiers. These
! 225: identifiers are generally valid only after they have been registered
! 226: with the central resource registry.
! 227:
! 228: The central resource registry remains the only authoritative source of
! 229: digital resource identifiers and their mapping to local resources.
! 230:
! 231: The resource registry provides interfaces to
! 232:
! 233: \begin{itemize}
! 234: \item redirect HTTP requests with resource identifiers to local
! 235: resource servers
! 236:
! 237: \item query the mapping of resource identifiers using a webservice
! 238: interface
! 239:
! 240: \item hand out new resource identifiers and acquire the necessary
! 241: mapping information
! 242:
! 243: \item change resource mapping information or resource meta information
! 244:
! 245: \item query the database for meta information
! 246:
! 247: \item upload sets of externally allocated resource identifiers
! 248:
! 249: \item download sets of identifiers or the whole database for caching
! 250: purposes.
! 251: \end{itemize}
! 252:
! 253:
! 254:
! 255: \subsection{Handling of digital resource identifiers in HTTP
! 256: requests}
! 257: \label{sec:dri-resolution-http}
! 258:
! 259: A global HTTP request usually accesses a digital resource via some
! 260: kind of display tool (for example \digilib{}) that is able to render a
! 261: web representation of the resource. While the resource identifier is
! 262: embedded in the DRI part of the URL, other aspects of the rendering
! 263: (for example which tool to use) are embedded in other parts of the URL
! 264: that may be specific to the display tool. Therefore the registry
! 265: server has to treat URLs differently depending on the display tool.
! 266:
! 267: The handling of HTTP requests has three steps:
! 268: \begin{enumerate}
! 269: \item Identification of the DRI in the request string.
! 270:
! 271: \item Lookup of additional information on the handling of the request
! 272: based on the DRI.
! 273:
! 274: \item Redirect of the client to the local resource server.
! 275: \end{enumerate}
! 276:
! 277: The first part of the treatment of the URL is the identification of
! 278: the DRI in the HTTP request string. Three basic ways of handling the
! 279: DRI are envisaged:
! 280:
! 281: \begin{itemize}
! 282: \item The DRI can be embedded as part of the URI path\footnote{The
! 283: first part of the URI path, separated by slashes, that is a valid
! 284: DRI string.} (\url{http://driserver.echo.eu/dri/ECHO00001A2B3CX}),
! 285:
! 286: \item it can be provided as a special HTTP GET or POST parameter for a
! 287: defined environment like \digilib{}\footnote{The environment itself
! 288: should be identified by the first parts of the URI path.}
! 289: (\url{http://driserver.echo.eu/digilib/digilib.jsp?dri=ECHO00001A2B3CX&pn=5})
! 290: or
! 291:
! 292: \item it can be extracted from the request by a generic pattern
! 293: matching scheme (this option is computationally most expensive)
! 294: \end{itemize}
! 295:
! 296: Once the DRI is identified more information about the resource can be
! 297: looked up in the central resource database. From this point on the
! 298: redirection of the request can be handled differently depending on the
! 299: record type information in the database.
! 300:
! 301: An extensible set of URL rewrite rules will be implemented by the
! 302: server. The type of rule to be used is part of the resource record of
! 303: the DRI in the central resource registry. The following rules should
! 304: be part of the first implementation of the registry server:
! 305:
! 306: \begin{description}
! 307:
! 308: \item[redirect] only the host part of the URL is replaced by the local
! 309: host name from the resource record.
! 310:
! 311: \item[replace] the full URL is replaced by the local URL from the
! 312: resource record.
! 313:
! 314: \item[\digilib{}] the host part of the URL is replaced by the local host
! 315: name from the resource record and the remaining part is replaced according
! 316: to \digilib{} rules.
! 317:
! 318: \item[rewrite] the host part of the URL is replaced by the local host
! 319: name from the resource record and the remaining part is replaced according to
! 320: generic substitution rules with wildcard patterns.
! 321: \end{description}
! 322:
! 323: The introduction of other specialized types of rewrite rules can be
! 324: implemented as extension modules to the resource server.
! 325:
! 326:
! 327:
! 328: \subsubsection{Redirect and replace type DRI resolution}
! 329: \label{sec:redirect-type-dri}
! 330:
! 331: When a DRI resource record has a resolution type of ``redirect'', then
! 332: only the host part of the URL is replaced in the redirected request by
! 333: the local host given in the resource record. See
! 334: table~\ref{tab:redirect-resolv}.
! 335:
! 336: \begin{table}[htbp]
! 337: \centering
! 338: \begin{tabular}{lp{0.7\textwidth}}
! 339: incoming request & \url{http://driserver.echo.eu/dri/ECHO00001A2B3CX} \\
! 340: \texttt{local\_host} record & \texttt{penelope.unibe.ch} \\
! 341: redirect request & \url{http://penelope.unibe.ch/dri/ECHO00001A2B3CX}
! 342: \end{tabular}
! 343: \caption{redirect type DRI resolution}
! 344: \label{tab:redirect-resolv}
! 345: \end{table}
! 346:
! 347: When a DRI resource record has a resolution type of ``replace'', then
! 348: the whole URL is replaced in the redirected request by the local URL
! 349: given in the resource record. See table~\ref{tab:replace-resolv}.
! 350:
! 351: \begin{table}[htbp]
! 352: \centering
! 353: \begin{tabular}{lp{0.7\textwidth}}
! 354: incoming request & \url{http://driserver.echo.eu/dri/ECHO00001A2B3CX} \\
! 355: \texttt{local\_url} record & \url{http://penelope.unibe.ch/docuserver/compago/compare.pl?32} \\
! 356: redirect request & \url{http://penelope.unibe.ch/docuserver/compago/compare.pl?32}
! 357: \end{tabular}
! 358: \caption{replace type DRI resolution}
! 359: \label{tab:replace-resolv}
! 360: \end{table}
! 361:
! 362:
! 363:
! 364: \subsubsection{\digilib{} type DRI resolution}
! 365: \label{sec:digilib-type-dri}
! 366:
! 367: When a DRI resource record has a resolution type of ``\digilib{}'', then
! 368: the host part of the URL is replaced by the local host in the resource
! 369: record and the remaining part is replaced according to \digilib{}
! 370: parameter format.
! 371:
! 372: In the preferred parameter-style format the DRI is given as the
! 373: parameter ``dri''. The local URL for the redirect is constructed by
! 374: replacing the URI path up to the ``?'' with the digilib path from the
! 375: resource record and adding a local filename as parameter ``fn''. See
! 376: table~\ref{tab:digilib-resolv}.
! 377:
! 378: \begin{table}[htbp]
! 379: \centering
! 380: \begin{tabular}{lp{0.7\textwidth}}
! 381: incoming request &
! 382: \url{http://driserver.echo.eu/digilib/digilib.jsp?dri=ECHO00001A2B3CX&pn=5} \\
! 383: \texttt{local\_host} record & \texttt{penelope.unibe.ch} \\
! 384: \texttt{digilib\_path} record & \texttt{/docuserver/digitallibrary/digilib.jsp} \\
! 385: \texttt{digilib\_file} record & \texttt{public/Beispiele} \\
! 386: redirect request &
! 387: \url{http://penelope.unibe.ch/docuserver/digitallibrary/digilib.jsp?dri=ECHO00001A2B3CX&fn=public/Beispiele&pn=5}
! 388: \end{tabular}
! 389: \caption{digilib type DRI resolution}
! 390: \label{tab:digilib-resolv}
! 391: \end{table}
! 392:
! 393: In the deprecated plus-style format the DRI could be placed the first
! 394: part of the parameter path, prefixed with ``dri:''. In the local URL
! 395: the local pathname is appended to the DRI part.
! 396:
! 397:
! 398: \subsubsection{Rewrite type DRI resolution}
! 399: \label{sec:rewrite-type-dri}
! 400:
! 401: When a DRI resource record has a resolution type of ``rewrite'', then
! 402: the host part of the URL is replaced by the local host name from the
! 403: resource record and the remaining part is replaced according to
! 404: generic substitution rules with wildcard patterns.
! 405:
! 406:
! 407:
! 408: \subsection{Handling of digital resource identifiers as a web service}
! 409: \label{sec:handl-dri-web}
! 410:
! 411: The basic function of resolution of a DRI as well as other maintenance
! 412: functions like the registration of new DRIs or the download of parts
! 413: or all registered DRI mappings should also be accessible with a web
! 414: service interface.
! 415:
! 416: Specifications for the web service interface have to be established.
! 417:
! 418:
! 419: \section{Resource metadata}
! 420: \label{sec:resource-metadata}
! 421:
! 422: The set of metadata about a resource that is stored on the resource
! 423: server is called a \emph{resource record}. Since the requirements of
! 424: access, structure and amount of metadata for different projects can
! 425: hardly be generalized the resource server stores only a minimal set of
! 426: fields that is sufficient for the basic functions of access to the
! 427: resource, sustainability of access, and interoperability. More
! 428: extensive and project specific metadata sets should be stored and
! 429: maintained on external servers. The optional resource information
! 430: field can be used to point to external metadata representations.
! 431:
! 432:
! 433: \subsection{Basic metadata}
! 434: \label{sec:basic-metadata}
! 435:
! 436: The amount of metadata is dependent on the type of resource record.
! 437: Common to all records is the \texttt{dri} field for the resource
! 438: identifier. Redirect-type records require an additional
! 439: \texttt{local\_host} field for the host name of the local host.
! 440: Replace-type records require an \texttt{local\_url} field for a full
! 441: URL. Digilib-type records require at least the three fields
! 442: \texttt{local\_host}, \texttt{digilib\_path}, and
! 443: \texttt{digilib\_file} and an optional parameter
! 444: \texttt{digilib\_pageno}. The basic fields can be found in
! 445: table~\ref{tab:basic-meta}.
! 446:
! 447: \begin{table}[htbp]
! 448: \centering
! 449: \begin{tabular}{lr|l}
! 450: type & field & description \\ \hline
! 451: \textbf{redirect} & & \\
! 452: & \texttt{record\_type} & type of record (``redirect'') \\
! 453: & \texttt{dri} & DRI \\
! 454: & \texttt{local\_host} & local host name \\ \hline
! 455: \textbf{replace} & & \\
! 456: & \texttt{record\_type} & type of record (``replace'') \\
! 457: & \texttt{dri} & DRI \\
! 458: & \texttt{local\_url} & full local URL \\ \hline
! 459: \textbf{digilib} & & \\
! 460: & \texttt{record\_type} & type of record (``digilib'') \\
! 461: & \texttt{dri} & DRI \\
! 462: & \texttt{local\_host} & local digilib server \\
! 463: & \texttt{digilib\_path} & URI path of the digilib installation \\
! 464: & \texttt{digilib\_file} & digilib path name (parameter fn) \\
! 465: & \texttt{digilib\_pageno} & optional page number
! 466: (parameter pn)
! 467: \end{tabular}
! 468: \caption{Basic metadata fields}
! 469: \label{tab:basic-meta}
! 470: \end{table}
! 471:
! 472: The resource server may implement additional fields like owner and
! 473: group fields for internal management and user access functions.
! 474:
! 475:
! 476: \subsection{Alternate server and backup server}
! 477: \label{sec:redund-serv-back}
! 478:
! 479: The resource server architecture is designed to fulfill high demands
! 480: on the performance and sustainability of access to the
! 481: resources. These demands can be met by a loosely coupled network of
! 482: local servers duplicating content for backup and the transparent
! 483: sharing of concurrent access to resources for enhanced
! 484: performance.
! 485:
! 486: Backup server fields give the names and paths of servers that provide
! 487: copies of the resource. Requests for the resource are diverted to a
! 488: backup server when the original server becomes unavailable.
! 489:
! 490: Alternate server fields give the names paths of servers that provide
! 491: copies of the resource. Requests for a resource are spread among all
! 492: alternate servers for the same resource according to a load-balancing
! 493: pattern. The pattern can be a simple round-robin scheme or a more
! 494: sophisticated scheme based on server performance or the geographical
! 495: location of client and server.
! 496:
! 497: A resource record can have any number of backup server and alternate
! 498: server fields. If a resource is required to have at least one backup
! 499: server is a policy decision of the hosting project that is not
! 500: enforced by the resource server.
! 501:
! 502:
! 503:
! 504: \subsection{Additional resource information}
! 505: \label{sec:addt-reso-inform}
! 506:
! 507: The resource server itself carries only minimal metadata on a resource
! 508: but it provides a basic mechanism to store and access more extensive
! 509: information on external servers.
! 510:
! 511: Every resource record can have a resource info URL that is stored in
! 512: the \texttt{info-url} field.
! 513:
! 514: \begin{table}[htbp]
! 515: \centering
! 516: \begin{tabular}{l|l}
! 517: field & description \\ \hline
! 518: \texttt{info-url} & URL to external information
! 519: \end{tabular}
! 520: \caption{External resource information}
! 521: \label{tab:extern-reso-inform}
! 522: \end{table}
! 523:
! 524: The external resource information can be accessed in a standardized
! 525: way on the resource server where the DRI of the resource is part of
! 526: the URI path: \url{http://driserver.echo.eu/resinfo/ECHO00001A2B3CX/}
! 527: Requests to this URL will be redirected to the URL in the
! 528: \texttt{info-url} field in the resource record.
! 529:
! 530:
! 531: \end{document}
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>
![[BACK]](/cvs/cvsweb/icons/back.gif){kind=icon}
Return to worldwide-digilib.tex CVS log ![[TXT]](/cvs/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvs/cvsweb/icons/dir.gif){kind=icon}
Up to [Repository] / worldwide-digilib