EMANI Application Profile (WP 3)

Transcription

1 EMANI Application Profile (WP 3) First draft, version 0.1 ( ) Prepared by: Heike Neuroth & Stefan Strathmann Goettingen State and University Library (SUB), Germany

2 TABLE OF CONTENTS 1 Introduction Metadata and preservation Standards, Interoperability OAIS METS Namespaces Workplan Format of Entry EMANI Application Profile Reference Information (first draft) Titel (and Journal, Issue, Volume) Creator/Author Contributor Publisher Location Subject EMANI Application Profile Contet Information (first draft) EMANI Application Profile Provenance Information (first draft) EMANI Application Profile Fiity Information (first draft)

3 1 Introduction Metadata are most commonly defined (structured) as data about data, describing the content, quality, conditions (like rights, access), and other characteristics of something (of data?), for eample information about the creator and/or title of a resource or object, or about the date of creation. But this definition is very fuzzy. Before metadata can be described, the meaning of "data" should be clarified. The epression "data about data" might cause some misunderstanding, because persons or books are not really data. So a definition like "data about resources or objects" might be more satisfying. This way it is possible to describe different "real" and "eisting" resources or objects (or collections of resources/objects) with a spatial or temporal limitation with metadata. But providing metadata about "non-tangible" objects like legends or myths is also imaginable. In this case it is even more difficult to talk about "data" because there is no real proof that these objects ever eisted and you never get a really unambiguous source (in metadata language this means identifier) for their eistence. The other difficult aspect is that if you talk about data about metadata (e.g. to describe a metadata collection like a subject gateway) the definit ion is also 'metadata'. This means that you use one term to describe different levels: on the one hand to describe data about data and on the other hand to describe data about metadata (data about "data about data"). So the meaning of metadata depends on the contet. Metadata are not a recent invention of new technologies: they have eisted for a very long time but without them being called metadata in the past. Just think of the hand written band catalogs or card catalogs which have provided access to printed materials for decades as well as OPACs. They all provide metadata. Also simple telephone books provide metadata, in this case about the persons listed there: their telephone numbers and sometimes also addresses and affiliations. Another question is why metadata are provided for: e.g., one main goal of Dublin Core promoting metadata in the contet of the internet is to increase resource discovery and not to support resource description. Metadata for resource description could be much richer as the agent discussion in the DC community shows. Here additional information about the creator like role (e.g. publisher, editor, etc.), , URL, etc. support the resource description but are not always very useful for resource disvovery. Of course it is imaginable that a rich set of metadata will help discover a certain resource, e.g. if you look for a special creator and you get a hit list with several creators of the same name, an URL or could be very helpful in finding the creator in question. The best solution before providing a definition of metadata might be to think about the reason (discovery, description, archiving, etc.) for creating the metadata, and what kind of things, objects, data, etc., should be described with it. This leads to the discussion of the concept of Application Profiles and Namespaces. Where several metadata elements, like title, creator, etc., are used to describe something, this set of metadata is defined in the concept of Application Profile and Namespace (see below). But for each element there should ideally be an accurate definition for semantics (content definition of an element) and synta (structural definition of an element), defined in a format of entry for the Application Profile and Namespace(s). Another approach to understanding metadata is to define metadata as a form of language (see Thomas 3

4 Baker 1 ). Therefore the Dublin Core Metadata Element Set (DCMES) can be seen as a kind of pidgin language for a digital tourist. Metadata implementors can communicate via DCMES on a minimal level, nevertheless each metadata implementor developed his own set of metadata. But by developing cross-walks (mappings) between several metadata formats (schema) different systems can echange and/or share metadata in a comfortable way. To reduce the effort that needs to be invested by developing cross-walks it makes sense to use standardized metadata schema as far as possible. Such metadata schema are e.g. already defined in namespaces like dc1.1, dcterms etc. Also the use of controlled vocabulary like keyword and thesauri systems increases the interoperability between several services rapidly. Such schema and controlled vocabulary systems are and will be saved in so called registries (e.g. Dublin Core registry 2, SCHEMAS registry 3 ). Especially by developing metadata schema for the cooperative access to distributed digital, archived objects the agreement of standardized metadata elements is very important. 2 Metadata and preservation Metadata are very important in the field of preservation resp. long-term archiving. To describe the lifecycle of digital objects several different types of metadata are important, e.g. to document the original format of the object, when this object was digitized, in which format and under which technical circumstances. Furthermore a special type of metadata informs about access/restriction policy (in general, about the Rights Management System). To ensure that some important metadata elements, e.g. administrative or technical metadata, allow automatically supported process in a repository partners have to agree on a minimal set of such metadata elements. It could be necessary in the future to allow some (semi-)automated migration processes to transform one presentation format of a digital object into another, more recent format. If distributed repositories hold several thousand or millions of digital objects the management and administration of these distributed repositories will be strongly supported by these types of metadata. In general the follwing types of metadata can be identified: - Content metadata (or descriptive metadata resp. bibliographic metadata) - Preservation metadata - Structural metadata - Administrative metadata - Technical metadata - Metadata about terms and condition (Rights Management System) - Metadata about metadata collection (e.g. RSLP metadata format 4 ) - Metadata about use of metadata (e.g. important for the definition of specific namespaces and application profiles) 1 Thomas Baker: A Grammar of Dublin Core, D-Lib Magazine October 2000, Volume 6 Number 10 (ISSN ), 2 see 3 see 4 see 4

