250 likes | 335 Views
DEER and Digital Autonomous Cultural Objects: A Demonstrator for ECultureNet. Torsten Schaßan and Manfred Thaller University at Cologne Maastricht, 12th December 2002. The problem.
E N D
DEER and Digital Autonomous Cultural Objects: A Demonstrator for ECultureNet. Torsten Schaßan and Manfred Thaller University at Cologne Maastricht, 12th December 2002
The problem • Existing institutional framework which administers Europe's cultural heritage is widely heterogeneous and multi-centralistic • National bodies exist which enforce strategies or standards • Standards are not necessarily compatible with those enforced by other, similar bodies Torsten Schaßan - Maastricht, 2002 Dec 12
Available strategies • Enforce adherence to a full set of standards • Install a European cultural heritage broker- accepting a set of different standards • - accepting arbitrary metadata • Agree upon- response models for totally unrelated servers • - behaviour of "digital cultural heritage objects" Torsten Schaßan - Maastricht, 2002 Dec 12
DACO • Digital Autonomous Cultural Objects • usage and usability of such objects within a concrete project • detailed description for a possible strategy for the implementation of a platform for a system of interconnected resource servers Torsten Schaßan - Maastricht, 2002 Dec 12
Usage of DACOs: CEEC • Codices Electronici Ecclesiae Coloniensis • http://www.ceec.uni-koeln.de Torsten Schaßan - Maastricht, 2002 Dec 12
Manuscript access • Creation of a functionally complete linkage interface that allows one to access the content of the library completely independent of its own user interface • the following ways of addressing are guaranteed to be as persistent as the floating discussion of persistent basic identifiers allows Torsten Schaßan - Maastricht, 2002 Dec 12
Manuscript access (2) • Digital objects may be divided into a • unit of reference manuscript • finer level of granularity manuscript pages • Two types of references are necessary: • The user's: to include a reference to a digitally stored manuscript directly in a text • The institution's: access individual digital objects in different holdings directly Torsten Schaßan - Maastricht, 2002 Dec 12
Necessary schemes • It is not desirable to create new identifiers for digital objects, but • a persistent (national) addressing scheme for collections • a persistent addressing scheme for digital objects within individual collections • mapping scheme that allows referencing a granule of a digital object by a specific numbering scheme Torsten Schaßan - Maastricht, 2002 Dec 12
Implementation of schemes • An implementation of the scheme would look like this:<collection-reference><object-reference> <granule-reference> • Within CEEC it looks like this:http://www.ceec.uni-koeln.de/ceec-cgi/kleioc/0010KlCEEC/exec/katk/%22kn28-0083ii%22 Torsten Schaßan - Maastricht, 2002 Dec 12
finer level of granularity • individual pagehttp://www.ceec.uni-koeln.de/ceec-cgi/kleioc/0010KlCEEC/ exec/pagemed/%22kn28-0083ii_164.jpg%22 • <collection-reference> http://www.ceec.uni-koeln.de • <object-reference> ceec-cgi/kleioc/0010KlCEEC/ exec/pagemed/ • <granule-reference> %22kn28-0083ii_164.jpg%22 Torsten Schaßan - Maastricht, 2002 Dec 12
object-reference • <object-reference> =<interface><access-mode> <resource-id>ceec-cgi/kleioc/0010KlCEEC/exec/pagemed Torsten Schaßan - Maastricht, 2002 Dec 12
granule-reference • a string that allows a direct reference to the smallest division of digitised information within a digital object • the complete resources id should be contained within the granule-reference • distinguish between • <direct-granule-reference> • <mapped-granule-reference> Torsten Schaßan - Maastricht, 2002 Dec 12
granule-reference (2) • <direct-granule-reference> • consists of a string that can be used directly to access digitised information on a specific server • never change throughout its existence • here: kn28-0083ii_164.jpg Torsten Schaßan - Maastricht, 2002 Dec 12
granule-reference (3) • <mapped-granule-reference> • consists of a string that is separated by a dividing character • it maps to a default mechanism that will exist for the complete life span of the object and is called a "canonical reference" • may be changed over the life span of the digital object or, indeed, be dropped as obsolete • here: |kn28-0083ii_82r Torsten Schaßan - Maastricht, 2002 Dec 12
A DEER built of DACOs • We need a naming convention for the lowest level of granularity of digital media • This naming convention has to be resistant against migration faults • First step: <media-ID>_-_<digital-ID> • media-ID: non-ambiguous identification of the respective physical media unit • digital-ID: identifies an individual component of the set of digital files representing that object Torsten Schaßan - Maastricht, 2002 Dec 12
digital-ID <digital-ID> ::= <meta-ID>|<digital object-ID> • the meta-ID represents metadata describing the heritage object • the digital object-ID identifies one discrete unit of digital data representing the content of the heritage object Torsten Schaßan - Maastricht, 2002 Dec 12
meta files <meta-ID>_-_meta[.state-of-the-art-extension] • For every digital heritage object the file is obligatory • We propose to choose for this file a XML-binding of the Dublin Core Format Torsten Schaßan - Maastricht, 2002 Dec 12
meta files (2) <meta-ID>_-_meta-toc[.state-of-the-art-extension] • For every digital media the file is recommended • The author considers the notion of a slight generalisation of the Ebind DTD Torsten Schaßan - Maastricht, 2002 Dec 12
Naming digital objects <digital object-ID> ::= <base-ID>[<segment-ID>][<version-ID>][<technical supplement>] • The <base-ID> is obligatory. • It describes such a unit of the original physical object, as gives the digital object an intuitively suitable granularity • The other IDs are optional. Torsten Schaßan - Maastricht, 2002 Dec 12
media-ID <media-ID> ::= <heritage-object-ID> [-_-<copy-ID>] • The <heritage-object-Id> specifies a non-ambiguous identification for a cultural heritage object • An integrated heritage server has the right to choose from any of the digital units if to the <heritage-object-Id> requested by a user no <copy-ID> has been added "functional identity" Torsten Schaßan - Maastricht, 2002 Dec 12
Generating metadata • Metadata should be generated using existing data, the best automatically, with the smallest possible expenditure • Immediately by the end of the digitisation process of an individual object the metadata has to be available which are necessary for the integration of digitised objects in a central portal Torsten Schaßan - Maastricht, 2002 Dec 12
Structure of access • To be able to use the <media-ID>, the following structure of accessing digitised units will be supported: • every digital collection of heritage objects has to provide a base-URL • its server respond with an autonomous webpage • optical design of the dynamically generated WWW pages is up to the respective institution Torsten Schaßan - Maastricht, 2002 Dec 12
The demonstrator • The demonstrator will make available with one interface the following servers: • Medieval manuscripts (CEEC) • Medieval images (Institut für Mittelalterliche Realienkunde of the Austrian Academy of Sciences) • Early modern doctoral theses of law and printed books on legal history (Max-Planck-Institut für Rechtsgeschichte, Frankfurt) • Possibly two other servers (Predigerseminar at Wittenberg / "Personenstandsarchiv Brühl" offering archival material for genealogy) Torsten Schaßan - Maastricht, 2002 Dec 12
Addresses 1. http://www.ceec.uni-koeln.de 2. http://www.imareal.oeaw.ac.at/realonline 3. http://dlib-diss.mpier.mpg.de 4. http://dlib-pr.mpier.mpg.de 5. Predigerseminar at Wittenberg. (Not yet accessible independently.) 6. "Personenstandsarchiv Brühl" 7. http://www.archive.geschichte.mpg.de/duderstadt/dud-e.htm.) Torsten Schaßan - Maastricht, 2002 Dec 12
http://www.ceec.uni-koeln.de/ceec-cgi/kleioc/0010KlCEEC/exec/katl/%22kn28-0012%22http://www.ceec.uni-koeln.de/ceec-cgi/kleioc/0010KlCEEC/exec/katl/%22kn28-0012%22 • http://www.ceec.uni-koeln.de/ceec-cgi/kleioc/0010KlCEEC/exec/pagebig/%22|kn28-0012_16v%22 Torsten Schaßan - Maastricht, 2002 Dec 12