5 - Metadata about terms and condition Within the Archival Information Package (AIP) 5 (OAIS reference model, see below) is an Information Object called the Preservation Description Information (PDI). This PDI contains additional information about the Content Information and is needed to make the Content Information meaningful for the indefinite long-term. The following metadata container can be distinguished: Reference Information: This information identifies, and if necessary describes, one or more mechanisms used to provide assigned identifiers for the Content Information. It also provides those identifiers that allow outside systems to refer, unambiguously, to this particular Content Information. Eamples of these systems include taonomic systems, reference systems and registration systems. In the OAIS Reference Model most if not all of this information is replicated in Package Descriptions, which enable Consumers to access Content Information of interest. Contet Information: This information documents the relationships of the Content Information to its environment. This includes why the Content Information was created and how it relates to other Content Information objects eisting elsewhere. Provenance Information: This information documents the history of the Content Information. This tells the origin or source of the Content Information, any changes that may have taken place since it was originated, and who has had custody of it since it was originated. This gives future users some assurance as to the likely reliability of the Content Information. Provenance can be viewed as a special type of contet information. Fiity Information: This information documents the authentication mechanisms, and it provides any authentication keys used to ensure that the particular Content Information object has not been altered in an undocumented manner. Fiity Information includes special encoding and error correction schemes that may be specific to a single Content Object or a family of Content Objects. Fiity Information does not include the integrity preserving mechanisms provided by the OAIS underlying services, error protection supplied by the media and device drivers used by Archival Storage although the Fiity Information may specify minimum quality of service requirements for these mechanisms. The CARMEN AP2/5 project at SUB Goettingen developed a set of metadata regarding provenance information and fiity information (see below). 3 Standards, Interoperability 3.1 OAIS Since its publication in 2001, the Open Archival Information System (OAIS) Reference Model 6 has received a great deal of attention in the archiving and preservation communities, and it has become the dominant and accepted model for planning and implementing digital archives. OAIS is modular, 5 See Reference Model for an Open Archival Information System (OAIS), July See (January 2002) 5

6 scalable, and fleible, making it ideal for use as a model. The OAIS Reference Model provides the basic framework for digital archives planning in the contet of the EMANI project. Key features of the model (shown in Figure 1 below) include the Submission Information Package (SIP) which provides metadata for the ingest process, the Archival Information Package (AIP), and the Dissemination Information Package (DIP), which provides tools for accessing and disseminating resources stored electronically. The implementation of the Archival Information Package will involve the design and construction of a distributed system for long-term preservation of digital content (see EMANI WP 4 and WP 11). 3.2 METS METS 7 is an XML schema designed for the purpose of creating XML document instances that epress the hierarchical structure of digital objects, the names and locations of the files that comprise those objects, and the associated metadata. METS is an open standard (non-proprietary) and is being developed by the library community (maintained by the Library of Congress). The standards is seen as relatively simple and is etensible and modular. METS can be implemented in the OAIS information package. At minimum a METS document consists of two major sections: the File Group and the Structure Map. A METS Application Profile will be developed by the METS team and will be considered in further EMANI developments, also in the contet of the workpackages WP 4 and WP 11 of EMANI. 3.3 Namespaces The following list provides (already defined) namespaces which will be considered by the 7 See 6

7 development of an EMANI Application Profile: - Dc1.1 - Dublin Core Metadata Element Set, Version 1.1: Reference Description, - Dcterms Dublin Core Qualifiers, - DC-Lib application profile (which is based on several namespaces), - MODS Metadata Object Description Schema, - MIX NISO metadata for Images in XML format, - Preservation Metadata for Digital Objects (RLG/OCLC working group), Workplan Developing and assembling the metadata element sets to yield the Content and Preservation Description Information for the current project requires bridging the gap between the metadata already maintained by the content providers involved and those metadata actually needed to manage the cooperative digital preservation system. Moving from eisting metadata to required metadata calls for two phases of work. - The first phase involves surveying the content providers for the metadata now in use and building a map among the elements used with an eye toward future interoperability. This means to agree on a minimal set of content metadata allowing cross-searching distributed archived content maintained by partners. - The second phase involves a detailed analysis of OAIS documentation to determine those preservation description elements actually needed for long-term preservation and access. Dependcies to other Workpasckages: There is a relationship to all EMANI workpackages, but especially to the following: WP 1: Import and presentation formats WP 4: Access, Navigation, Design WP 11: Architecture 5 Format of Entry We suggest the following format of entry for each metadata element defined in the EMANI Application Profile. This format of entry was developed for several projects at SUB Goettingen and was re-used for the DC Library Application Profile. 7

8 Qualified Name of Metadata Element The human readable qualified name of the metadata element. This includes refinement and encoding scheme. Synta: Name of metadata element: name of element refinement (name of element encoding scheme). If no refinement or encoding scheme eists, use "-" to indicate this. Eamples: Title: Alternative, Date: Created (W3CDTF), Title: - (-) Name of Metadata Element The human readable unqualified name of the metadata element, without refinement or encoding scheme. Rule: Use the simple name of metadata element. Specify the namespace of the element. Eample: Title Namespace: dc1.1 Refinement These qualifiers make the meaning of an element narrower or more specific. A refined element shares the meaning of the unqualified element, but with a more restricted scope. A client that does not understand a specific element refinement term should be able to ignore the qualifier and treat the metadata value as if it were an unqualified (broader) element. Rule: Use the name of the refinement of the element. Specify the namespace of the refinement. Eample: Alternative Namespace: dcterms Encoding Scheme These qualifiers identify schemes that aid in the interpretation of an element value. These schemes include controlled vocabularies and formal notations or parsing rules. A value epressed using an encoding scheme will thus be a token selected from a controlled vocabulary (e.g., a term from a classification system or set of subject headings) or a string formatted in accordance with a formal notation (e.g., " " as the standard epression of a date). If an encoding scheme is not understood by a client or agent, the value may still be useful to a human reader. Rule: Use the name of the encoding scheme of the element. Specify the namespace of the encoding scheme. 8

9 Eample: DDC Namespace: dcterms Data Echange Identifier A string consisting of two or three capital letters. This string will be used as an unique identifier of the metadata element in particular for data echange. Rule: This shall be an project internal identifier which is computer readable. In-between an metadata set you have to use the Identifier as XML-Tag to mark a metadata element. Eample: If you have an metadata set about a resource with the title "Analysis", you need a line such like: <TI>Analysis</TI> Obligation Obligation can be: mandatory (M), mandatory if applicable (MA), or optional (O). "Mandatory (M)" ensures that some of the elements are always supported and "mandatory if applicable (MA)" means that this element must be supported if the information is available. Repeatable State, if the metadata field is repeatable or not. Definition Definition of metadata element. Rule: Start first with the definition of the simple metadata element, continue with the definition of the refinement (if available) and finish with the definition of the encoding scheme (if available). Specify the namespace the definition derives from. Eample: e.g. Date: Created (W3CDTF) dc1.1: A date associated with an event in the life cycle of the resource dcterms: Date of creation of the resource dcterms: W3C Encoding rules for dates and times - a profile based on ISO 8601 Comment Some additional eplanation to the element. Type of Metadata Element Metadata elements are categorised into several types: descriptive, technical, administrative, metadata on terms and conditions, etc. Best Practice/Guidelines Recommendations of best use of this element for this metadata element, e.g. cataloging/synta rules for this element. 9

10 6 EMANI Application Profile Reference Information (first draft) The following presents summaries of metadata mappings regarding single metadata elements used by partners. A table sheet based on the format of entry will be developed for each single metadata element (see recommendations). This draft version will consider only metadata elements necessary for the document type journal. Other document types like dissertations, proceedings will be defined in a later step. 6.1 Titel (and Journal, Issue, Volume) DC-Lib THADL Euclid GDZ Springer Article (Title) Titel Title Alternative Titel Main (Proper) Sub Title Titel.Lang o Article (Structure) Start_page o End_page o Figure Count Number of tables Reference Count o Page Count Journal Journal Title Main o? Journal SubTitle o? Abreviated journal Title 10

11 Issue Issue number o Issue Title o? Issue_publ_date / Cover Date o Start_page End_page Editorial Board / Editor Volume Volume number o ProcessOfAppearance Notes: Article (Title): The character 'o' marks that the information is covered by an other metadata element (e.g. Relation, Language, Description). Recommendations: Article level: Title.Main, including language attribute Title.Alternative (translated titles etc.), including language attribute Article structure: Start_page End_page Journal level: JTitle.Main, including language attribute JTitle.Alternative (translated title, acronyms (with encoding scheme?), etc.), including language attribute Issue level: 11

12 Issue number?issue title Issue date Start page End page Editorial board (changes?) Volume level: Volume number Best Practice/Guidelines: If more than one version of a title is provided choose one title as the main one, and setting the other as "alternative. The title marked main will be displayed in search and browse results (title alternative not?), and be placed before any alternate titles on the article display page. Any form of the title used as a substitute or alternative to the formal title of the resource is called 'alternative'. This qualifier can include Title abbreviations as well as translations. A language attribute (ISO 639-1) should be recommended. For standardized journal title abbreviations please consult the abbreviation rules of ISDS based on ISO 4 (??) and ISO 833. Further questions: Development of a controlled list of journal titles, something like a journal authority file? Advantages: All kinds of transliterations can be considered as well as acronyms for titles! 6.2 Creator/Author DC-Lib THADL Euclid GDZ Springer Creator Creator.Name.Personal.Name Creator.Name.Personal.Year of Birth/Death Creator.Name.Personal.Role Creator.Name.Corporate.Name Creator.Name.Corporate.Duration 12

13 Creator.Name.Corporate.Role Creator.Name.Conference.Name Creator.Name.Conference.Session Creator.Name.Conference.Location Creator.Note CreatorsAll Author Illustrator Printer Author.Name Author. Author.Wep_page Author.Affiliation AUG.AFF.Type Notes: Creator and Author (maybe Contributor by the way of a 'Role' attribute as well) can be merged. The Dublin Core Agent Working Group is developing a concept for Creator and Contributor. This concept allows the use of only one metadata element (Contributor) with qualifiers: MARC Relators (roles such as publisher, illustrator, editor, etc.) 8. Is is recommended to follow these recommendations as far as they are approved by the DC usage board (probably March 2003). For the moment Contributor will be used in the form Author/Creator. Recommendations: DC Agent discussion: instead of Author/Creator: Contributor role=creator, role=illustrator, etc. 8 See John Kunze (1 Nov 2002, list DC Agent):... First, approval of the idea of letting the US Library of Congress "bless" and maintain the MARC Relator terms (about 185 terms) as Dublin Core Agent/CCP element qualifiers. The second UB decision was to declare that dc:creator would be a refinement of dc:contributor (dc:creator will still be usable as a top-level element). Consensus was to request the UB members present (Andy Powell, Diane Hillman) to clarify whether loc:creator or dc:creator refines dc:contributor

14 Author/Creator.Name (with well defined synta?) Author/Creator.Role (for GDZ also one MARC relator = printer) Author/Creator. Author/Creator.Affiliation (with well defined synta?) Author/Creator.Webpage Author/Creator.Note Best Practice/Guidelines: A surname is required. In case personal or family names are not used, the name should be classified as a surname. Particles (e.g. van, Von, de, al-) and suffies (e.g. Jr., III) belong to the surname. Developments of special IFLA groups and developments in the contet of AACR 2 new edition will be considered. Further questions: Is is useful/possible to develop or re-use a name authority file? 6.3 Contributor DC-Lib THADL Euclid GDZ Springer Contributor Contributors.NamePersonal.Name Contributors.NamePersonal.Year of Birth/Death Contributors.NamePersonal.Role Contributors.NameCorporate.Name Contributors.NameCorporate.duration Contributors.NameCorporate.Role Contributors.NameConference.Name Contributors.NameConference.Session Contributors.NameConference.Location Contributor. Contributor.Webpage 14

15 Contributor.Affiliation Notes: If we follow the recommendations of DC Agent Working Group we can define this element via DC.Contributor (resp. DC Contributor role=author, DC.Contributor role=illustrator, etc.). Recommendations: Contributor.Name (with well defined synta?) Contributor. Contributor.Affiliation (with well defined synta?) Contributor.Webpage Contributor.Note Best Practice/Guidelines:? Further questions:? 6.4 Publisher DC-Lib THADL Euclid GDZ Springer Publisher? Publisher.Name Publisher.Place Notes: - Recommendations: Publisher.Name (with well defined synta?) Publisher.Place (with well defined synta resp. encoding scheme?) 15

16 Best Practice/Guidelines:? Further questions:? 6.5 Location DC-Lib THADL Euclid GDZ Springer Location Notes: DC-Lib definition: Identifies the organization holding the resource or from which access is obtained. DC-Lib comment: Use for a physical location that allows the user to retrieve the item when a URI is not appropriate (e.g. for physical items not available electronically). This also facilitates access if the URI doesn't retrieve anything or only a poor substitute. When there is further identification within a location (e.g. call number, accession number), consider usin g Identifier. Recommendations:? Best Practice/Guidelines:? Futher questions: Do we need such a call number? (Namespace MODS!) 6.6 Subject DC-Lib THADL Euclid GDZ Springer Subject Subject.Controlled Subject Terms.Topic 16

17 Subject.Controlled Subject Terms.Title / Keyword(s) Subject.Controlled Subject Terms.NamePersonal Subject.Controlled Subject Terms.NameCorporate Subject.Controlled Subject Terms.NameConference Subject.Controlled Subject Terms.Geographicname Subject.UncontrolledSubjectTerms Subject.CLC Classification Subject DDC Classification Subject DC encoding scheme(s) MSC2000, MSC1991, other Subject(s), lang Subject(s) rang Keyword(s).lang Keyword(s).rank KWDG (Class/Language) Notes: We should develop a list of: - Classification systems used by EMANI partners - Keyword Systems used by EMANI Partners which informs e.g. about the following: - Name/acronym of vocabulary system - Name of underlying controlled vocabulary system resp. uncontrolled system - Version, publisher, URL etc. - Type of system (thematic, general, etc.) - Use of system (local, national, international) - Language(s) (mono-, bi-, multilingual) 17

18 - Number of levels and classes - Mappings to other controlled vocabulary system(s) -... Recommendations: Subject (uncontrolled) Subject.Controlled (with encoding scheme) Best Practice/Guidelines:? Further questions: Is it possible to agree on MSC as a common classification system? Do we need a language attribute? -- Further metadata elements will be added 7 EMANI Application Profile Contet Information (first draft) Metadata regarding contet information will be provided in this container. It could be possible that some information from the reference information container will be repeated here but probably etended with additional information. The relation between an article and issue resp. journal will be presented here as well. It is recommended that the Dublin Core metadata element relation including qualifiers will be the basis of this type of information. DC.Relation: Is Version Of Has Version Is Replaced By Replaces Is Required By Requires Is Part Of Has Part Is Referenced By References 18

19 Is Format Of Has Format 8 EMANI Application Profile Provenance Information (first draft) The following metadata set developed in the contet of the CARMEN AP 2/5 project at SUB 9 Goettingen will be suggested as a basis for further discussions: 1. Original media type 2. Original technical environment Hardware Operating systems Software Documentation 3. Ingest process history Institution name/adress Event date/time Event type Event description Technical device 4. Preservation history Institution name/adress Action date/time Action type Action description Technical device 5. Rights management Access status rights information

20 copyright statement patent statement archiving permission use conditions actors actions permitted by statute permitted by license encryption details contacts / rights holders 9 EMANI Application Profile Fiity Information (first draft) Authentication digital signature documentation of authentication mechanism 20