1 About this document

1.1 Scope

The LIDO Primer is a user guide for those who wish to represent information describing objects or works of material culture and natural heritage with LIDO. Described objects may be human-made art works or utilitarian objects, as well as natural specimens or archeological remains. It is intended for anyone concerned with producing, maintaining, transforming, or publishing metadata for cultural heritage collections, not only limited to museums, but also including, for example, libraries and archives. The Primer complements the more technical documents listed below by giving background information and introductory examples for applying the LIDO schema in practice.

Throughout this Primer, the painting Mona Lisa by Leonardo da Vinci serves as an example of an object description in LIDO Version 1.1. XML snippets are provided to show the usage of LIDO elements, attributes, and recommended terminology. Besides, the Mona Lisa also features in the Europeana Data Model Primer (EDM Primer) to illustrate the main features of the model. The example in LIDO intends to demonstrate similarities between its XML-based model and the RDF graph resulting from application of the EDM.

1.2 Associated documents

• The LIDO XML Schema Definition is the authoritative reference for all LIDO elements and attributes. The latest version can be found here: http://lido-schema.org/schema/latest/lido.xsd
• The LIDO Documentation provides a concise description of all LIDO elements and attributes as well as detailed structural and technical information. It is recommended to consult the documentation for a systematic description of all LIDO elements and attributes. The latest version can be found here: http://lido-schema.org/schema/latest/lido.html
• The LIDO Terminology Recommendation provides references to recommended terms from the LIDO Terminology or other linked open vocabularies for a number of LIDO elements and attributes. The latest version can be found here: http://lido-schema.org/documents/terminology-recommendation.html
• The LIDO Terminology is publicly accessible via http://terminology.lido-schema.org. A short introduction and a documentation of the LIDO Terminology LOD interface is given here: https://cidoc.mini.icom.museum/working-groups/lido/lido-overview/lido-terminology/
• LIDO Examples can be found here: LIDO Examples
• The LIDO website provides further information about LIDO and other resources: https://lido-schema.org

2 About LIDO

2.1 What is LIDO?

LIDO is a metadata schema, formally defined in the XML schema language. It enables a representation of data about a variety of objects of material culture, originating in heterogenous cataloging or collection management systems. The multitude of objects cover a wide range of objects including natural objects, works of fine art, items from decorative arts, archaeology, technology, life sciences, and other domains. Below, the term “cultural objects” refers to all these kinds of objects, following the UNESCO definition of cultural heritage.

Among other features, LIDO is able to represent contextual information as events occurring in the lifetime of an object. This approach is highly flexible, easy to follow, and consistent with internationally agreed recommendations for museum documentation (see sections 2.3 Background and 2.4 Related standards). Events can also connect an object description to the wider knowledge sphere, using Linked Data principles.

A single object or work, or a group of objects, is described in a LIDO record using XML syntax. A LIDO document can contain one or several LIDO records. The representation of the LIDO schema in LIDO XML documents is referred to as the LIDO format.

There are many use cases for a LIDO based data exchange and transfer in provider/consumer scenarios. LIDO was initially designed as a data harvesting standard and still serves this function in heritage institutions where metadata is often made available through the OAI Protocol for Metadata Harvesting (OAI-PMH). Harvesting refers to the process of collecting and updating metadata by aggregation portals.

Next to descriptive metadata, a LIDO record contains administrative metadata that may include rights information and links to resource representations. Aggregation portals can use these links for guiding the user to media items (such as facsimiles, images, audio or video files, or 3D models) representing the collection object described in the metadata record. While accessing and obtaining such media items may be the actual goal of interacting with a portal, the metadata record is essential for making them findable, comprehensible, and to aid in their discovery.

2.2 Why LIDO?

LIDO is designed to allow for object descriptions at different levels of granularity or specificity. Few elements are considered mandatory in order to facilitate the recording of objects where detailed information is not available, while a great number of possible elements enables a fine-grained account of an object. The latter supports, for instance, a deeper exploration of data, possibly encouraging and facilitating research questions and the reuse of research data. By improving interoperability through the support of Linked Data principles and by providing data via interfaces or APIs, resources and research data become more visible and accessible.

The LIDO XML schema is designed to

• allow the description of objects or works, including non-artistic and natural objects, to the level desired;
• allow a data provider to decide how extensive the metadata sets they provide in a particular reuse context are, i.e., they can vary in different scenarios;
• enable the provision of metadata about digital surrogates representing the object in focus;
• provide links back to records in their home context, i.e., on an organization’s website;
• enable the display of (detailed) information about an object in a reader-friendly form, while the record content is equally well prepared for retrieval;
• support the identification of an associated entity such as an actor, an event, a place, or a concept, by allowing for references to authority files and controlled vocabularies;
• provide full support for multilingual records, either at the structural element level or at the individual term or appellation element level, or both;
• distinguish between the identifiers of the documented object, the web page containing a description of the object, its online digital surrogates and the LIDO record itself.

Representing metadata in LIDO enables efficient processing for public information portals where collection objects can be discovered, searched, viewed and contextualised.

2.3 Background

LIDO builds upon several pre-existing standards and guidelines for the description of cultural objects and metadata exchange. The LIDO schema integrates and extends CDWA Lite, is underpinned by the CIDOC Conceptual Reference Model (CIDOC CRM), and incorporates some information units from Spectrum definitions.

2.3.1 CDWA Lite

CDWA Lite is an XML schema derived from the Categories for the Description of Works of Art (CDWA), following the data content standard Cataloging Cultural Objects (CCO), published by the J. Paul Getty Trust and ARTstor. It is intended as a low-barrier way for institutions to contribute their collection metadata to union catalogs using the Open Archives Initiatives Protocol for Metadata Harvesting (OAI/PMH).

CDWA Lite defines 96 elements and sub-elements, most of which are integrated in LIDO. Note that the CDWA Lite schema is replaced by LIDO Version 1.0 since 2010.

The most important extension to CDWA Lite is the introduction of the <lido:event> element, reflecting the event-centric approach taken by the CIDOC CRM mentioned below. The Event element not only permits to describe the object history as such, but also the entities (like actors and places) associated with each single event.

There is a Metadata Standards Crosswalk provided by the Getty Vocabulary Program. It departs from the full CDWA standard, comprising a mapping of a partial list of the elements for 15 standards from the museum, library and archive sectors, including CDWA Lite.

For more information on the schema, see the publication CDWA Lite of the Getty Research Institute. For more information on the standard, see the CDWA Homepage and CDWA and Other Metadata Standards.

2.3.2 CIDOC CRM

The CIDOC Conceptual Reference Model is a formal ontology, published as ISO standard 21127 in 2006 (21127:2006), revised in 2014 (21127:2014). The CIDOC CRM provides definitions and a formal structure for describing foundational concepts and relationships used in cultural heritage documentation. It is intended to be a common language for domain experts and implementers when formulating requirements for information systems, and it is also regarded as an example for good practice of conceptual modeling. Development and maintenance work is carried out by the CIDOC CRM Special Interest Group (SIG), continuously active for more than two decades.

It was the CIDOC CRM event-centric modeling that inspired LIDO to introduce an Event element in addition to elements taken from CDWA Lite. Some of the CIDOC CRM classes and its definitions were considered in or aligned with the LIDO Terminology, particularly terms for the <lido:category> and <lido:eventType> elements. A mapping between LIDO 1.0 and the CIDOC CRM version 6.0 has been prepared in 2017, using the X3ML mapping definition language.

For more information on the model and versions of the standard see CIDOC CRM Home.

2.3.3 Spectrum

Spectrum is a collections management standard provided by the UK Collections Trust charity. It describes activities, known as “procedures” in Spectrum, commonly encountered in managing museum collections. The standard also specifies Information requirements to be applied to procedures, for instance, Object information groups, further containing “Units of information” for documentation purposes, e.g., Object production information. The Spectrum version 5.0 was published in September 2017, including 21 procedures, nine of which are considered “Primary procedures”.

In LIDO, some of the information units defined in Spectrum have been considered, particulary from the Object collection information. There is also a list of mappings available in Mapping Spectrum to other standards, including a mapping from Spectrum 5.0 to LIDO Version 1.0.

For more information on Spectrum see Introduction to Spectrum 5.0 by Collectios Trust.

2.4 Related standards

LIDO builds upon several standards, specifications, and guidelines. A structured view of relevant background information offers the following distinction:

• Formal models as reference frameworks for data integration, notably the CIDOC Conceptual Reference Model (CIDOC CRM), the IFLA Library Reference Model (IFLA LRM), and FRBRoo, a conceptual model for bibliographic information in object-oriented formalism.
• Rules for data content include cataloging guidelines, specifically Categories for the Description of Works of Art (CDWA) and Cataloging Cultural Objects: A Guide to Describing Cultural Works and Their Images (CCO).
• Controlled vocabularies for data values, such as authority files like the Union List of Artist Names (ULAN) or thesauri like the Art & Architecture Thesaurus (AAT).

For more related standards see the list of Standards and guidelines provided by the CIDOC community, and the overview in CDWA and Other Metadata Standards as well as the Metadata Standards Crosswalk, both maintained by the Getty Vocabulary Program.

3 Design principles

3.1 Basic considerations

The design of LIDO was guided by the following considerations:

• Reuse existing standards Preexisting models for representing cultural heritage metadata contain assumptions that are still valid today. These should be preserved and re-used in the design of LIDO. For an overview of preexisting models see section 2.3 Background.
• Use proven technologies Metadata needs to be processed in a wide range of system environments. Choosing proprietary or poorly supported technologies can result in barriers and unnecessary costs. For a brief summary of the XML family of technologies adopted for LIDO see section 3.2 Choice of technologies.
• Facilitate interoperability Metadata is moved, transformed, distributed, and interconnected at an increasing rate. LIDO should therefore facilitate and encourage higher levels of harmonization than in the past. Next to technical and organizational considerations described in section 3.3 Supporting Web principles, mappings between LIDO and standards as well as models from other domains are essential tools for enabling and maintaining such harmonization.
• Enable adaptability The information landscape is changing continuously, bringing up new requirements that need to be addressed without invalidating existing data records. Not all future requirements can be anticipated. Well-defined extension points should be provided as parts of the model. Moreover, cultural heritage metadata will continue to be produced in varying degrees of detail and granularity. The model should therefore be amenable to object descriptions of widely different richness by allowing for the introduction of application-specific restrictions (see section 3.4 Enabling adaptability).

3.2 Choice of technologies

3.2.1 An XML schema for LIDO

The Exensible Markup Language (XML) has evolved from a mere markup language for structuring machine-processable text into a major technological ecosystem with a wide range of auxiliary specifications and tools. This long-term evolution justifies the assumption that XML will not become obsolete in the foreseeable future. Nevertheless, it is fair to say that JSON (JavaScript Object Notation) is emerging as a contender in many areas where use of XML is currently prevalent. Moreover, the Linked Data paradigm, briefly described in chapter 3.3 Supporting Web principles, presents a challenge due to the core differences between the XML and RDF data models. Version 1.1 of the LIDO schema is an attempt at reconciling some of these differences.

Given the maturity of XML and the broad support in the information processing sphere, it is reasonable to expect that this technology is, and will remain, a solid and reliable platform for the LIDO metadata schema.

XML itself defines the format of markup elements (often referred to as tags) and how these can be nested to form a tree-like structure. Any XML document that obeys the basic element syntax and has matching start and end tags is said to be well-formed.

In order to allow for predictable processing of the document content, the order and occurrence of markup elements is typically restricted by a schema (sometimes referred to as the document grammar). At least three languages (known as DTD, RELAX NG, and XSD) are available for writing XML schema definitions. The LIDO schema is written in the XML Schema Definition (XSD) language, which can be considered the most expressive of these three.

The core specification for LIDO is laid down in an XSD document. This schema document can be used by software tools known as validating parsers in order to verify if a LIDO record complies with all rules and restrictions given in the schema. Such validation is essential wherever the LIDO record is to be processed for usage in databases, web portals, or in transformation chains as used in large-scale aggregation portals.

3.2.2 Schema design

The XSD language provides some mechanisms for object-oriented design. This means that schema constructs can be defined on an abstract level, acting as types or templates for actual element or attribute definitions. The LIDO schema definition makes extensive use of type declarations for elements composed of more than one element, or of simple data types with attributes. In the XSD language, these type declarations are referred to as complex types. In fact, the entire LIDO record structure is first modeled on the abstract level of complex types, before declaring the derived elements that are actually used in a LIDO record. This design principle offers a clear distinction between the model and its implementation.

The basic structure of LIDO is determined by the XML schema specification which defines the building blocks of a LIDO XML document:

• the elements and attributes that may occur in a LIDO document,
• the allowed data types for values of elements and attributes,
• the number and order of child elements is declared in complex types.

3.2.3 Namespaces

As explained in section 2.3 Background, reuse of existing specifications is an important objective in the design of the LIDO schema. XML has mechanisms for combining definitions from more than one schema. This allows a schema definition to “borrow” element or attribute definitions from other schemas, typically using a mechanism known as namespaces.

Declaring a namespace for LIDO allows to distinguish between elements or attributes that are part of the LIDO data model, and others that are defined elsewhere. Namespaces determine the scope and origin of an element or attribute name. In other words, a namespace indicates who is responsible for the definition of a particular element or attribute name and where XML processing software can find the corresponding schema. Namespaces also allow to distinguish between elements or attributes that carry identical names. As an example, the meaning of rdf:type is different from that of lido:type.

A combination of namespace and name is referred to as qualified name (a QName in XML terminology). QNames can be written either in full or in an abbreviated form:

<http://www.lido-schema.org/titleSet>

is identical to

<lido:titleSet xmns:lido="http://www.lido-schema.org">

In practice, the abbreviated namespace (in this case, “lido”) is only declared once in the outermost element of an XML document. This allows all subsequent elements and attributes from the LIDO namespace to be written with what is known as a namespace prefix, followed by a colon:

<lido:lidoWrap  xmns:lido="http://www.lido-schema.org" (...)  >
    (...)
        <lido:titleSet>
    (...)

LIDO XML records prepared using the Schema Version 1.1 can (and should) include the following prefix declarations in their outermost element.

Table 1: Prefix declarations

3.3 Supporting Web principles

The Web as a platform for cultural heritage information has seen a number of changes since the introduction of LIDO v1.0. Arguably the most significant developments are concerned with openness and interconnection of published knowledge. In LIDO Schema Version 1.1 new constructs were introduced, primarily focussing on requirements from two areas: the FAIR Principles and the Linked Data Platform Guidelines.

3.3.1 FAIR Principles

The FAIR Principles, first published in 2016, are guidelines provided by the research data community to improve the computability for finding, accessing, interoperating, and reusing data. The principles may also serve as a checklist for funding agencies. LIDO is well suited to play a key role in implementing FAIR principles in the domain of cultural heritage metadata. Four main principles are defined that should guide the preparation of data and metadata, in particular (identifiers in square brackets refer to the corresponding topics from the FAIR guidelines):

F – Findable: LIDO mandates the use of publishable identifiers both for the object [F3] and the metadata record [F1]. LIDO implements a rich metadata model [F2] designed for indexing and retrieval [F4].

A – Accessible: LIDO metadata is readily distributed via open protocols such as OAI-PMH and REST-based APIs [A1] and is harvested by aggregators [A2] at significant scale.

I – Interoperable: LIDO builds upon a well-established and extensively documented XML schema definition [I1] that expressly supports the use of linked open vocabularies [I2].

R – Reusable: LIDO has provisions for detailed licensing information, for both the data resources and the metadata [R1.1], for metadata provenance [R1.2], and for domain-specific metadata such as events occuring in the object lifecycle [R1.3].

3.3.2 Semantic Web technologies

The notion of a Semantic Web originated soon after the “classic” Web had gained acceptance. While ordinary Web pages with hyperlinks support little more than free-text search, a desire was felt to make assertions on the Web that can be acted upon by machines more precisely, for example, for compiling databases of factual statements derived from, and linked to, Web pages. Initially, metadata standards such as LIDO were not primarily designed as building blocks for the Semantic Web, but rather to co-exist with it.

The Semantic Web idea gave rise to a technology known as the Resource Description Framework (RDF). RDF is a data model that uses a sentence-like structure (subject–predicate–object) to express statements about things. For example, a painting (the subject) was created (the predicate) by a person (the object) where the person can become the subject for further statements, such as the person’s date of birth, place of activity, working field, etc.

The LIDO schema beginning with version 1.1, while strictly rooted in XML technology, permits a limited number of RDF statements (<skos:Concept>, <owl:sameAs>) to be used as a bridge to Linked Open Data (LOD), and thus the Semantic Web. Moreover, the LIDO Terminology was designed from the ground up to comply with Semantic Web principles.

Initiatives for transforming LIDO data to RDF are underway. However, development of a fully RDF-based metadata schema for cultural heritage is still at an early stage. Examples are the proposed RDF Ontology for the Visual Resources Association Core (VRA CORE) standard, and the data model proposed by the Linked Art community.

Progress in this area can be followed by subscribing to the LIDO mailing list or by sending email to the LIDO working group. For details, see https://cidoc.mini.icom.museum/working-groups/lido/lido-community/.

3.3.3 Linked Data

Data published in accordance with Semantic Web principles is known as Linked Data. Most Linked Data of interest to the cultural heritage community is freely available as Linked Open Data (LOD).

LIDO strongly recommends the use of controlled vocabularies wherever an index element for a concept can occur, and of shared authority files where a reference to a named entity, such as a person, an organization, or a place is expected. Very often the relevant concept or entity is described in one of the major LOD sources such as the Art & Architecture Thesaurus (AAT), the German Integrated Authority File (GND), or in an aggregated Linked Data source such as VIAF or Wikidata. Last, but not least, the LIDO Terminology, recommended for many of the type attributes in LIDO, is also available as a LOD source.

In order to qualify as Linked Data, a data source must use the RDF data model. Each item must be uniquely and persistently identified by a URI, and the URI must be dereferenceable as a Web resource. The latter means that machines or humans can invoke the URI as a network address and obtain the corresponding resource in the desired RDF syntax, or in a human-readable rendering. A useful add-on to many LOD sources is the option to obtain arbitrary selections or aggregates of the available data by sending queries in the SPARQL Query Language for RDF.

The LIDO Terminology meets all of these requirements and can therefore claim to be a fully qualified LOD source. LIDO itself can only partly comply with Linked Data requirements in that LIDO records can be published under persistent URIs. Extracting single statements from a LIDO record requires querying the XML syntax tree using a foundational technology that is different from what is used for Linked Data.

In summary, it can be stated that LIDO supports publishing data as Linked Open Data for the following reasons:

• LIDO supports the use of LOD-enabled controlled vocabularies and authority files.
• The LIDO Terminology is available as LOD vocabularies, where each LIDO Term is a resolvable RDF resource, identified by a persistent Uniform Resource Identifier (URI). For instance, the URI for the Event Type “Production” is http://terminology.lido-schema.org/lido00007.
• The element and attribute names declared in the LIDO schema could be made into RDF class and property names in a future RDF rendering of LIDO records.

3.4 Enabling adaptability

Adaptability means decreasing or increasing the expressivity, and thus the complexity, of the data model. Doing so requires precautions to ensure that all resulting LIDO records are still valid with respect to the current LIDO XML schema.

3.4.1 Restriction and simplification

The LIDO XML schema itself permits a considerable degree of freedom for choosing the amount of detail that goes into a data record. In some cases it may be useful, or even required, to suppress the usage of elements or attributes explicitly so that processing systems do not have to be prepared to process them.

Restrictions may be declared in ancillary files, e.g., in the form of external Schematron rules (see chapter 6.2 Schematron), transformation scripts, or any other technology suitable for checking or restricting the content of XML records. Evidently, restrictions also must not lead to the disappearance of mandatory LIDO elements. The recommended way to implement restrictions, however, is the creation of an application profile (s. below).

A different case for simplification can occur if the content of the LIDO record is to be rendered in a less expressive data model. For example, some applications of the OAI-PMH harvesting protocol require that whatever schema is used for the original data, a simplified representation using Dublin Core must be provided alongside the original record. This requires transforming the LIDO record according to a mapping scheme, in the case of Dublin Core somewhat flippantly referred to as “dumbing down”.

3.4.2 Extension

Different collections of cultural and natural objects may have specific description requirements not readily available in LIDO. While simplification can be achieved without touching the LIDO XML schema, adding expressivity to the schema may sometimes require more complex solutions.

A frequent case is that a concept is either missing from a recommended vocabulary, or considered too broad for the intended purpose. Where a more suitable vocabulary is available as Linked Data, this may safely be used within the <skos:Concept> element without compromising the schema validity of the LIDO record.

3.4.3 Application profiles

Application profiles are a way of economizing the use of broadly scoped standards. They allow users to specify rules and recommendations for specific use cases, define rules to improve data editing and quality, or solve possible ambiguities of the relevant standard. A LIDO application profile might include element restrictions or recommend or mandate specific vocabularies, and more.

An application profile is always a sub-standard of its parent. It may specify an element’s semantics compared to generic LIDO, but never change its semantics. Further, mandatory elements and attributes must not be declared optional. This ensures that a LIDO record conforming to an application profile is still a valid generic LIDO record.

3.4.3.1 What Constitutes an Application Profile?

The rules of an application profile can either be expressed in a textual document (such as a print publication, HTML document, etc.) or a set of machine-actionable rules (XML Schema and/or Schematron rules). Ideally, an application profile comprises both, providing textual documentation of the rules and background of an application profile, as well as a machine-actionable file to automatically check records for conformance.

The LIDO Application Profile Workflow is the recommended way of creating application profiles. It provides an easy way to document differences between the application profile and generic LIDO, as well as to produce documentation and machine-actionable rules for the profile. You can find the workflow as well as more extensive documentation in the relevant GitLab Repository.

3.4.3.2 How to Use the Application Profile Workflow

Use of the application profile worklflow requires basic knowledge of XML and XML Schema Definition. Some familiarity with Schematron, XPath, and TEI-Lite is useful, though not necessarily required.

The profile workflow is built around the LIDO Profile Definition XML. This file contains all the information users need to provide for the process to produce a valid LIDO application profile: profile metadata, profile documentation, and the profile rules. This way, the Profile Definition serves as a single source for both machine-actionable rules as well as HTML documentation. Each of the output files is produced by a single XSL transformation of the Profile Definition.

Machine-actionable rules can be declared as XML Schema rules, as well as Schematron rules.

Profile documentation in the Profile Definition follows TEI-Lite and is the primary source for HTML documentation. For ease of use, the workflow can also produce simple documentation of individual rules and Schematron constraints if desired.

The repository contains an empty Profile Definition template to facilitate the creation of new Profile Definitions by users, as well as further resources to aid the creation of application profiles.

For more information on LIDO profiles, see section 4.2.4 Application Profile, the GitLab Repository hosting the workflow, and https://cidoc.mini.icom.museum/working-groups/lido/lido-overview/profiles/.

4 Basic structure of LIDO

4.1 LIDO document and LIDO record

The basic structure of LIDO is determined by the XML representation. Any data represented in XML requires a single outer element, enclosing all further data. With regard to the tree-like structure of XML, this outermost element is referred to as the root element. The root element is where all machine processing of XML data starts and ends. Either the LIDO wrapper <lido:lidoWrap> or the LIDO element <lido:lido> can be used as the root element for an entire LIDO document. A document with the root <lido:lido> can contain only one LIDO record, while a document with the root <lido:lidoWrap> can contain one or more <lido:lido> elements i.e. one ore more LIDO records. Both forms are valid with respect to the LIDO XML schema.

4.2 Top level elements

In the <lido:lido> element six elements are nested at the top. Following is an outline of these elements with short descriptions.

The <lido:lido> element fully encloses a metadata record. The following list contains the six elements that can occur at the upper level of a LIDO record. Three of these are mandatory elements:

• LIDO Metadata Record Identifier required
• Published Object Identifier
• Category
• Application Profile new in LIDO v1.1
• Descriptive Metadata required
• Administrative Metadata required

The LIDO top level elements in XML syntax:

<lido:lido>
    <lido:lidoRecID lido:type="{...}">[...]</lido:lidoRecID>
    <lido:objectPublishedID>[...]</lido:objectPublishedID>
    <lido:category>[...]</lido:category>
    <lido:applicationProfile lido:type="{...}">[...]</lido:applicationProfile>
    <lido:descriptiveMetadata xml:lang="{...}">[...]</lido:descriptiveMetadata>
    <lido:administrativeMetadata xml:lang="{...}">[...]</lido:administrativeMetadata>
</lido:lido>

4.2.1 LIDO Metadata Record Identifier

Element name: <lido:lidoRecID>

Note: This mandatory element serves to distinguish an individual LIDO record from any other record that may occur in a database, data repository, or any other aggregation of machine-processable records. The LIDO Metadata Record Identifier is preferably composed of an identifier for the contributor and a record identification in the (local) system of the contributor. It is not required to be persistent, which means that it can be obsoleted when new versions of a LIDO record become available. Any subsequent version of a LIDO record should be distinguishable at least by using the <lido:recordMetadataDate> element. For identifiers guaranteed to be persistent see the <lido:objectPublishedID> described below. However, some aggregators will expect this identifier to be persistent throughout all updates.

Example for “URI”: In the following example the LIDO Metadata Record Identifier is composed of the ISIL (International Standard Identifier for Libraries and Related Organisations) of the contributor and the local record ID. The mandatory type attribute has a value from the LIDO Terminology for “URI”, and the source is provided as ISIL of the contributor.

LIDO Metadata Record Identifier: ld.zdb-services.de/resource/organisations/DE-Mb112/lido-obj00154983

Type: URI | Source: ld.zdb-services.de/resource/organisations/DE-Mb112

<lido:lidoRecID
    lido:type="http://terminology.lido-schema.org/lido00099"
    lido:source="ld.zdb-services.de/resource/organisations/DE-Mb112">
    ld.zdb-services.de/resource/organisations/DE/DE-Mb112/lido-obj00154983
</lido:lidoRecID>

Example for “Local identifier”: In the following example the LIDO Metadata Record Identifier is composed of the ISIL of the contributor (data provider) and the local record ID. The mandatory lido:type attribute has a value from the LIDO Terminology for “Local identifier”, and the source is provided as free text.

LIDO Metadata Record Identifier: DE-Mb112/lido-obj00154983 Type: Local identifier | Source: Deutsches Dokumentationszentrum für Kunstgeschichte - Bildarchiv Foto Marburg

<lido:lidoRecID
    lido:type="http://terminology.lido-schema.org/lido00100"
    lido:source="Deutsches Dokumentationszentrum für Kunstgeschichte - Bildarchiv Foto Marburg">
    DE-Mb112/lido-obj00154983
</lido:lidoRecID>

4.2.2 Published Object Identifier

Element name: <lido:objectPublishedID>

Note: This element contains a public entry for the described object or work in another information system or authority file. This identifier should always be a dereferenceable URI so that it can be used as a key to associated information. Repeatable for identifiers from more than one source. If there are multiple published identifiers, then the attribute lido:pref should mark the one preferred by the provider of the LIDO record.

Example: In the following example the Published Object Identifier is marked as the preferred one by the data provider. The mandatory lido:type attribute has a value from the LIDO Terminology for “URI”, and the source is provided as free-text.

Published Object Identifier: https://d-nb.info/gnd/4074156-4 Preference: Preferred | Type: URI | Source: Deutsche Nationalbibliothek: Gemeinsame Normdatei. URL: https://d-nb.info/gnd [2022-09-23]

<lido:objectPublishedID
    lido:pref="http://terminology.lido-schema.org/lido00169"
    lido:type="http://terminology.lido-schema.org/lido00099"
    lido:source="Deutsche Nationalbibliothek: Gemeinsame Normdatei. URL: http://d-nb.info/gnd [2022-09-23]">
    http://d-nb.info/gnd/4074156-4
</lido:objectPublishedID>

4.2.3 Category

Element name: <lido:category>

Note: Category is a content element for grouping LIDO records together by very broad classes of objects or works. Initially intended to be populated with high-level classes of the CIDOC CRM, particularly sub-classes of E18 Physical Thing, there is now a Category Vocabulary available from the LIDO Terminology for use in this element. Note that a <lido:category> statement must be logically and semantically consistent with what is said in the more specific <lido:objectWorkType> and <lido:classification> elements.

Example: In the following example, the category statement is fully expressed by the LIDO Terminology identifier, “lido00096”. The term in <skos:prefLabel> is given here both for human readability and for use by processing systems that are not prepared for fetching data using a vocabulary URI.

Category: Human-made object Preference: Preferred

<lido:category>
    <skos:Concept rdf:about="http://terminology.lido-schema.org/lido00096">
        <skos:prefLabel xml:lang="en">Human-made object</skos:prefLabel>
    </skos:Concept>
</lido:category>

4.2.4 Application Profile

Element name: <lido:applicationProfile>

Note: The LIDO schema may not cover all metadata needs of the user community. To accommodate specialized user requirements, the LIDO schema can be complemented with application profiles. Whenever an application profile has been used in the preparation of a LIDO record, the <lido:applicationProfile> element should carry the public identifier (URI or equivalent) of the respective document(s). For further information on LIDO profiles, see section 3.4.3 Application Profiles and https://cidoc.mini.icom.museum/working-groups/lido/lido-overview/profiles/.

Example: In the following example the Application Profile Element contains the URI of the XML Schema Definition Document of the LIDO Application Profile Painting and Sculpture.

Application Profile: https://lido-schema.org/profiles/v1.1/lido-v1.1-profile-paintingandsculpture-v1.0.xsd Type: URI

<lido:applicationProfile
    lido:type="http://terminology.lido-schema.org/lido00099">
    https://lido-schema.org/profiles/v1.1/lido-v1.1-profile-paintingandsculpture-v1.0.xsd
</lido:applicationProfile>

4.2.5 Descriptive Metadata

Element name: <lido:descriptiveMetadata>

Note: Descriptive metadata are intended to facilitate the discovery and identification of objects or works. They are most visible to end-users, guiding them through the physical or virtual shelves and enabling them to find what they need. Descriptive metadata comprise information on object properties, such as its type, title, physical features, or participation in an event. Note, that the use of <lido:descriptiveMetadata> provided with an xml:lang attribute is mandatory.

4.2.6 Administrative Metadata

Element name: <lido:administrativeMetadata>

Note: Administrative metadata are intended to facilitate the management of the data provided, particularly holding information about rights and restrictions on the access or use of the described object or work, the provided record or any supplied resource. Note, that the use of <lido:administrativeMetadata> provided with an xml:lang attribute is mandatory.

4.3 Element nesting

Element nesting means that elements contain other elements that contain still other elements, and so forth. A nested structure of so called parent elements and child elements is a basic feature of XML. As with CDWA Lite, LIDO consists of wrapper and set elements that only serve to structure the data, and data elements for the actual data content. In this Primer document, the wrapper and set elements are referred to as structural elements, whereas the elements actually holding data are called content elements. Since a complete LIDO record can have a dozen or more nesting levels, some distinctions between kinds of elements are made in the LIDO element descriptions.

The following figure shows the nesting of LIDO structural and content elements with a corresponding example for the description of materials and techniques, used in the production of an object. The Object Materials/Techniques Wrapper contains the Object Materials/Techniques Set, enclosing the Display Materials/Techniques element and the set for Materials/Techniques, holding the index elements.

Example: Following is an XML code snippet containing the elements depicted in figure 5.

 <lido:objectMaterialsTechWrap>
    <lido:objectMaterialsTechSet>
        <lido:displayMaterialsTech xml:lang="{...}">[...]</lido:displayMaterialsTech>
        <lido:materialsTech>
            <lido:termMaterialsTech lido:type="{...}">
                <skos:Concept rdf:about="{...}"></skos:Concept>
            </lido:termMaterialsTech>
        </lido:materialsTech>
    </lido:objectMaterialsTechSet>
</lido:objectMaterialsTechWrap>

4.3.1 Structural elements

LIDO defines structural elements for grouping more specific elements together. A structural element is either a wrapper which is non-repeatable, or a repeatable set. Usually, wrappers are on a higher nesting level relative to set elements, the latter being typically enclosed by a wrapper. However, wrapper elements may also occur as sub-elements of wrappers as well as sets.

4.3.1.1 Wrapper elements

Note: In the LIDO Schema Documentation, an element is introduced as “A wrapper …” if it structures the data in a LIDO record and if it is not repeatable.

Features: Wrappers are not repeatable, have no attributes, except for a language attribute that can be given to administrative and descriptive metadata. A wrapper itself does not hold any content data.

Example: <lido:classificationWrap> is a wrapper for the index element <lido:classification>, and is contained by the wrapper element <lido:objectClassificationWrap>.

<lido:classificationWrap>
    <lido:classification lido:type="{...}">
        <skos:Concept rdf:about="{...}"></skos:Concept>
    </lido:classification>
</lido:classificationWrap>

4.3.1.2 Set elements

Note: In the LIDO Schema documentation, an element is introduced as “A set …” if it structures the data in a LIDO record and if it is repeatable.

Features: In contrast to LIDO wrappers, sets are repeatable and can have attributes. Like wrappers, they do not hold any content data.

Example: <lido:measurementsSet> is a set element that encloses three index elements for object dimensions (<lido:measurementType>, <lido:measurementUnit>, <lido:measurementValue>), all of which are mandatory if <lido:measurementsSet> is used. The set is repeatable within its parent element so that it can accommodate data for different types of dimensions, such as height, width, weight, etc. The following XML code snippet shows the usage of measurement types “height” and “width”.

<lido:objectMeasurementsSet>
    <lido:displayObjectMeasurements xml:lang="en">height x width [...]</lido:displayObjectMeasurements>
    <lido:objectMeasurements>
        <lido:measurementsSet>
            <lido:measurementType>
                <skos:Concept rdf:about="{...}">
                    <skos:prefLabel xml:lang="en">
                        height
                    </skos:prefLabel>
                </skos:Concept>
            </lido:measurementType>
            <lido:measurementUnit>
                <skos:Concept rdf:about="{...}"></skos:Concept>
            </lido:measurementUnit>
            <lido:measurementValue>[...]</lido:measurementValue>
        </lido:measurementsSet>
        <lido:measurementsSet>
            <lido:measurementType>
                <skos:Concept rdf:about="{...}">
                    <skos:prefLabel xml:lang="en">
                        width
                    </skos:prefLabel>
                </skos:Concept>
            </lido:measurementType>
            <lido:measurementUnit>
                <skos:Concept rdf:about="{...}"></skos:Concept>
            </lido:measurementUnit>
            <lido:measurementValue>[...]</lido:measurementValue>
        </lido:measurementsSet>
    </lido:objectMeasurements>
</lido:objectMeasurementsSet>

4.3.2 Content elements

The LIDO element descriptions distinguish between the following kinds of content elements:

1. Text elements for free-text notes
2. Display elements, a kind of text elements
3. Index elements holding indexing terms
4. Identifier elements for all kinds of entities

4.3.2.1 Text elements

Note: In the LIDO Schema Documentation, an element is introduced as “A text element …” if it is intended to present human-readable notes or explanations, populated with free-text data values. Most of the text elements are used for display and source information, or for more detailed textual descriptions of the object or work. Note that exactly one <lido:appellationValue> per language should be marked as the preferred one.

Features: Defined by textComplexType, a text element can have attributes, is repeatable (under conditions), and has free text (xs:string) as its data value.

Example: <lido:appellationValue> is a text element contained by several elements for naming entities. This element is required if an element for naming entities is used, e.g., <lido:nameActorSet>.

Creator: Leonardo da Vinci Preference: Preferred

<lido:nameActorSet>
    <lido:appellationValue
        lido:pref="http://terminology.lido-schema.org/lido00169"
        xml:lang="en">
        Leonardo da Vinci
    </lido:appellationValue>
</lido:nameActorSet>

4.3.2.2 Display elements

Note: In the LIDO Schema Documentation, an element is introduced as “A display element …” if it contains a human-readable rendering of what is stated in the associated index element. For an account of LIDO display elements and more detailed information see section 4.3.3 Display and index elements.

Features: Defined by textComplexType, a display element can have attributes, is repeatable only for different languages, and has free text (xs:string) as its data value.

Example: <lido:displayMaterialsTech> is a textual description of the associated index terms in <lido:termMaterialsTech> contained, e.g., by the <lido:objectMaterialsTechSet> element.

Materials/Techniques: Oil on poplar panel

<lido:objectMaterialsTechSet>
    <lido:displayMaterialsTech xml:lang="en">
        Oil on poplar panel
    </lido:displayMaterialsTech>
</lido:objectMaterialsTechSet>

4.3.2.3 Index elements

Note: In the LIDO Schema Documentation, an element is introduced as “An index element …” if it refers to general concepts for indexing and retrieval. Index elements provide sub-elements for information on the indexing concept, including its URI or local identifier, and the natural language term or terms. For more information on display and index elements see section 4.4.3 Display and index elements below.

Features: Defined by conceptComplexType, an index element can have attributes, may be repeatable, and is populated with elements containing controlled data values.

Example: <lido:termMaterialsTech> is an index element to provide descriptors for materials, e.g., medium or support, and techniques, from controlled vocabularies.

Materials/Techniques: Oil paint Type: Medium Preference: Display

<!-- Medium -->
<lido:termMaterialsTech
    lido:type="http://terminology.lido-schema.org/lido00513">
    <skos:Concept
        rdf:about="http://vocab.getty.edu/aat/300015050">
        <skos:prefLabel xml:lang="en">
            oil paint (paint)
        </skos:prefLabel>
    </skos:Concept>
    <!-- Display label -->
    <lido:term
        lido:pref="http://terminology.lido-schema.org/lido00526"
        xml:lang="en">
        oil paint
    </lido:term>
</lido:termMaterialsTech>

4.3.2.4 Identifier elements

Note: In the LIDO Schema Documentation, an element is introduced as “An identifier …” if it is intended to hold values for IRIs, URIs, or local identifiers. There are thirteen identifier elements defined in LIDO, particularly for named entities, such as <lido:actorID>, administrative data, such as <lido:recordID>, or contextual information, such as <lido:resourceID>. Note that the lido:type attribute is required for identifiers. Terms for the type attribute are provided in the LIDO Identifier Type-Vocabulary. It is strongly recommended to use an HTTP URI identifier from a LOD vocabulary for the type attribute.

Features: Defined by identifierComplexType, an identifier element can have attributes, is repeatable (under conditions), and is populated preferably with URIs. If local identifiers must be used, then use of the source attribute is necessary for making the identifier unambiguous.

Example: <lido:actorID> holds an identifier for an actor.

Actor Identifier: http://viaf.org/viaf/24604287 Type: URI

<lido:actor>
    <lido:actorID
        lido:type="http://terminology.lido-schema.org/lido00099">
        http://viaf.org/viaf/24604287
    </lido:actorID>
</lido:actor>

4.3.3 Display and index elements

Following CDWA/CCO, LIDO defines elements to allow for recording distinct display information alongside the index entries intended for retrieval. A display element presents information in natural language, intended to be easily readable. An index element is designed to hold controlled values or descriptors from formal languages, such as thesauri or classification systems, assigned for information retrieval. Compared to index elements, the free-text display elements allow for a less rigid expression of information including subtleties, uncertainties, or fuzziness. In contrast, value-controlled index elements support consistent matching with user queries and reliable feedback for query refinement.

Portals can use the information given in display and/or index elements in various ways. If the display element is lacking an associated index element, then free text is the only source for search terms, forsaking the chance for more reliable search results. Where the display element is not used, portal designers will typically present the index terms in some order, perhaps linking them to a new or modified query. If the index terms are from a controlled vocabulary, then search portals may construct hyperlinks for semantically enhanced search and navigation, for example by offering a broader or narrower search focus, or by retrieving definitions and other additional information from the thesaurus or authority file (sometimes referred to as ‘exploring the knowledge graph’).

A total of 13 display elements are available in LIDO Version 1.1. The list below shows all of these elements within their sets and examples of the paired use of display elements with their corresponding index element.

Of 33 index elements in total, 12 are derived from conceptMixedComplexType. Elements declared this way can either contain plain text, or sub-elements with structured information, but not both simultaneously. These elements offer a fallback solution for data providers that can only supply textual keywords for indexing.

For further information see Cataloging Cultural Objects, chapter “Display and Indexing”, pp. 24–25. Examples and cataloging rules are provided in the respective chapter describing a category, e.g., Measurements, pp. 109–120.

The following table lists the 13 display elements and shows values for the display element as well as the corresponding index element or elements, if applicable for the painting Mona Lisa.

Table 2: List of display elements with examples for display and index data

4.4 Information areas and groups

Descriptive and administrative metadata in LIDO are organized into a total of seven structural elements, called information areas. This arrangement reflects basic information about content descriptions of cultural objects, rather than formal or technical requirements. Four of these areas are descriptive, while the other three hold administrative data.

Each information area in LIDO is a non-repeatable wrapper and a direct sub-element of the topmost descriptive or administrative metadata element. Being structural elements, the information areas do not hold any content data themselves. The following figure shows the seven areas, listed by their sequence in a LIDO record.

The direct sub-elements of the information areas are the main building blocks for structuring data content. These are called information groups in LIDO. Note that the information areas and information groups are introduced to provide a quick synopsis of major elements. Information areas and groups are not declared as such in the LIDO schema.

Table 3: Information areas and information groups

4.4.1 Descriptive Metadata

Descriptive Metadata in LIDO hold information about the properties of the described object itself, whether it is analog or digital. These data are essential for searching, finding, and identifying the object in collections or portals. Descriptive information about an object or work includes the following four information areas:

1. Object Classification
2. Object Identification
3. Event
4. Object Relation

4.4.1.1 Object Classification

The Object Classification Wrapper groups objects together on the basis of shared characteristics for discovery. It contains the information groups for Object/Work Type and Classification with the index elements <lido:objectWorkType> and <lido:classification>. While the former describes the object or work type as specific as possible, the latter groups objects together by broad categories, particularly for browsing or facet filtering. For information on the index elements <lido:objectWorkType> and <lido:classification> see sections 5.1 Mandatory elements and 5.2 Recommended elements.

4.4.1.2 Object Identification

The Object Identification Wrapper contains identifying information about an item, including its title, repository information, a textual object description, and description of the physical appearance. A minimum of information in this area is necessary to identify the unique item described in the LIDO record, distinguishing it from all similar ones in a collection, a local database, or an aggregation portal. For information on <lido:titleSet>, <lido:objectMeasurements>, and <lido:materialsTech> see sections 5.1 Mandatory elements and 5.2 Recommended elements.

4.4.1.3 Event

The Event Wrapper contains the repeatable <lido:eventSet> and enables the description of various events the object or work has been involved in or is associated with in some way. The <lido:eventSet> itself may be equally repeated in order to record the history of an object and its provenance as a chain of custodial events. An event-centric cataloging opens up ways to establish a network of contextual entities that may be associated with the event, usually actors, places, and dates. The LIDO elements <lido:eventActor>, <lido:eventPlace>, and <lido:eventDate> reflect the high-level entities of the CIDOC CRM model, E39 Actor, E53 Place, and E52 Time-Span, respectively. For information on indexing events see section 5.2 Recommended elements.

4.4.1.4 Object Relation

The Object Relation Wrapper comprises information on the topics of the object in focus, i.e., what it is about, and possible relations to other objects or works. It contains the two information groups <lido:subjectWrap> and <lido:relatedWorksWrap>. For information on the index elements <lido:subject> and <lido:relatedWork> see sections 5.1 Mandatory elements and 5.2 Recommended elements.

4.4.2 Administrative Metadata

Administrative Metadata in LIDO relate to the management of the described record or resource, and associated usage or intellectual property rights. This includes information about the rights holder, preservation and archiving processes the record or resource has gone through, as well as technical characterstics, e.g., for decoding or rendering the digital representation.

Information in the Administrative Metadata part of the LIDO schema is divided into three information areas, each of which has its dedicated wrapper element.

1. Rights for Work
2. Record
3. Resource

4.4.2.1 Rights for Work

The Rights for Work Wrapper contains information about intellectual property and usage rights associated with the described object or work. “Work” here refers to the object at hand as either a distinct intellectual or artistic creation such as a human-made artifact, or as a natural object such as a plant or a mineral specimen. Being an object in its own right, it is distinct from any surrogate resource which is to be described in its own wrapper. The rights associated with the described object or work are documented in <lido:rightsWorkSet>.

Note on Rights Type

The <lido:rightsType> element allows for indexing rights pertaining to each of the above information areas, i.e., the object or work, the record, and the resource. LIDO allows two distinct usages of this element: a generic type statement designating the kind of right in question, e.g., copyright or performance right, and specific rights information, such as a particular license. The values are provided by the LIDO Rights Type Type-Vocabulary.

Example: Following is an example of how to record a generic rights type.

<lido:rightsWorkWrap>
    <lido:rightsWorkSet>
        <!-- "Generic rights type" -->
        <lido:rightsType
            lido:type="http://terminology.lido-schema.org/lido00920">
            <skos:Concept
                rdf:about="http://vocab.getty.edu/aat/300055598">
                <skos:prefLabel xml:lang="en">
                    copyright
                </skos:prefLabel>
        </lido:rightsType>
    </lido:rightsWorkSet>
</lido:rightsWorkWrap>

Example: Following is an example of how to record specific rights information.

<lido:rightsWorkWrap>
    <lido:rightsWorkSet>
        <!-- "Specific rights information" -->
        <lido:rightsType
            lido:type="http://terminology.lido-schema.org/lido00921">
            <skos:Concept
                rdf:about="https://creativecommons.org/publicdomain/mark/1.0/">
                <skos:prefLabel xml:lang="en">
                    Public Domain Mark 1.0
                </skos:prefLabel>
            </skos:Concept>
        </lido:rightsType>
    </lido:rightsWorkSet>
</lido:rightsWorkWrap>

4.4.2.2 Record

The Record Wrapper contains information about this very LIDO record. It encloses three mandatory elements: <lido:recordID> relates to identifiers from systems where the description was produced, <lido:recordType> indicates the description level chosen for the object, and <lido:recordSource> holds data about the producer of this record. Further elements relate the identity of the originator, how the LIDO record can be referenced in databases or metadata repositories, and what rights are claimed by the originator for using this record. The rights associated with the record are documented in <lido:recordRights>.

Please note: Rights specifications in <lido:recordRights> refer to all elements of the current LIDO record. It is possible to specify different rights for individual object description texts in <lido:descriptiveNoteValue> using the element <lido:objectDescriptionRights> in the corresponding <lido:objectDescriptionSet>. Rights specifications in <lido:objectDescriptionRights> overwrite the rights specifications in <lido:recordRights>.

4.4.2.3 Resource

The Resource Wrapper contains information about the digital resource or resources that serve as a surrogate for the object or work. Typically this consists of one or more digital representations such as digital images, video or audio files, or 3D models for online access. Information includes the type of the resource and its digital format, as well as its source and rights. Note that the resource element does not apply to items that are considered objects/works in their own right, but only to surrogates of such. The rights associated with the resource are documented in <lido:rightsResource>.

For further information about metadata see NISO (2017): Understanding Metadata: What is Metadata, and What is it For?: A Primer

4.5 Element structure

Some content elements in LIDO follow a fixed structural pattern: A LIDO set, e.g., <lido:subjectActor>, comprises a display element followed by elements holding indexing information. This structure applies particularly to named entities for which an identifier may be used, such as actor, event, object, and place (see identifierComplexType). This pattern is also followed for, e.g., collection information, descriptions of materials and techniques, or measurements. For more information on display and index elements see section 4.3.3 Display and index elements.

4.5.1 Overview of the structure and the elements

The following figure shows the element structure, and an example for the description of an actor as subject of the described object or work. The sequence of the sub-elements of <lido:actor> is determined by the LIDO specification for actorComplexType.

Example: The following XML code snippet includes display and index elements to record identifying information about a person and its “Cultural affiliation” as a type for <lido:nationalityActor>.

<lido:subjectActor>
    <lido:displayActor xml:lang="{...}">
        [...]
    </lido:displayActor>
    <!-- Person -->
    <lido:actor
        lido:type="http://terminology.lido-schema.org/lido00163">
        <lido:actorID lido:type="{...}">
            [...]
        </lido:actorID>
        <lido:nameActorSet>
            <!-- Preferred name -->
            <lido:appellationValue
                lido:pref="http://terminology.lido-schema.org/lido00169"
                xml:lang="{...}">
                [...]
            </lido:appellationValue>
        </lido:nameActorSet>
        <!-- Cultural affiliation -->
        <lido:nationalityActor
            lido:type="http://terminology.lido-schema.org/lido01027">
            <skos:Concept rdf:about="{...}"></skos:Concept>
        </lido:nationalityActor>
    </lido:actor>
</lido:subjectActor>

4.5.2 Mandatory sequence of elements

The LIDO XML schema prescribes a sequence for elements occurring in elements defined by XML complex types. This sequence must always be observed. Validating parsers will detect any violation of mandatory sequences and will refuse to recognize the XML record as valid with respect to the LIDO schema definition.

Note, that only elements explicitly marked as required are mandatory to use in a LIDO record. For the description of an actor, for instance, it is required and sufficient to use the <lido:nameActorSet> element to get a valid LIDO record. If more information on the actor is given, such as a person’s nationality or vital dates, the prescribed sequence of actorComplexType must be observed to satisfy the LIDO schema definition.

5 Basic elements and attributes

This chapter introduces some of the most important content elements in LIDO, including elements from other namespaces, and gives an account of the attributes used for some of the LIDO elements. A brief explanation of the role of complex types in XML schema definitions and an enumeration of the complex types defined for the LIDO schema is appended.

5.1 Mandatory elements

5.1.1 Overview

Six content elements are declared mandatory in LIDO as a minimum requirement for a LIDO-compliant record. These elements are a subset of the core categories of CDWA, and are considered necessary to unambiguously identify an object or work. The motivation for selecting only a small number of mandatory elements was to offer a low threshold for transforming existing data to LIDO. Having only few restrictions also leaves room for adapting the LIDO schema to different requirements. The convenience of easy data transformation, however, has to be balanced against the risk of accepting poor metadata that often leads to unsatisfactory search results. Therefore, some elements in addition to the minimum set are strongly recommended to be used in the object description. Note that the elements Descriptive Metadata and Administrative Metadata must be present in any valid LIDO record. Besides, there are more mandatory elements, depending on the use of other elements, see below.

The following six content elements are mandatory, listed in the sequence of appearance in a LIDO record:

1. LIDO Metadata Record Identifier
2. Object/Work Type
3. Title Set
4. Record Identifier
5. Record Type
6. Record Source

The mandatory elements must be contained in a LIDO record. If any of these are missing, a validating XML processor will reject the LIDO record as invalid. Note, that this validation concerns the syntactical conformance to the LIDO schema only; it does not refer to the element contents, whether they contain data, and if this is semantically correct or not.

Therefore, the following example is a syntactically valid, yet semantically useless LIDO record.

<lido:lido>
    <lido:lidoRecID lido:type="xxx"></lido:lidoRecID>
    <lido:descriptiveMetadata xml:lang="xxx">
        <lido:objectClassificationWrap>
            <lido:objectWorkTypeWrap>
                <lido:objectWorkType></lido:objectWorkType>
            </lido:objectWorkTypeWrap>
        </lido:objectClassificationWrap>
        <lido:objectIdentificationWrap>
            <lido:titleWrap>
                <lido:titleSet>
                    <lido:appellationValue>
                    </lido:appellationValue>
                </lido:titleSet>
            </lido:titleWrap>
        </lido:objectIdentificationWrap>
    </lido:descriptiveMetadata>
    <lido:administrativeMetadata xml:lang="xxx">
        <lido:recordWrap>
            <lido:recordID lido:type="xxx"></lido:recordID>
            <lido:recordType></lido:recordType>
            <lido:recordSource></lido:recordSource>
        </lido:recordWrap>
    </lido:administrativeMetadata>
</lido:lido>

Note that more elements can become mandatory, depending on the use of a super-element (a parent element in XML terminology) or a sub-element (child element in XML), respectively. For example, <lido:eventType> is mandatory if the super-element <lido:event> is used; <lido:titleWrap> is mandatory if the sub-element <lido:titleSet> is used.

List of elements that are mandatory when the super-element (parent-element in XML) is used, listed in alphabetical order:

• <lido:actor> if <lido:actorInRole> is used
• <lido:appellationValue> if a named entity or a title is described
• <lido:eventType> if <lido:event> is used
• <lido:linkResource> if <lido:resourceRepresentation> is used
• <lido:measurementType> if <lido:measurementsSet> or <lido:resourceMeasurementsSet> is used
• <lido:measurementUnit> if <lido:measurementsSet> or <lido:resourceMeasurementsSet> is used
• <lido:measurementValue> if <lido:measurementsSet> or <lido:resourceMeasurementsSet> is used
• <lido:nameActorSet> if <lido:actor> is used

List of elements that are mandatory depending on the use of a sub-element (child-element in XML), listed in alphabetical order:

• <lido:classificationWrap> if <lido:classification> is used
• <lido:displayStateEditionWrap> if one of the sub-elements is used
• <lido:eventWrap> if <lido:eventSet> is used
• <lido:inscriptionsWrap> if <lido:inscriptions> is used
• <lido:objectDescriptionWrap> if <lido:objectDescriptionSet> is used
• <lido:objectMaterialsTechWrap> if <lido:objectMaterialsTechSet> is used
• <lido:objectMeasurementsWrap> if <lido:objectMeasurementsSet> is used
• <lido:objectRelationWrap> if <lido:subjectSet> and/or <lido:relatedWorkSet> is used
• <lido:relatedWorksWrap> if <lido:relatedWorkSet> is used
• <lido:repositoryWrap> if <lido:repositorySet> is used
• <lido:resourceWrap> if <lido:resourceSet> is used
• <lido:rightsWorkWrap> if <lido:rightsWorkSet> is used
• <lido:subjectWrap> if <lido:subjectSet> is used
• <lido:titleWrap> if <lido:titleSet> is used

5.1.2 LIDO Metadata Record Identifier

Element name: <lido:lidoRecID>

Note: This mandatory element serves to distinguish an individual LIDO record from any other record that may occur in a database, data repository, or any other aggregation of machine-processable records. The LIDO Metadata Record Identifier is preferably composed of an identifier for the contributor and a record identification in the (local) system of the contributor. It is not required to be persistent. For more detailed information and examples see section 4.2.1 LIDO Metadata Record Identifier.

5.1.3 Object/Work Type

Element name: <lido:objectWorkType>

Note: The designation object/work dates from the CDWA Lite category Object/Work, calling attention to the fact that the element embraces not only works of art, but, e.g., human-made everyday objects and natural specimens as well. This element captures the particular kind of an object, what the thing is in itself, considering its form and other intrinsic or defining characteristics. These generic properties are referred to as the isness of an object. Hence, a good descriptor for the object’s type conveys essential features of the object as required for reliable indexing and retrieval. The type of object at hand should always be indexed using the most specific descriptor available from the indexing vocabulary. Doing so is essential for ensuring a satisfactory level of precision in search results. In addition, there are more advantages when following the principle of the most specific and appropriate index entry (Cutter’s rule) if relying on a well-structured knowledge organization system. Specific descriptors for <lido:objectWorkType> may be found in the Objects Facet hierarchy of the Art & Architecture Thesaurus.

Example: In the following example the most specific concept from the Art & Architecture Thesaurus (AAT), “oil painting”, is used to describe the work type of the Mona Lisa by Leonardo da Vinci. This statement is further qualified by the value for the type attribute, “Object by material or technique”, taken from the LIDO Terminology and corresponding to the equivalent “guide term” in the AAT hierarchy. The values for <skos:prefLabel> and <skos:altLabel> are supposed to be automatically taken from the AAT concept. In the case where the labels provided by the authority vocabulary are not well suited for display purposes, a <lido:term> with preference “Display label” may be added to control how the term will be presented. Terms for the lido:type attribute of Object/Work Type are provided by the LIDO Object/Work Type Type-Vocabulary.

Object/Work Type: Oil painting Preference: Display

<!--Object by material or technique-->
<lido:objectWorkType
    lido:type="http://terminology.lido-schema.org/lido00789">
    <skos:Concept
        rdf:about="http://vocab.getty.edu/aat/300033799">
        <skos:prefLabel xml:lang="en">
            oil paintings (visual works)
        </skos:prefLabel>
    </skos:Concept>
    <!-- Display label -->
    <lido:term
        lido:pref="http://terminology.lido-schema.org/lido00526"
        xml:lang="en">
        Oil painting
    </lido:term>
</lido:objectWorkType>

See also Cataloging Cultural Objects: 1.1 About Object Naming, pp. 48–50.

5.1.4 Title Set

Element name: <lido:titleSet>

Note: The Title Set element holds values for the appellation of the object or work, such as a title proper for a work or a name by which the object is known. A title is critical to always have a human-readable text to refer to an object, and making it distinguishable from similar objects in search results. There may exist multiple titles in a given language, as well as titles in different languages. One title has to be marked as the preferred one in each language, if there is more than one title; all other titles are regarded as alternative ones. It is strongly recommended to provide a descriptive, concise title that indicates the most important features to be recognized at a glance. If no title or name is available, a descriptive one should be constructed based on the object/work type and further characteristics sufficient to select and distinguish the object in information retrieval. For example, “Daucus carota L.” as a title may apply to dozens of plant specimens. Enriching the title with information from place and date elements can yield unique object titles such as “Daucus carota L. from Gmünd, Niederösterreich, 2009”, or “Seats from Zea mays L. from Missahoe (Togo), 1914”. Where multiple titles are taken from different sources, the title set has to be repeated for each source. Note that (local) inventory numbers should not be recorded in titles.

Example: The following example shows a published title sufficiently descriptive for identification. The type for <lido:titleSet> is taken from the AAT “titles (general, names)” hierarchy as suggested in the LIDO Terminology Recommendation. The preferred title in this example is the best known one, “Mona Lisa”. The published title is marked as an alternative one and useful for search queries. The CDWA guidelines recommend to always provide a descriptive title which in this example is drawn from the CONA record for “Mona Lisa”.

Title: Mona Lisa Preference: Preferred | Source: Getty Vocabulary Program, CONA [online], Mona Lisa.
Descriptive title: Portrait of Lisa Gherardini Preference: Alternative | Source: Getty Vocabulary Program, CONA [online], Mona Lisa.
Published title: PORTRAIT DE MONA LISA (1479-1528) ; DITE LA JOCONDE Preference: Alternative | Source: Collections des musées de France (Joconde), Portait de Mona Lisa.

<!-- Preferred title -->
<lido:titleSet
    lido:pref="http://terminology.lido-schema.org/lido00169">
<!-- Preferred appellation -->
    <lido:appellationValue
        lido:pref="http://terminology.lido-schema.org/lido00169"
        xml:lang="en">
        Mona Lisa
    </lido:appellationValue>
    <lido:appellationValue
        lido:pref="http://terminology.lido-schema.org/lido00169"
        xml:lang="de">
        Mona Lisa
    </lido:appellationValue>
    <lido:sourceAppellation
        xml:lang="en">
        Getty Vocabulary Program, CONA [online], Mona Lisa. URL: http://vocab.getty.edu/page/cona/700000213 [2022-07-04]
    </lido:sourceAppellation>
    <lido:sourceAppellation
        xml:lang="de">
        German National Library, GND, Mona Lisa. URL: https://d-nb.info/gnd/4074156-4 [2022-07-04]
    </lido:sourceAppellation>
</lido:titleSet>
<!-- Alternative title; descriptive title -->
<lido:titleSet
    lido:type="http://vocab.getty.edu/aat/300417199"
    lido:pref="http://terminology.lido-schema.org/lido00170">
    <!-- Alternative appellation -->
    <lido:appellationValue
        lido:pref="http://terminology.lido-schema.org/lido00170"
        xml:lang="en">
        Portrait of Lisa Gherardini
    </lido:appellationValue>
    <lido:sourceAppellation>
        Getty Vocabulary Program, CONA [online], Mona Lisa. URL: http://vocab.getty.edu/page/cona/700000213
    </lido:sourceAppellation>
</lido:titleSet>
<!-- Alternative title; published title -->
<lido:titleSet
    lido:type="http://vocab.getty.edu/aat/300417206"
    lido:pref="http://terminology.lido-schema.org/lido00170">
    <!-- Alternative appellation -->
    <lido:appellationValue
        lido:pref="http://terminology.lido-schema.org/lido00170"
        xml:lang="fr">
        PORTRAIT DE MONA LISA (1479-1528) ; DITE LA JOCONDE
    </lido:appellationValue>
    <lido:sourceAppellation>
        Collections des musées de France (Joconde), Portait de Mona Lisa. URL: https://www.pop.culture.gouv.fr/notice/joconde/000PE025604
    </lido:sourceAppellation>
</lido:titleSet>

See also Cataloging Cultural Objects: 1.2.2 Rules for Title, pp. 58–69.

5.1.5 Record Identifier

Element name: <lido:recordID>

Note: The Record Identifier element is a text string uniquely identifying the record in the contributor’s database or other recordkeeping system. It serves as a reference for all communication with the originator concerning the contents of the metadata record.

Example: The following example shows the local identifier for the record describing the “Mona Lisa” provided by Deutsches Dokumentationszentrum für Kunstgeschichte - Bildarchiv Foto Marburg.

Record Identifier: obj00076417 Type: Local identifier | Source: Deutsches Dokumentationszentrum für Kunstgeschichte - Bildarchiv Foto Marburg

<lido:recordID
    lido:source="Deutsches Dokumentationszentrum für Kunstgeschichte - Bildarchiv Foto Marburg"
    lido:type="http://terminology.lido-schema.org/lido00100">
    obj00076417
</lido:recordID>

5.1.6 Record Type

Element name: <lido:recordType>

Note: The Record Type element indicates the cataloging level selected for the record in question. It represents the logical tier of the <lido> object record, whether it refers to a single item, a part thereof, or a group of objects. Objects or works may be described at the following levels of granularity, as recommended in the LIDO Record Type Vocabulary:

• Item-level records describe one single object or work in a single LIDO record, e.g., an “Oil painting”; a description at item-level may also embrace parts of an object, e.g., a “Sèvres Bowl” comprising bowl, lid and dish.
• Group-level records describe more than one object in a single LIDO record, e.g., a “Collection of photographs”, a “Group of drawings”, or a “Tea service set”.
• Component-level records describe parts or components as distinct LIDO records. These records must be linked to the record for the whole, thus establishing a hierarchy of whole and parts; e.g., the “Dome” as a component of Saint Peter’s Basilica.
• Conceptual-level records are designated to collocate other records. This level allows introducing a record that is merely notional in nature, not describing any real object as an instance. Typical uses are assembling items of a multiple, or for series items under a common concept; e.g., “Great Wave off Kanagawa”.

Example: The following example refers to the cataloging level of an item. The values for the concept URI and the labels are drawn from the LIDO Record Type Vocabulary. If desired, a custom display label may be added manually.

Record Type: Item Preference: Display

<lido:recordType>
    <skos:Concept
        rdf:about="http://terminology.lido-schema.org/lido00141">
        <skos:prefLabel
            xml:lang="en">
            item-level record
        </skos:prefLabel>
        <skos:prefLabel
            xml:lang="de">
            Einzelobjekt
        </skos:prefLabel>
    </skos:Concept>
    <!-- Display label -->
    <lido:term
        lido:pref="http://terminology.lido-schema.org/lido00526"
        xml:lang="en">
        Item
    </lido:term>
</lido:recordType>

See also Categories for the Description of Works of Art: 1.1. Catalog Level in chapter 1. Object/Work.

5.1.7 Record Source

Element name: <lido:recordSource>

Note: The Record Source element holds identifying information on the source from which, or where the <lido> object record was created. The source is usually the repository, institution or person creating the record in question.

Example: The following example shows the source information for the record describing the “Mona Lisa” provided by Deutsches Dokumentationszentrum für Kunstgeschichte - Bildarchiv Foto Marburg.

Record Source: Deutsches Dokumentationszentrum für Kunstgeschichte - Bildarchiv Foto Marburg
Legal Body Identifier: https://ld.zdb-services.de/resource/organisations/DE-Mb112 Type: URI | Source: ISIL (ISO 15511)
Appellation Value: Deutsches Dokumentationszentrum für Kunstgeschichte - Bildarchiv Foto Marburg Preference: Preferred
Legal Body Weblink: https://www.uni-marburg.de/de/fotomarburg

<lido:recordSource>
    <!-- URI -->
    <lido:legalBodyID
        lido:type="http://terminology.lido-schema.org/lido00099"
        lido:source="ISIL (ISO 15511)">
        https://ld.zdb-services.de/resource/organisations/DE-Mb112
    </lido:legalBodyID>
    <lido:legalBodyName>
        <!-- Preferred label -->
        <lido:appellationValue
            lido:pref="http://terminology.lido-schema.org/lido00169"
            xml:lang="de">
            Deutsches Dokumentationszentrum für Kunstgeschichte - Bildarchiv Foto Marburg
        </lido:appellationValue>
        <lido:appellationValue
            lido:pref="http://terminology.lido-schema.org/lido00169"
            xml:lang="en">
            Foto Marburg Picture Archive
        </lido:appellationValue>
        <lido:sourceAppellation
            xml:lang="en">
            Philipps Universität Marburg. URL: https://www.uni-marburg.de/en/research/research-profile/academics_centres/academic-centers
        </lido:sourceAppellation>
    </lido:legalBodyName>
    <lido:legalBodyWeblink>
        https://www.uni-marburg.de/de/fotomarburg
    </lido:legalBodyWeblink>
</lido:recordSource>

5.1.8 Example: Mandatory elements

The following XML code snippet shows the use of the mandatory elements in the record describing the “Mona Lisa” provided by Deutsches Dokumentationszentrum für Kunstgeschichte - Bildarchiv Foto Marburg. Note that the value for the Object/Work Type is adapted to follow Cutter’s rule of using the most specific descriptor.

<lido:lido>
    <lido:lidoRecID
        lido:source="ld.zdb-services.de/resource/organisations/DE-Mb112"
        lido:type="http://terminology.lido-schema.org/lido00099">
        ld.zdb-services.de/resource/organisations/DE-Mb112/lido/obj/00076417
    </lido:lidoRecID>
    <lido:descriptiveMetadata xml:lang="en">
        <lido:objectClassificationWrap>
            <lido:objectWorkTypeWrap>
                <lido:objectWorkType>
                    <skos:Concept
                        rdf:about="http://vocab.getty.edu/aat/300033799">
                        <skos:prefLabel
                            xml:lang="en">
                            oil paintings (visual works)
                        </skos:prefLabel>
                    </skos:Concept>
                </lido:objectWorkType>
            </lido:objectWorkTypeWrap>
        </lido:objectClassificationWrap>
        <lido:objectIdentificationWrap>
            <lido:titleWrap>
                <lido:titleSet>
                    <lido:appellationValue
                        lido:pref="http://terminology.lido-schema.org/lido00169"
                        xml:lang="en">
                        Mona Lisa
                    </lido:appellationValue>
                </lido:titleSet>
            </lido:titleWrap>
        </lido:objectIdentificationWrap>
    </lido:descriptiveMetadata>
    <lido:administrativeMetadata
        xml:lang="en">
        <lido:recordWrap>
            <lido:recordID
                lido:source="ld.zdb-services.de/resource/organisations/DE-Mb112"
                lido:type="http://terminology.lido-schema.org/lido00100">
                obj00076417
            </lido:recordID>
            <lido:recordType>
                <skos:Concept
                    rdf:about="http://terminology.lido-schema.org/lido00141">
                    <skos:prefLabel
                        xml:lang="en">
                        Item-level record
                    </skos:prefLabel>
                </skos:Concept>
            </lido:recordType>
            <lido:recordSource>
                <lido:legalBodyID
                    lido:type="http://terminology.lido-schema.org/lido00099">
                    ld.zdb-services.de/resource/organisations/DE-Mb112
                </lido:legalBodyID>
                <lido:legalBodyName>
                    <lido:appellationValue
                        xml:lang="de">
                        Deutsches Dokumentationszentrum für Kunstgeschichte - Bildarchiv Foto Marburg
                    </lido:appellationValue>
                </lido:legalBodyName>
            </lido:recordSource>
        </lido:recordWrap>
    </lido:administrativeMetadata>
</lido:lido>

5.2 Recommended elements

5.2.1 Overview

The mandatory LIDO elements are sufficient to identify an object or work unambiguously, given that metadata elements are applied correctly. In most cases, however, providing the bare minimum of metadata will usually not be enough to enable good retrieval results in terms of findability and object discovery. Compared to LIDO, the CDWA standard defines some more elements as required, marked “core” in the CDWA Overview of Categories. These are, besides information on the creator and creation, particularly metadata for classification and subject matter.

Overview of mandatory and recommended elements in LIDO

Mandatory elements are

• LIDO Metadata Record Identifier
• Object/Work Type
• Title
• Record ID
• Record Type
• Record Source

It is strongly recommended to provide indexing terms for the following elements. These elements are further described below.

• Classification
• Measurements
• Materials/Techniques
• Event
• Subject
• Related Works

It is strongly recommended to provide information for Rights for Work, Rights for Record, and Rights Resource. For more information see section 4.4.2 Administrative Metadata“.

It is also recommended to provide information for the following elements:

• Inscriptions
• Repository
• Description
• Record Metadata
• Resource Representation

In addition to the mandatory and recommended elements above, data producers are encouraged to utilize further schema elements in the LIDO record based on the following considerations:

• the nature of the items being described;
• the availability of data in the organization’s collections management system;
• the requirements of the target portal.

5.2.2 Classification

Element name: <lido:classification>

Note: Classification assigns an object to one or more classes from a shared class scheme. Like <lido:objectWorkType>, the Classification element is used for grouping similar objects so that they can be retrieved in a single search operation. Unlike Object/WorkType which classifies the object at the most specific level suitable, the classification element aggregates objects on the basis of broad categories. For example, a work of type “oil painting” can be classified under “paintings”, a “bas-relief” would be assigned to a class “sculptures”, and a “cathedral” should be grouped into a category “architecture”.

Classes can be used to implement browsing facilities in digital environments. Examples are the Europeana Themes or the access to the Louvre collections entitled Explore the collections. Such categories may also give a first impression of what can be expected to be found in the database and thus serve as a useful starting point for discovery in a Web portal.

An object can be assigned several classification terms from different classification schemes, depending on the aspect or point of view. The schemes may vary in the division criteria used to arrange the classes, such as by period, location, or status of property. An example is the categorization of the Mona Lisa in Wikipedia under 16th-century portraits, Portrait paintings in the Louvre, and Stolen works of art.

Classification categories can refer to different aspects under which the object is viewed. Two common aspects are the genre or form represented by the object, reflecting its isness at a broad level, and the thematic context the object is related to, such as a “subject category” or a domain-specific grouping. For example, a farmhouse like the Olson House could be classified as a “building” by object genre and assigned to “agriculture” as subject category; for a religious building like the Holy Name of Jesus Cathedral the subject category might be “religion”. Drawings of plants may be categorized by theme “botanics”. These different aspects of categorization can be distinguished by using the lido:type attribute for <lido:classification>, for instance, “Object genre” or “Subject category”, provided by the LIDO Classification Type-Vocabulary. The usage of classification for natural objects or for special collection domains is subject to further development.

While suitable schemes for broad classification are widely used in the library community, none of these has yet been released as an open data resource as demanded the FAIR principles. This also applies to classification schemes proposed for the museum community. As long as an overarching classification system that is appropriate for cross-domain metadata aggregations is lacking, the LIDO classification element should be used according to the recommendations given in the CDWA guidelines.

Example: The following example refers to the Mona Lisa painting. In this particular case, classification is not very illuminating because there are no different aspects to consider. Nevertheless, it serves to illustrate the usage of different vocabularies for the different types of classification. The French term “peinture” is added here corresponding to the term being indexed and displayed displayed as “Category” in the Louvre record. The term “peinture” is used there to link to the search results for this index term in the “Louvre collections”. Note that the URI for the Dewey Class in the following XML code snippet does not resolve.

Classification: paintings (visual works) Type: Object genre Preference: Display
Classification: Painting and paintings Type: Subject category Preference: Preferred | Notation: 750

<lido:classificationWrap>
    <!-- Object genre -->
    <lido:classification
        lido:type="http://terminology.lido-schema.org/lido00853">
        <skos:Concept
            rdf:about="http://vocab.getty.edu/aat/300033618">
            <skos:prefLabel
                xml:lang="en">
                paintings (visual works)
            </skos:prefLabel>
            <skos:prefLabel
                xml:lang="de">
                Gemälde
            </skos:prefLabel>
            <skos:prefLabel
                xml:lang="fr">
                peintures (oeuvres visuelles)
            </skos:prefLabel>
        </skos:Concept>
        <lido:term
            lido:addedSearchTerm="yes"
            xml:lang="fr">
            peinture
        </lido:term>
        <!-- Display label -->
        <lido:term
            lido:pref="http://terminology.lido-schema.org/lido00526"
            xml:lang="fr">
            peinture
        </lido:term>
    </lido:classification>
    <!-- Subject category -->
        <lido:classification
            lido:type="http://terminology.lido-schema.org/lido00932">
        <!-- This URI does not resolve -->
            <skos:Concept
                rdf:about="http://dewey.info/class/750">
                <skos:prefLabel
                    xml:lang="en">
                    Painting and paintings
                </skos:prefLabel>
                <skos:prefLabel
                    xml:lang="de">
                    Malerei und Gemälde
                </skos:prefLabel>
            <skos:notation>750</skos:notation>
        </skos:Concept>
    </lido:classification>
</lido:classificationWrap>

5.2.3 Measurements

Element name: <lido:measurementsSet>

Note: Measurements Set contains information about the dimensions of the object, comprising the measurement type, such as height or width, the corresponding unit, and the measured value. LIDO provides two elements: <lido:objectMeasurementsSet> is used to catalog the dimensions of the object at hand, whereas <lido:eventObjectMeasurements> refers to the measurements with respect to the event in focus, for instance, the decreased dimensions after the removal of a part.

Example: The following example describes the dimensions of the Mona Lisa in the Louvre. The Measurements Set for “width” is omitted in the XML snippet for brevity. Added is information on the extent, i.e., the part of the object to which the dimensions apply, here the wood panel. Also added is the shape of the panel.

Display Object Measurements: Height x width: 0.79 x 0.53 m
Type: height Unit: meter Value: 0.79
Type: width Unit: meter Value: 0.53
Extent Measurements: wood panel
Shape Measurements: rectangular

<lido:objectMeasurementsSet>
    <lido:displayObjectMeasurements
        xml:lang="en">
        Height x width: 0.79 x 0.53 m
    </lido:displayObjectMeasurements>
    <lido:objectMeasurements>
        <lido:measurementsSet>
            <lido:measurementType>
                <skos:Concept
                    rdf:about="http://www.wikidata.org/wiki/Q208826">
                    <skos:prefLabel
                        xml:lang="en">
                        height
                    </skos:prefLabel>
                </skos:Concept>
                </lido:measurementType>
            <lido:measurementUnit>
                <skos:Concept
                    rdf:about="http://www.wikidata.org/wiki/Q11573">
                    <skos:prefLabel
                        xml:lang="en">
                        meter
                    </skos:prefLabel>
                </skos:Concept>
            </lido:measurementUnit>
            <lido:measurementValue>
                0.79
            </lido:measurementValue>
        </lido:measurementsSet>
        <lido:extentMeasurements>
            <skos:Concept
                rdf:about="http://vocab.getty.edu/aat/300014657">
                <skos:prefLabel
                    xml:lang="en">
                    panel (wood by form)
                </skos:prefLabel>
                <skos:altLabel
                    xml:lang="en">
                    wood panel
                </skos:altLabel>
            </skos:Concept>
        </lido:extentMeasurements>
        <lido:shapeMeasurements>
            <skos:Concept
                rdf:about="http://vocab.getty.edu/aat/300263831">
                <skos:prefLabel
                    xml:lang="en">
                    rectangular
                </skos:prefLabel>
            </skos:Concept>
        </lido:shapeMeasurements>
    </lido:objectMeasurements>
</lido:objectMeasurementsSet>

5.2.4 Materials/Techniques

Element name: <lido:materialsTech>

Note: Materials/Techniques contains information about the substances, such as the medium or support, and the techniques or implements, either incorporated in the object in focus, or used in the production or modification of the object. LIDO provides two elements, <lido:objectMaterialsTechSet> and <lido:eventMaterialsTech>, to catalog materials and techniques either as found in the object, or as used in the context of an event, respectively.

Example: The following example describes materials and techniques found in the Mona Lisa painting. The <lido:extentMaterialsTech> element is applied to describe the part of the painting where a certain technique was utilized.

Display Materials/Techniques: Oil on poplar panel
Materials/Techniques: oil paint Type: Medium Preference: Display
Materials/Techniques: poplar wood Type: Support Preference: Display
Materials/Techniques: panel painting Type: Technique Preference: Display
Materials/Techniques: sfumato Type: Technique Preference: Display | Extent: landscape Preference: Display

<lido:objectMaterialsTechSet>
    <lido:displayMaterialsTech
        xml:lang="en">
        Oil on poplar panel
    </lido:displayMaterialsTech>
    <lido:materialsTech>
        <!-- Medium -->
        <lido:termMaterialsTech
            lido:type="http://terminology.lido-schema.org/lido00513">
            <skos:Concept
                rdf:about="http://vocab.getty.edu/aat/300015050">
                <skos:prefLabel
                    xml:lang="en">
                    oil paint (paint)
                </skos:prefLabel>
            </skos:Concept>
            <lido:term
                lido:addedSearchTerm="yes"
                xml:lang="de">
                Ölfarbe
            </lido:term>
            <!-- Display label -->
            <lido:term
                lido:pref="http://terminology.lido-schema.org/lido00526"
                xml:lang="en">
                oil paint
            </lido:term>
        </lido:termMaterialsTech>
        <!-- Support -->
        <lido:termMaterialsTech
            lido:type="http://terminology.lido-schema.org/lido00514">
            <skos:Concept
                rdf:about="http://vocab.getty.edu/aat/300012363">
                <skos:prefLabel
                    xml:lang="en">
                    poplar (wood)
                </skos:prefLabel>
            </skos:Concept>
            <!--Display label -->
            <lido:term
                lido:pref="http://terminology.lido-schema.org/lido00526"
                xml:lang="en">
                poplar wood
            </lido:term>
        </lido:termMaterialsTech>
        <!-- Technique -->
        <lido:termMaterialsTech
            lido:type="http://terminology.lido-schema.org/lido00131">
            <skos:Concept
                rdf:about="http://vocab.getty.edu/aat/300178675">
                <skos:prefLabel
                    xml:lang="en">
                    panel painting (image-making)
                </skos:prefLabel>
            </skos:Concept>
            <!-- Display label -->
            <lido:term
                lido:pref="http://terminology.lido-schema.org/lido00526"
                xml:lang="en">
                panel painting
            </lido:term>
        </lido:termMaterialsTech>
    </lido:materialsTech>
    <lido:materialsTech>
        <!-- Technique -->
        <lido:termMaterialsTech
            lido:type="http://terminology.lido-schema.org/lido00131">
            <skos:Concept
                rdf:about="http://vocab.getty.edu/aat/300053421">
                <skos:prefLabel
                    xml:lang="en">
                    sfumato
                </skos:prefLabel>
            </skos:Concept>
            <!-- Display label -->
            <lido:term
                lido:pref="http://terminology.lido-schema.org/lido00526"
                xml:lang="en">
                sfumato
            </lido:term>
        </lido:termMaterialsTech>
        <lido:extentMaterialsTech>
            <skos:Concept
                rdf:about="http://vocab.getty.edu/aat/300008626">
                <skos:prefLabel
                    xml:lang="en">
                    landscapes (environments)
                </skos:prefLabel>
            </skos:Concept>
            <!-- Display label -->
            <lido:term
                lido:pref="http://terminology.lido-schema.org/lido00526"
                xml:lang="en">
                landscape
            </lido:term>
        </lido:extentMaterialsTech>
    </lido:materialsTech>
</lido:objectMaterialsTechSet>

5.2.5 Event

Element name: <lido:event>

Note: Event contains information about occurences associated with the object in some way. The element is meant to be used in the following contexts, to refer to - an event the object participated in or was present at, e.g., its production, modification, or provenance as a series of events, to be recorded in <lido:eventSet>.

• an event that is related to the event in focus, e.g., the so-called “Benin Expedition” as associated with the taking of the “Benin Bronzes”, to be recorded in <lido:relatedEventSet>;
• an event that is a topic of the object in focus, e.g., the “Coronation of Maria de Medici” as a theme in Rubens’ painting “The death and apothesis of Henry IV”, to be recorded in <lido:subjectEventSet>.

It is recommended to catalog a production event for human-made objects as a minimum. For natural objects, the equivalent should be the collection event. If the creator or producer of a human-made object is not identified, the value “unknown” from the Union List of Artist Names (ULAN) authority may be used as a value. If known or applicable, the cultural context for the object should be indexed.

5.2.5.1 Event Type

Element name: <lido:eventType>

Note: Event Type indicates the kind of an event, whether it is, e.g., the production, acquisition, or use of an object in its lifecycle. Terms for these types are provided by the LIDO Terminology or by application profiles. For related events, and events as subjects of a work, the term for Event Type should be drawn from external authorities.

This element is required if <lido:event> is set.

Terms for Event Type in the object’s lifecycle (<lido:eventSet>) are provided by the LIDO Event Type Vocabulary. If terms of the Event Type Terminology are not sufficient for a specific use case concerning the object’s lifecycle, compatible vocabulary recommendations may be provided within an application profile. Such recommendations should ideally extend the LIDO Event Type vocabulary.

Terms for <lido:relatedEvent> and <lido:subjectEvent> should be drawn from external authorities. For suggestions see the LIDO Terminology Recommendation.

Example: The following example describes the production of the Mona Lisa as the most notable event. The Event Type is indexed with the concept “Production” from the LIDO Terminology. The mapping relation to the AAT descriptor is provided by the LIDO Term.

Event: Painted by Leonardo da Vinci, probably between 1503/1519
Event Type: Production Preference: Preferred

<lido:eventSet
    lido:sortorder="2"
    lido:mostNotableEvent="1">
    <lido:displayEvent
        xml:lang="en">
        Painted by Leonardo da Vinci, probably between 1503/1519
    </lido:displayEvent>
    <lido:event>
        <lido:eventType>
            <skos:Concept
                rdf:about="http://terminology.lido-schema.org/lido00007">
                <skos:prefLabel
                    xml:lang="en">
                    Production
                </skos:prefLabel>
            </skos:Concept>
        </lido:eventType>
    </lido:event>
</lido:eventSet>

5.2.5.2 Event Actor

Element name: <lido:eventActor>

Note: Event Actor contains information about the person or organization involved in the event in focus, including identifying data, names, roles, and possibly biographical details.

Example: The following example describes Leonardo da Vinci in the role of painter. The reference to the painting of the Mona Lisa is provided by the parent element <lido:eventSet> with the Event Type “Production”.

Actor: Painter: Leonardo da Vinci (1452–1519)
Name Actor: Leonardo, da Vinci Preference: Preferred • Leonardo da Vinci Preference: Display
Role Actor: painter Preference: Display

<lido:eventActor>
    <lido:displayActorInRole
        xml:lang="en">
        Painter: Leonardo da Vinci (1452–1519)
    </lido:displayActorInRole>
    <lido:actorInRole>
        <lido:actor
            lido:type="http://terminology.lido-schema.org/lido00413">
            <lido:actorID
                lido:type="http://terminology.lido-schema.org/lido00099">
                http://viaf.org/viaf/24604287
            </lido:actorID>
            <lido:nameActorSet>
                <!-- Preferred name -->
                <lido:appellationValue
                    lido:pref="http://terminology.lido-schema.org/lido00169"
                    xml:lang="en">
                    Leonardo, da Vinci
                </lido:appellationValue>
                <!-- Display name -->
                <lido:appellationValue
                    lido:pref="http://terminology.lido-schema.org/lido00526"
                    xml:lang="en">
                    Leonardo da Vinci
                </lido:appellationValue>
            </lido:nameActorSet>
        </lido:actor>
        <lido:roleActor>
            <skos:Concept
                rdf:about="http://vocab.getty.edu/aat/300025136">
                <skos:prefLabel
                    xml:lang="en">
                    painters (artists)
                </skos:prefLabel>
                <skos:prefLabel
                    xml:lang="de">
                    Maler
                </skos:prefLabel>
            </skos:Concept>
            <!-- Display label -->
            <lido:term
                lido:pref="http://terminology.lido-schema.org/lido00526"
                xml:lang="en">
                painter
            </lido:term>
            <lido:term
                lido:pref="http://terminology.lido-schema.org/lido00526"
                xml:lang="de">
                Maler
            </lido:term>
        </lido:roleActor>
    </lido:actorInRole>
</lido:eventActor>

5.2.5.3 Event Place

Element name: <lido:eventPlace>

Note: Event Place contains information about the place where the event occured, including identifying data, names and possibly coordinates. The type of place, whether it is an adminstrative entity such as a city or country, or a physical feature such as a river or a mountain, can be captured in detail using the <lido:placeClassification> element.

Example: The following example describes the city “Florence” as a possible place of production of the Mona Lisa. The reference to the painting is provided by the <lido:eventSet> element with the Event Type “Production”. The place type “city” is expressed by the attribute lido:politicalEntity, and the URI for “city” is taken from Wikidata.

Event Place: Florence between 1502/1506 Political Entity: City
Name Place: Florence Preference: Preferred
Coordinates: 43.771389, 11.254167

<lido:eventPlace>
    <lido:displayPlace
        xml:lang="en">
        Possibly Florence, between 1502/1506
    </lido:displayPlace>
    <!-- City -->
    <lido:place
        lido:politicalEntity="http://www.wikidata.org/entity/Q515">
        <lido:placeID
            lido:type="http://terminology.lido-schema.org/lido00099">
            http://www.wikidata.org/entity/Q2044
        </lido:placeID>
        <lido:namePlaceSet>
            <!-- Preferred label -->
            <lido:appellationValue
                lido:pref="http://terminology.lido-schema.org/lido00169"
                xml:lang="en">
                Florence
            </lido:appellationValue>
        </lido:namePlaceSet>
        <lido:gml>
            <gml:Point>
                <gml:pos>43.771389, 11.254167</gml:pos>
            </gml:Point>
        </lido:gml>
    </lido:place>
</lido:eventPlace>

5.2.5.4 Event Date

Element name: <lido:eventDate>

Note: Event Date contains information about the date or timespan when the event took place. The dates are expressed in the elements <lido:earliestDate> and <lido:latestDate>, both of which are required. If earliest and latest date concur, the date is given twice. Example: The following example describes the estimated timespan for the production of the Mona Lisa. The reference to the painting is provided by the parent element <lido:eventSet> with the Event Type “Production”.

Event Date: Between 1506/1519
Earliest Date: 1506 Type: Estimated date
Latest Date: 1519 Type: Estimated date

<lido:eventDate>
    <lido:displayDate xml:lang="en">
        Between 1506/1519
    </lido:displayDate>
    <lido:date>
        <!-- Estimated date -->
        <lido:earliestDate
            lido:type="http://terminology.lido-schema.org/lido00529">
            1503
        </lido:earliestDate>
        <lido:latestDate
            lido:type="http://terminology.lido-schema.org/lido00529">
            1519
        </lido:latestDate>
    </lido:date>
</lido:eventDate>

5.2.6 Related Work

Element name: <lido:relatedWork>

Note: Related Work contains information about an object that is directly associated with the object in focus. An extensive list of such relationships can be found in the LIDO Terminology for Relationship Type. Examples are preparatory and derivative relationhips, or associations between companion pieces. However, there is no general answer to whether or not a work should be linked as associated. The decision will depend on how the benefits in retrieval are estimated. Will retrieving both objects at one go be meaningful to users? Or will the relation of the objects lead to a deluge of unwanted search results? These questions should be weighed when establishing an associative relation between works.

Example: The following example describes the ready made “L.H.O.O.Q” by Marcel Duchamp as a related work to Leonardo’s Mona Lisa. Although these works are not directly associated, they are contextually connected in such a way that users may want to become aware of both in one search session.

Related Work: Marcel Duchamp, L.H.O.O.Q., Ready-made 1919
Note: L.H.O.O.Q; photographic reproduction; Marcel Duchamp; 1919; Israel Museum
Relationship Type: is reproduction of

<lido:relatedWorkSet
    lido:sortorder="3">
    <lido:displayRelatedWork
        xml:lang="en">
        Marcel Duchamp, L.H.O.O.Q., Ready-made 1919
    </lido:displayRelatedWork>
    <lido:relatedWork>
        <lido:object>
            <lido:objectWebResource
                lido:formatResource="text/html"
                xml:lang="en">
                https://www.imj.org.il/en/collections/199796-0
            </lido:objectWebResource>
            <lido:objectID
                lido:type="http://terminology.lido-schema.org/lido00099"
                lido:source="Israel Museum, Jerusalem">
                B99.0575
            </lido:objectID>
            <lido:objectNote
                xml:lang="en">
                L.H.O.O.Q; photographic reproduction; Marcel Duchamp; 1919; Israel Museum
            </lido:objectNote>
        </lido:object>
    </lido:relatedWork>
    <lido:relatedWorkRelType>
        <skos:Concept
            rdf:about="http://terminology.lido-schema.org/lido00607">
            <skos:prefLabel
                xml:lang="en">
                is reproduction of
            </skos:prefLabel>
        </skos:Concept>
    </lido:relatedWorkRelType>
</lido:relatedWorkSet>

5.2.7 Subject

Element name: <lido:subject>

Note: Subject contains information about what is shown in an object or what is a theme of the work in focus. Indexing subject matter is strongly recommended, since it is a primary access point in retrieval, and users quite often perform topical searches. Subject may occur as depicted items, themes, or narrative content, and refers to abstract concepts and equally refers to abstract concepts and named entities.

Terms designating a generic notion are indexed in <lido:subjectConcept>. Examples for concepts in the role of subject may be perceivable things, such as bridges or bicycles, or abstract ideas, like love or fear. In the context of works of art, what is depicted is referred to as the ofness of an object, e.g., a sitting woman, a landscape, an armrest. For this kind of subject, the type is “Description”. Beyond this, cultural objects most often have content calling for interpretation, e.g., when a picture conveys allegorical meaning or relates to a mythological narrative. This kind of knowledgeable information is called the aboutness of an object. Here, the type of subject is “Interpretation”. In the library context aboutness refers to the totality of subjects explicitly or implicitly addressed in the text of a document. Note that indexing values for <lido:subjectConcept> drawn from Iconclass are of type “Iconclass notation”.

Content referring to named entities, such as a certain person or a particular place, is indexed in distinct LIDO elements: <lido:subjectActor> for individual persons or organizations, whether alive or historical, <lido:subjectDate> for date values,<lido:subjectEvent> for named historical events, <lido:subjectPlace> for real places, and <lido:subjectObject> for a named object that is shown or described in or by the object at hand. Please note, that named objects comprise not only material objects, but also immaterial ones, that are documented as single units or serve as topic of discourse. These include fictitious actors, fictitious places and fictitious events, for instance, from legends, religion, mythology, or literature and performing arts. They are all indexed as <lido:subjectObject>.

The subject type for named entities is “Identification”. Note that indexing values from Iconclass belong to a type of its own, labelled “Iconclass notation”.

The usage of subject for, e.g., natural objects, buildings, or utilitarian items, should be specifically elaborated for respective areas of collection. In the following element descriptions, <lido:subjectDate> is omitted since the value recommendations are the same as for <lido:date> in general.

5.2.7.1 Type of Subject

The type of <lido:subject>, also called “indexing type”, indicates whether the indexing term is an impartial description of what is depicted, a more subjective interpretation of the topic, or an identification of a named entity. The following types are the most common ones:

• Description relates to the ofness of an object. It states what the depicted content is.
• Interpretation relates to the aboutness of an object, stating what the thematic, iconographical, or symbolic meaning is.
• Identification relates to named individuals that the object at hand is of or about.
• Iconclass notation is used for all subjects, whether concepts or named entities, that are indexed with an Iconclass notation.

For subject types see terms in the LIDO Subject Type-Vocabulary.

5.2.7.2 Subject Concept

Element name: <lido:subjectConcept>

Note: Subject Concept contains generic concepts describing what the object depicts or what it is about.

Example for “Description”: The following example refers to a term used as subject for Leonardo’s painting in the EDM Primer, showing the possible inference of broader concepts when using controlled structured vocabularies (see Fig. 9 Mona Lisa – enriched using contextual entities, page 15). In the example below, it is concluded from the Wikidata subclass relation for “woman” that a woman is a “female human” which in turn is a “human”. Subject type is “Description” because the indexing term refers to what can be seen in the picture by a non-expert.

Subject Concept: woman Preference: Display
Subject Type: Description

<lido:subjectSet>
  <!-- Description -->
    <lido:subject
        lido:type="http://terminology.lido-schema.org/lido00525">
        <lido:subjectConcept>
            <skos:Concept
                rdf:about="http://www.wikidata.org/entity/Q467">
                <skos:prefLabel
                    xml:lang="en">
                    women (human females)
                </skos:prefLabel>
            </skos:Concept>
            <!-- Display label -->
            <lido:term
                lido:pref="http://terminology.lido-schema.org/lido00526"
                xml:lang="en">
                woman
            </lido:term>
        </lido:subjectConcept>
    </lido:subject>
</lido:subjectSet>

Example for “Extent”: Here, the part of the painting to which the indexing term “landscape” refers is recorded as “background” in <lido:extentSubject>. Since the landscape is only a secondary theme in this painting, search portals may use this information for ranking, or for explaining the connection in the keyword display.

Subject Concept: landscape Preference: Display
Subject Type: Description
Extent: background

<lido:subjectSet>
    <!-- Description -->
    <lido:subject
        lido:type="http://terminology.lido-schema.org/lido00525">
        <lido:extentSubject>
            <skos:Concept
                rdf:about="http://vocab.getty.edu/aat/300056369">
                <skos:prefLabel
                    xml:lang="en">
                    background
                </skos:prefLabel>
            </skos:Concept>
        </lido:extentSubject>
        <lido:subjectConcept>
            <skos:Concept
                rdf:about="http://vocab.getty.edu/aat/300008626">
                <skos:prefLabel
                    xml:lang="en">
                    landscapes (environments)
                </skos:prefLabel>
            </skos:Concept>
            <!-- Display label -->
            <lido:term
                lido:pref="http://terminology.lido-schema.org/lido00526"
                xml:lang="en">
                landscape
            </lido:term>
        </lido:subjectConcept>
    </lido:subject>
<lido:subjectSet>

Example for “Interpretation”: The following is an example for subject type “Interpretation”. Even though in this example the smile of the depicted person is immediately evident, a statement about a facial expression is still a subjective judgement and thus an interpretation.

Subject Concept: smile Preference: Display
Subject Type: Interpretation

<lido:subjectSet>
    <!-- Interpretation -->
    <lido:subject
        lido:type="http://terminology.lido-schema.org/lido00524">
        <lido:subjectConcept>
            <skos:Concept
                rdf:about="http://vocab.getty.edu/aat/300417502">
                <skos:prefLabel
                    xml:lang="en">
                    smiling
                </skos:prefLabel>
            </skos:Concept>
            <!-- Display label-->
            <lido:term
                lido:pref="http://terminology.lido-schema.org/lido00526"
                xml:lang="en">
                smile
            </lido:term>
        </lido:subjectConcept>
    </lido:subject>
 </lido:subjectSet>

5.2.7.3 Subject Actor

Element name: <lido:subjectActor>

Note: Subject Actor contains information about a person or a group of persons, depicted in or addressed by an object. Fictitious actors are indexed as <lido:subjectObject>.

Example: The following example describes Lisa del Giocondo as the person portrayed in Leonardo’s Mona Lisa. Here, the attributes “Index label” and “Display label” from the LIDO Preference Vocabulary for <lido:term> are used to govern how the labels are to be processed. The subject type is “Identification”.

Subject Actor: Sitter: Lisa del Giocondo (1479–1542) Type: Person
Subject Type: Identification
Name Actor: Del Giocondo, Lisa Preference: Index
• Lisa del Giocondo Preference: Display

<lido:subjectSet>
    <!-- Identification -->
    <lido:subject
        lido:type="http://terminology.lido-schema.org/lido00136">
        <lido:subjectActor>
            <lido:displayActor
                xml:lang="en">
                Sitter: Lisa del Giocondo (1479–1542)
            </lido:displayActor>
                <!-- Person -->
                <lido:actor
                    lido:type="http://terminology.lido-schema.org/lido00163">
                <lido:actorID
                    lido:type="http://terminology.lido-schema.org/lido00099">
                    http://viaf.org/viaf/50517148
                </lido:actorID>
                <lido:nameActorSet>
                    <!-- Index name -->
                    <lido:appellationValue
                        lido:pref="http://terminology.lido-schema.org/lido00961"
                        xml:lang="en">
                        Del Giocondo, Lisa
                    </lido:appellationValue>
                    <!-- Display name -->
                    <lido:appellationValue
                        lido:pref="http://terminology.lido-schema.org/lido00526"
                        xml:lang="en">
                        Lisa del Giocondo
                    </lido:appellationValue>
                </lido:nameActorSet>
            </lido:actor>
        </lido:subjectActor>
    </lido:subject>
</lido:subjectSet>

5.2.7.4 Subject Event

Element name: <lido:subjectEvent>

Note: Subject Event contains information about a particular event the object depicts or is about. Iconographical narratives and fictitious events are indexed as <lido:subjectObject>.

Example: Since there is no event as a topic in Leonardo’s Mona Lisa, a Punch cartoon has been chosen as an example instead, addressing the theft of the Mona Lisa from the Louvre in 1911. The values for the preferred labels in English, German, and French are drawn from Wikidata. Note that the LIDO Event Type Terminology does not provide terms for <lido:subjectEvent>. Rather, the event type should be drawn from an external vocabulary. Many authority files provide a generic concept as a broader term for named events that may be used as values for <lido:eventType>. In the following snippet, a superclass for the “theft of Mona Lisa” from Wikidata is used. The subject type is “Identification”.

Subject Event: Theft of Mona Lisa
Subject Type: Identification
Event Type: theft Preference: Preferred

<lido:subjectSet>
    <!-- Identification -->
    <lido:subject
        lido:type="http://terminology.lido-schema.org/lido00136">
        <lido:subjectEvent>
            <lido:displayEvent
                xml:lang="en">
                Theft of Mona Lisa
            </lido:displayEvent>
            <lido:event>
                <lido:eventID
                    lido:type="http://terminology.lido-schema.org/lido00099">
                    http://www.wikidata.org/entity/Q61266859
                </lido:eventID>
                <lido:eventType>
                    <skos:Concept
                        rdf:about="http://www.wikidata.org/entity/Q2727213">
                        <skos:prefLabel
                            xml:lang="en">
                            theft
                        </skos:prefLabel>
                    </skos:Concept>
                </lido:eventType>
            </lido:event>
        </lido:subjectEvent>
    </lido:subject>
</lido:subjectSet>

5.2.7.5 Subject Place

Element name: <lido:subjectPlace>

Note: Subject Place contains information about a particular place the object depicts or is about. Fictitious places are indexed as <lido:subjectObject>

Example: The place depicted in Leonardo’s Mona Lisa is possibly Bobbio in the Province of Piacenza. Coordinates are taken from Wikidata. The subject type is “Identification”.

Subject Place: Possibly Bobbio in the Province of Piacenza
Subject Type: Identification
Place Name: Bobbio Preference: Preferred Coordinates: 44.7715, 9.3864

<lido:subjectSet>
    <!-- Identification -->
    <lido:subject
        lido:type="http://terminology.lido-schema.org/lido00136">
        <lido:subjectPlace>
            <lido:displayPlace
                xml:lang="en">
                Possibly Bobbio in the Province of Piacenza
            </lido:displayPlace>
            <lido:place>
                <lido:placeID
                    lido:type="http://terminology.lido-schema.org/lido00099">
                    http://www.wikidata.org/entity/Q11498
                </lido:placeID>
                <lido:namePlaceSet>
                <!-- Preferred name -->
                <lido:appellationValue
                    lido:pref="http://terminology.lido-schema.org/lido00169">
                    Bobbio
                </lido:appellationValue>
                <lido:sourceAppellation
                    xml:lang="en">
                    Glori, Carla. Il paesaggio della Gioconda illustrato. 2022/06/09. URL: https://www.researchgate.net/publication/361190634_Il_paesaggio_della_Gioconda_illustrato [2022-11-08]
                </lido:sourceAppellation>
                </lido:namePlaceSet>
                <lido:gml>
                    <gml:Point>
                        <gml:pos>
                            44.7715, 9.3864
                        </gml:pos>
                    </gml:Point>
                </lido:gml>
            </lido:place>
        </lido:subjectPlace>
    </lido:subject>
</lido:subjectSet>

5.2.7.6 Subject Object

Element name: <lido:subjectObject>

Note: Subject Object contains information about a particular object depicted in, or referred to, by the object in focus. Fictitious actors, fictitious places, iconographical narratives and fictitious events are indexed as Subject Object as well.

Example: Since there is no object as a topic in Leonardo’s Mona Lisa, a photograph depicting the painting when it was exhibited in the Uffizi 1913 has been chosen as an example instead. The subject type is “Identification”.

Subject Object: Mona Lisa
Subject Type: Identification

<lido:subjectSet>
    <!-- Identification -->
    <lido:subject
        lido:type="http://terminology.lido-schema.org/lido00136">
        <lido:subjectObject>
            <lido:displayObject
                xml:lang="en">
                Mona Lisa
            </lido:displayObject>
            <lido:object>
                <lido:objectID
                    lido:type="http://terminology.lido-schema.org/lido00099">
                    https://collections.louvre.fr/en/ark:/53355/cl010062370
                </lido:objectID>
                <lido:objectNote
                    xml:lang="en">
                    Photograph of the painting exhibited in the Uffizi 1913
                </lido:objectNote>
            </lido:object>
        </lido:subjectObject>
    </lido:subject>
</lido:subjectSet>

For more information on subject indexing see Getty Vocabulary Program, CONA Editorial Rules, Chapter 3.6.3 Depicted Subject, Iconography Authority.

5.3 Elements from other namespaces

LIDO “borrows” some definitions from other schemas, following the principle that useful data types and elements defined elsewhere should be reused instead of redefined. All schemas are identified by namespace prefixes which must be declared using the xmlns Attribute, preferably on the outermost element of a LIDO record.

<?xml version="1.0" encoding="UTF-8"?>
<lido:lido
    xsi:schemaLocation="http://www.lido-schema.org http://lido-schema.org/schema/v1.1/lido-v1.1.xsd"
    xmlns:lido="http://www.lido-schema.org"
    xmlns:gml="http://www.opengis.net/gml"
    xmlns:owl="http://www.w3.org/2002/07/owl#"
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:skos="http://www.w3.org/2004/02/skos/core#"
    xmlns:xml="http://www.w3.org/XML/1998/namespace"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

5.3.1 Geographic locations (gml)

Namespace: http://www.opengis.net/gml

Origin: Open Geospatial Consortium (OGC)

Elements used: gml:Point, gml:LineString, gml:Polygon

GML is a huge XML schema widely used in geographic information system (GIS) applications. LIDO reuses three elements from GML for representing location coordinates wrapped up in the <lido:gml> element. <lido:gml> is available in all LIDO elements derived from lido:placeComplexType. These are:

• lido:partOfPlace
• lido:place
• lido:repositoryLocation
• lido:vitalPlaceActor

The <lido:gml> element is structured as follows:

All three GML elements can have an attribute, srsName, for the spatial reference system (SRS) to which the coordinate values apply. If the srsName attribute is omitted, then the World Geodetic System 1984 (WGS 84, also known as EPSG 4326) coordinate system is assumed. Thus the srsName attribute is only required in the rare case where a location given in historical coordinates has not been translated to WGS 84.

The most common GML sub-element will be gml:point for a single coordinate pair. Here, coordinates are written as decimal degrees with negative values for western and southern hemispheres, respectively. The format is latitude, followed by a space, followed by longitude. For example, <gml:pos>-34.6 -58.38</gml:pos> is the approximate location of Buenos Aires, Argentina, and <gml:pos>43.78 11.25</gml:pos> encodes the location Florence, Italy.

Validating parsers will check the syntax of all GML elements within a LIDO record using the GML XML schema included via an xs:import directive.

5.3.2 Concepts (skos)

Namespace: http://www.w3.org/2004/02/skos/core#

Origin: W3C Semantic Web Deployment Working Group

Element used: skos:Concept

The Simple Knowledge Organization System (SKOS) is a data model for representing controlled vocabularies in the Resource Description Framework (RDF). SKOS has evolved to the de-facto standard for authority data in the Linked Data sphere. Many important controlled vocabularies are published in SKOS, for instance, the Art & Architecture Thesaurus (AAT) or the Library of Congress Subject Headings (LCSH).

The SKOS class <skos:Concept> is introduced in LIDO v1.1 to represent LOD vocabularies. All LIDO elements for which a <[lido:conceptID]> element is defined, can preferably use the SKOS class <skos:Concept> together with allowed SKOS properties of this class represented in RDF/XML syntax.

Following this syntax, <skos:Concept> becomes an XML element with the attribute ‘rdf:about’ for the URI of the Linked Data resource to be referenced. In its most basic form, <skos:Concept> could be used as follows in LIDO v1.1, referencing the AAT concept ‘oil paintings’:

<skos:Concept rdf:about="http://vocab.getty.edu/aat/300033799"/>

which is equivalent to

<lido:conceptID
    type="http://terminology.lido-schema.org/lido00099">
    http://vocab.getty.edu/aat/300033799
</lido:conceptID>

The advantage of using <skos:Concept> instead of <lido:conceptID> becomes evident when further information from or about the Linked Data resource is added to the concept reference, for example:

<skos:Concept
    rdf:about="http://vocab.getty.edu/aat/300033656">
    <skos:prefLabel
        xml:lang="en">
        panel paintings
    </skos:prefLabel>
    <skos:prefLabel
        xml:lang="de">
        Tafelbild (Gemälde)
    </skos:prefLabel>
    <skos:mappingRelation>
        http://www.wikidata.org/entity/Q55439
    </skos:mappingRelation>
    <skos:mappingRelation>
        https://d-nb.info/gnd/4037220-0
    </skos:mappingRelation>
</skos:Concept>

This gives users and consumers of the LIDO record several clues as to how the concept can be represented in a search index or in a multilingual display, and where contextual information can be obtained from other Linked Data sources. Moreover, when the object at hand is described with several concepts from different vocabularies using <lido:conceptID>, then it is impossible to tell if two or more identifiers relate to similar concepts and which term relates to which identifier. Using a mapping relation from SKOS prevents such possible confusion. In the example above, the concept URIs from Wikidata and GND are explicitly stated as equivalent to the AAT concept. This greatly facilitates the alignment of indexing vocabulary in cases where an aggregator receives LIDO records using different preferred vocabularies. Using SKOS label properties also obviates the need for <lido:term> elements in cases where portals or aggregators are not prepared to collect term data from Linked Data URIs.

Usually, such augmented SKOS concept statements will not be constructed manually, but by software components that produce LIDO records. <lido:conceptID> is still appropriate for indexing terms with local identifiers from vocabularies not published as LOD.

The LIDO XML schema only demands that no other foreign namespace besides SKOS is used within a concept element (i.e., one that is derived from conceptComplexType and conceptMixedComplexType). Proper usage of the SKOS namespace must therefore be checked using the given Schematron rules or equivalent tools.

For more detailed information about the usage of <skos:Concept> and allowed properties, see 4.2.3 Display and index elements in this document.

5.3.3 Individuals (owl)

Namespace: http://www.w3.org/2002/07/owl#

Origin: W3C OWL Working Group

Element used: owl:sameAs

Individual entities such as persons, organizations, places, objects or named events can be described in more than one authority file, meaning that there can be more than one URI for referencing such an entity. When the content of LIDO records is processed or presented to users, it can be useful to choose among alternative Linked Data sources or to collect complementary information from several sources.

The Web Ontology Language (OWL) defines a property, ‘owl:sameAs’, for stating that two identifiers refer to the same individual in the real world. LIDO, from version 1.1, adopts the <owl:sameAs> statement for use in elements defined by the following complex types in LIDO:

• actor
• event
• legal body
• object
• place

As with the SKOS namespace described above, the OWL namespace identifies an RDF data model. ‘owl:sameAs’ is therefore an RDF property represented in XML using RDF/XML syntax. The LIDO schema only demands that identity statements in the above elements are from the OWL namespace. Proper use of this namespace (i.e., only the <owl:sameAs> property is permitted in LIDO and it can only contain a URI) must therefore be checked using the given Schematron rules or equivalent tools.

5.4 Attributes

Many LIDO elements can be provided with attributes. An attribute is an XML construct used for qualifying or typifying the contents of an element. The LIDO schema determines which elements can have attributes and which attribute (or attributes) an element is permitted or required to hold. Each attribute appears as a pair of attribute name and attribute value (known as a key-value pair). Many attributes are used for several different elements in LIDO. For many of the LIDO attributes there are recommended value lists provided by the LIDO Terminology. This particularly applies to the lido:type attribute.

Fourteen attributes are defined in the LIDO Schema Version 1.1 namespace. In addition, the language attribute xml:lang from the XML namespace can be used for all text elements and is mandatory for the elements <lido:administrativeMetadata> and <lido:descriptiveMetadata>.

5.4.1 @type

The type attribute is of particular importance. The LIDO Terminology contains LIDO Vocabularies for some type attributes, depending on the element in which the attribute occurs:

• Actor Type-Vocabulary
• Classification Type-Vocabulary
• Earliest Date Type-Vocabulary
• Event Place Type-Vocabulary
• Gender Actor Type-Vocabulary
• Identifier Type-Vocabulary
• Latest Date Type-Vocabulary
• Nationality Actor Type-Vocabulary
• Object Description Set Type-Vocabulary
• Object Measurements Set Type-Vocabulary
• Object/Work Type Type-Vocabulary
• Period Name Type-Vocabulary
• Record Info Set Type-Vocabulary
• Record Metadata Date Type-Vocabulary
• Repository Set Type-Vocabulary
• Repository Work ID Type-Vocabulary
• Resource Representation Type-Vocabulary
• Rights Type Type-Vocabulary
• Term Materials/Techniques Type-Vocabulary
• Vital Dates Actor Type-Vocabulary
• Vital Place Actor Type-Vocabulary

5.4.2 @addedSearchTerm

Attribute name: lido:addedSearchTerm

Note: Boolean attribute of the <lido:term> element indicating that the term has been added to enhance retrieval when set to “yes” (“no” is default). The additional term may be a synonym, a broader term, or an equivalent term in a further language, taken from a local or published controlled vocabulary.

Possible use cases for adding a term are: The index term from a linked data vocabulary (a) does not provide a (correct) term in the desired language; (b) does not include a synonym considered useful as search entry by the data provider; (c) is not expected to be fully exploited with regard to its semantic relationships by the portal, so that adding a broader term is useful for expanding the search result.

Example 1: The following XML code snippet is an example for use case (a): The AAT descriptor provides an incorrect German equivalent, ‘Ölgemälde’.

<!-- Medium -->
<lido:termMaterialsTech
   lido:type="http://terminology.lido-schema.org/lido00513">
   <skos:Concept
       rdf:about="http://vocab.getty.edu/aat/300015050">
       <skos:prefLabel
           xml:lang="en">
           oil paint (paint)
       </skos:prefLabel>
       <!-- The following label is an incorrect German translation -->
       <skos:prefLabel
           xml:lang="de">
           Ölgemälde
       </skos:prefLabel>
   </skos:Concept>
   <lido:term
       lido:addedSearchTerm="yes"
       xml:lang="de">
       Ölfarbe
   </lido:term>
</lido:termMaterialsTech>

Example 2: The following XML code snippet is an example for use case (b): The AAT concept is represented by two terms, ‘smiling’ and ‘smiled’. The term ‘smile’ which is likely to be searched for, is not provided and therefore added as a search term.

<lido:subjectConcept>
   <skos:Concept
       rdf:about="http://vocab.getty.edu/aat/300417502">
       <skos:prefLabel
           xml:lang="en">
           smiling
       </skos:prefLabel>
       <skos:altLabel
           xml:lang="en">
           smiled
       </skos:altLabel>
       <skos:mappingRelation>
           http://www.wikidata.org/entity/Q487
       </skos:mappingRelation>
       <skos:mappingRelation>
           https://d-nb.info/gnd/4034011-9
       </skos:mappingRelation>
   </skos:Concept>
   <lido:term
       lido:addedSearchTerm="yes"
       xml:lang="en">
       smile
   </lido:term>
   <lido:term
       lido:addedSearchTerm="yes"
       xml:lang="de">
       Lächeln
   </lido:term>
</lido:subjectConcept>

5.4.3 @codecResource

Attribute name: lido:codecResource

Note: Attribute for <lido:linkResource> and <lido:resourceSet> to indicate that a particular codec is required for rendering the resource. Values and URIs for codec names can be found in the Open Metadata Registry.

Example: The following XML code snippet indicates that the linked resource is a provided audio to be rendered as digital audio encoded according to a specification officially named MPEG Audio Version 1 Layer 3 (colloquially referred to as MP3). The resource is an ‘audio excerpt’ from the opera Mona Lisa, provided by the German Digital Library.

<lido:resourceRepresentation
    lido:type="http://terminology.lido-schema.org/lido00465">
    <lido:linkResource
        lido:codecResource="MPEG Audio Version 1 Layer 3"
        lido:formatResource="audio/mpeg">
        http://media.slub-dresden.de/fon/snp/a/012100/fon_snp_a_012100_01.mp3
    </lido:linkResource>
</lido:resourceRepresentation>

5.4.4 @encodingAnalog

Attribute name: lido:encodinganalog

Note: Attribute for many LIDO elements to record the field label in the source database from which the element content was migrated. The source format for the whole document is indicated in the attribute lido:relatedencoding of the LIDO Wrapper.

Example: The following XML code snippet contains the popular French title for Mona Lisa, “La Joconde”, stored in the source database as “titre d’usage” under the field label “Type de titre”. The title type is indexed with the AAT descriptor ‘popular title’.

<lido:titleSet
    lido:type="http://vocab.getty.edu/aat/300417200">
    <lido:appellationValue
        lido:pref="http://terminology.lido-schema.org/lido00170"
        lido:encodinganalog="Type de titre"
        lido:label="titre d'usage"
        xml:lang="fr">
        La Joconde
    </lido:appellationValue>
    <lido:sourceAppellation>
        "Institut national d'histoire de l'art, Portrait de Lisa Gherardini. URL: https://agorha.inha.fr/ark:/54721/8e279ee1-f842-4eb3-994d-797ca8562c09
    </lido:sourceAppellation>
</lido:titleSet>

5.4.5 @formatResource

Attribute name: lido:formatResource

Note: Attribute for elements referring to the internet media type of a web resource, i.e., <lido:legalBodyWeblink>, <lido:linkResource>, <lido:objectWebResource>, and <lido:recordInfoLink>. It is recommended to use the IANA Media Types as values.

Example: The following XML code snippet marks the format of the Web resource for a study of the Mona Lisa as “text/html” according to the IANA Media Type.

<lido:object>
    <lido:objectWebResource
        lido:formatResource="text/html"
        xml:lang="de">
        http://foto.biblhertz.it/obj08012138
    </lido:objectWebResource>
</lido:object>

5.4.6 @geographicalEntity

Attribute name: lido:geographicalEntity

Note: Attribute for <lido:partOfPlace>, <lido:place>, <lido:repositoryLocation>, and <lido:vitalPlaceActor> to indicate the kind of place as a physical entity, such as a forest or a river. This attribute was intended in LIDO v1.0 to qualify the type of the given place entity including natural environment and landscape. In LIDO v1.1 these values can be expressed in greater detail through <lido:placeClassification>. Note that Place Classification in LIDO corresponds to ‘Place Type’ in the Getty Thesaurus of Geographic Names. It is recommended to use a URI to refer to the kind of geographical entity.

Example: For an analogous example see ‘lido:politicalEntity’ below in this list.

For more information see the note for ‘geographicalEntity’ in the LIDO Terminology Recommendation.

5.4.7 @label

Attribute name: lido:label

Note: Attribute for many LIDO elements to indicate how the data element from which the data were migrated is labelled at the user interface. Note that this can be different from how the element is named in the source database (see lido:encodinganalog for this case).

Example: The following XML code snippet marks the label for the “Historique” note displayed at the user interface of the PORTRAIT DE MONA LISA (1479-1528).

<lido:descriptiveNoteValue
    lido:label="Historique"
    xml:lang="fr">
    Commandé par le florentin Francesco del Giocondo, époux de Mona Lisa entre 1503 et 1506
</lido:descriptiveNoteValue>

5.4.8 @measurementsGroup

Attribute name: lido:measurementsGroup

Note: Attribute for <lido:eventObjectMeasurements> and <lido:objectMeasurementsSet> to indicate the kind of measurements given in multiple <lido:measurementsSet> elements. This attribute is intended to be used in application profiles.

Example: The following XML code snippet shows how the “Measurement object requirement” concerning temperature conditions is recorded.

<!-- Measurement object requirement for @measurementsGroup "temperature" -->
<lido:eventObjectMeasurements
    lido:type="http://terminology.lido-schema.org/lido00923"
    lido:measurementsGroup="http://vocab.getty.edu/aat/300056066">
    <lido:displayObjectMeasurements>
        16-25°C ± 1.5°C over 24 hours if the object is installed in a room
        equipped with an operating Heating Ventilation and Air-Conditioning
        (HVAC) system
    </lido:displayObjectMeasurements>

5.4.9 @mostNotableEvent

Attribute name: lido:mostNotableEvent

Note: Attribute for <lido:eventSet> and <lido:eventWrap> to indicate that the event in focus is considered to be the most notable or significant event among others recorded for the object.

Example: The following XML code snippet declares the event “Production” as the most notable one.

<lido:eventSet
    lido:sortorder="1"
    lido:mostNotableEvent="1">
    <lido:event>
        <lido:eventType>
            <skos:Concept
                rdf:about="http://terminology.lido-schema.org/lido00007">
                <skos:prefLabel
                    xml:lang="en">
                    Production
                </skos:prefLabel>
                <skos:prefLabel
                    xml:lang="de">
                    Herstellung
                </skos:prefLabel>
            </skos:Concept>
         </lido:eventType>
    <lido:event>
</lido:eventSet>

5.4.10 @politicalEntity

Attribute name: lido:politicalEntity

Note: Attribute for <lido:partOfPlace>, <lido:place>, <lido:repositoryLocation>, and <lido:vitalPlaceActor> to indicate the kind of place as an administrative, political entity. This attribute was intended in LIDO v1.0 to qualify the type of the given place entity according to political structures, including values such as country or city. In LIDO v1.1 these values can be expressed in greater detail through <lido:placeClassification>. Note that Place Classification in LIDO corresponds to ‘Place Type’ in the Getty Thesaurus of Geographic Names. It is recommended to use a URI to refer to the kind of political entity.

Example: The following XML code snippet shows the index entry for “France”, qualified as a “country” by the value for the political entity attribute.

<lido:partOfPlace
   lido:politicalEntity="http://www.wikidata.org/entity/Q6256">
   <lido:placeID
       lido:type="http://terminology.lido-schema.org/lido00099">
       http://www.wikidata.org/entity/Q20861
   </lido:placeID>
</lido:partOfPlace>

For more information, see the note for ‘politicalEntity’ in the LIDO Terminology Recommendation.

5.4.11 @pref

Attribute name: lido:pref

Note: Attribute for text elements like <lido:term> or appellations, as well as identifier elements, to indicate whether, e.g., the value is a preferred or an alternative one, or should be used as a search entry only. The LIDO Preference Vocabulary contains a value list for the pref attribute. For concept terms and names of individual entities a “Preferred label” (one and only one per language), always has to be provided. If only one value is supplied, this will be chosen as the preferred one. To determine how a value should be displayed in a portal, the preference role “Display label” may be used.

Example: The following XML code snippet represents the concept with indexing terms as defined in the SKOS namespace. In order to predefine a label for display, the value “Display label” is used for the ‘lido:pref’ attribute.

<lido:roleActor>
   <skos:Concept
       rdf:about="http://vocab.getty.edu/aat/300025136">
       <skos:prefLabel
           xml:lang="en">
           painters (artists)
       </skos:prefLabel>
       <skos:prefLabel
           xml:lang="de">
           Maler
       </skos:prefLabel>
   </skos:Concept>
   <!-- Display label-->
   <lido:term
       lido:pref="http://terminology.lido-schema.org/lido00526"
       xml:lang="en">
       Painter
   </lido:term>
   <lido:term
       lido:pref="http://terminology.lido-schema.org/lido00526"
       xml:lang="de">
       Maler
   </lido:term>
</lido:roleActor>

5.4.12 @relatedEncoding

Attribute name: lido:relatedEncoding

Note: Attribute held by the <lido:lidoWrap> and <lido:lido> elements to indicate the format of the whole data source from which the data were migrated. For individual elements with data values the corresponding source data fields can be indicated using the attributes lido:encodinganalog and lido:label.

5.4.13 @sortorder

Attribute name: lido:sortorder

Note: Attribute held by many LIDO elements to suggest a sequential ordering among sibling elements for online presentation.

Example: The following XML code snippet marks the “Aquisition” of the object as the second event in the list of events the object is involved in.

<lido:eventSet
    lido:sortorder="2">
    <lido:event>
        <lido:eventType>
            <skos:Concept
                rdf:about="http://terminology.lido-schema.org/lido00001">
                <skos:prefLabel
                    xml:lang="en">
                    Acquisition
                </skos:prefLabel>
                <skos:prefLabel
                    xml:lang="de">
                    Erwerb
                </skos:prefLabel>
            </skos:Concept>
         </lido:eventType>
    <lido:event>
</lido:eventSet>

5.4.14 @source

Attribute name: lido:source

Note: Attribute held by identifier and date elements to describe the source of the information given in the holding element.

Example: The following XML code snippet shows the source for the estimated earliest date of the creation of the Mona Lisa by Leonardo da Vinci.

<lido:earliestDate
    lido:source="Collections des musées de France (Joconde), Portait de Mona Lisa. URL: https://www.pop.culture.gouv.fr/notice/joconde/000PE025604"
    lido:type="http://terminology.lido-schema.org/lido00529">
    1503
<lido:earliestDate>

6 Checking metadata quality

Quality issues can affect processing, integration, and usefulness of a metadata record. Quality checks should therefore be organized according to different levels of compliance:

• Syntactic validity with respect to the schema definition
• Observation of additional formal constraints
• Observation of content rules and recommendations

6.1 Syntactic validation

Reliable processing of XML records requires that the record structure follows the model definition. The LIDO record schema is expressed in the W3C XML Schema Definition Language (XSD), one of several formal grammars for specifying XML data structures. An XML record is said to be syntactically valid if (and only if) it meets all constraints laid down in the formal schema definition.

Since all further quality checks rely on the syntactic validity of a LIDO record, XSD validation is the essential first step in quality assurance. Software tools for checking XML records against XSD are widely available. In the case of the LIDO schema, such validators will also perform checks against the Geographical Markup Language (GML) definition used in LIDO for location coordinates. Note that the GML schema is many times larger than the LIDO schema, so that precautions against overuse of machine resources may have to be taken when high quantities of individual LIDO records need to be validated.

6.2 Schematron

The schema definition of LIDO v1.1 contains embedded Schematron rules that constrain certain aspects of the definition which cannot be expressed through the XML Schema Definition Language (XSD). A valid LIDO v1.1 document has therefore to validate against the structural definition contained in the XSD Schema while also complying to the Schematron assertions.

Schematron validates these constraints through rules implemented as W3C XSL Transformations. In other words, Schematron provides a workflow in which a transformation style sheet, when applied to a LIDO v1.1 document, will result in a report document (as Schematron Validation Report Language, SVRL) about compliance to these rules.

Validation of Schema embedded Schematron rules is supported by several tools. Please refer to the respective documentation. For pre-built Schematron validation style sheets and technical documentation refer to https://gitlab.gwdg.de/lido/development/-/tree/develop/1.1/schematron.

6.3 Further measures

Wherever feasible, additional checks should be developed for the detection of repeatedly (or even occasionally) occuring quality issues. In many cases, such checks can be implemented as sets of Schematron rules apart from those described above, as self-contained XSLT or XQuery scripts, or as tools written in any programming language with support for XML technology.

Useful areas for such quality checks include:

• Compliance with the LIDO Terminology Recommendation. These specify which sections of the LIDO Terminology or from other vocabularies can be applied in particular element or attribute contexts. For example, the pref attribute of a <lido:term> element can only contain a URI from the LIDO Preference Vocabulary, and a statement in <lido:objectWorkType> should only be expressed with concepts from the AAT Objects Facet.
• Appropriate usage of elements and attributes for specific object types. For example, a Natural object cannot have a Production event.
• Appropriate usage of textual elements. For example, object titles in the <lido:titleSet> element should consist of more than one word, not only of numbers, etc.
• Detection of contradictory statements. For example, the timespan of a Collection event cannot precede that of the Designing of the item.
• Improper use of type attributes. A <lido:measurementType> “height” is incompatible with a <lido:measurementUnit> “kilogram”.

7 References and further reading

7.1 LIDO

• LIDO XML Schema Definition. XSD
• LIDO Documentation. HTML
• LIDO Terminology Recommendation. HTML
• LIDO Terminology. Website
• LIDO Terminology LOD Interface Documentation. Website
• LIDO Examples. Website
• LIDO Application Profiles Website
• [LIDO Application Profile Painting and Sculpture] Knaus, Gudrun, Kailus, Angela und Stein, Regine: LIDO-Handbuch für die Erfassung und Publikation von Metadaten zu kulturellen Objekten: Band 2: Malerei und Skulptur, herausgegeben von Deutsches Dokumentationszentrum für Kunstgeschichte – Bildarchiv Foto Marburg und Christian Bracht, Heidelberg: arthistoricum.net, 2022 (LIDO-Handbuch, Band 2). Website/PDF
• [LIDO home] LIDO Website. Website

7.2 General introductions

• Baca, Murtha (ed.) (2002). Introduction to Art Image Access: Issues, Tools, Standards, and Strategies. Online Edition
• Baca, Murtha (ed.) (2016). Introduction to Metadata (Third Edition). Online Edition
• Harpring, Patricia (2010). Introduction to Controlled Vocabularies: Terminology for Art, Architecture, and Other Cultural Works. Online Edition
• Hyvönen, Eero (2012). Publishing and Using Cultural Heritage Linked Data on the Semantic Web. Morgan & Claypool.
• Joudrey, Daniel; Taylor, Arlene G. (2018). The Organization of Information. Fourth edition. Libraries Unlimited.
• Jannidis, Fotis; Kohle, Hubertus; Rehbein, Malte (Hg.) (2017). Digital humanities. Eine Einführung. J. B. Metzler.
• Lubas, Rebecca; Jackson, Amy; Schneider, Ingrid (2013). The Metadata Manual. A practical workbook. Elsevier Science.
• Riley, Jenn (2017). Understanding Metadata: What is Metadata, and What is it For? A Primer Publication of the National Information Standards Organization. PDF
• Zeng, Lei Marcia; Qin, Jan (2022). Metadata. Third edition. London: Facet Publishing.

7.3 Metadata standards and guidelines

• [CDWA-Lite] J. Paul Getty Trust/ARTstor (2006). CDWA Lite. XML Schema Content for Contributing Records via the OAI Harvesting Protocol. Website
• [CRM home] CIDOC Conceptual Reference Model (CRM). Website
• [CRM 2006–] The International Committee for Documentation of the International Council of Museums (ICOM-CIDOC). Versions of the CIDOC-CRM
• [CRM 2014] ISO 21127:2014. Information and documentation – A reference ontology for the interchange of cultural heritage information. Reference
• [CRM 2014] Oldman, Dominic and CRM Labs (2014). The CIDOC Conceptual Reference Model (CIDOC-CRM): Primer. PDF
• [EDM home] Europeana Data Model. Website
• [EDM 2013] Europenana Data Model Primer (2013). Editor: Antoine Isaac. PDF
• [EDM 2017] Definition of the Europeana Data Model v5.2.8. (2017). Europeana Foundation. PDF
• [IFLA-FRBRoo] Bekiari, Chryssoula; Doerr, Martin; Le Boeuf, Patrick; Riva, Pat (2015). Definition of FRBRoo: A Conceptual Model for Bibliographic Information in Object-Oriented Formalism. PDF
• [IFLA-LRM] Riva, Pat; Le Bœuf, Patrick; Žumer, Maja (2017). IFLA Library Reference Model: A Conceptual Model for Bibliographic Information. PDF
• [LinkedArt] Linked Art: Networking Digital Collections and Scholarship (2019–). Research Network funded by the UK Arts and Humanities Research Council (AHRC). Website -Spectrum Collections Trust (2022). Spectrum 5.1. Website

7.4 Content standards and guidelines

• [CCO 2006] Cataloging Cultural Objects: A Guide to Describing Cultural Works and Their Images. Visual Resources Association. Edited by Murtha Baca et al. (2006). American Library Association, Chicago. PDF
• [CDWA] Categories for the Description of Works of Art (2009–). Edited by Murtha Baca and Patricia Harpring. Last revised 2022. Online Edition
• [GVP] Getty Vocabulary Program. Getty Resarch Institute. Website
• [GVP 2014–] Training Materials. Website
• [GVP 2020] CONA and Subject Access for Art Works. Overview of the CONA Depicted Subject. Patricia Harpring (2020). PDF
• [GVP 2022] Cataloging Works at Museums and Special Collections: Documentation, Indexing, Access with CDWA, CCO, and the Getty Vocabularies. Patricia Harpring (Revised February 2022). PDF
• [GVP 2022] Utilizing Getty Vocabularies for Research and Retrieval. Patricia Harpring et al. (May 2022). PDF (9 MB, 71pp)
• [GVP 2022] Introduction and Application: Getty Vocabularies, CDWA, and CCO. Workshop (June 2022). PDF (13 MB, 166pp)

7.5 Value vocabularies

• [AAT] Art & Architecture Thesaurus® Online. J. Paul Getty Trust, Getty Research Institutes, made available under the ODC Attribution License. Website
• [GeoNames] GeoNames – open source geographical database. Website
• [GND] Gemeinsame Normdatei (Integrated Authority File). Deutsche Nationalbibliothek. Website. Access via lobid.gnd (German)
• [Iconclass] Iconclass. Third version of the online Iconclass browser. Website
• [LCSH] LOC Library of Congress Subject Headings. Website
• [TGN] Getty Thesaurus of Geographic Names® Online. J. Paul Getty Trust, Getty Research Institutes, made available under the ODC Attribution License. Website
• [ULAN] Union List of Artist Names® Online. J. Paul Getty Trust, Getty Research Institutes, made available under the ODC Attribution License. Website
• [VIAF] VIAF: Virtual International Authority File. Hosted by OCLC. Website
• [Wikidata] Wikimedia Foundation. Wikidata – the free knowledge base. Website

7.6 Linked Data and Semantic Web

• Heath, Tom; Bizer, Christian [2011]. Linked Data: Evolving the Web into a Global Data Space. Online Edition 1.0.
• European Commission (2013). Einführung in Linked Data. Open Data Support. PDF (in German)
• Europeana (2017). Linked Open Data. Website
• FAIR Princples (2016). GO FAIR Initiative. Website
• UCLA Library [2022]. Semantic Web and Linked Data. (Last Updated Dec 12, 2022). Home
• W3C (2014). Linked Data Platform Best Practices and Guidelines. Website
• W3C (2015–). Semantic Web. Website

7.7 Application profiles

• Dublin Core Metadata Initiative (2009). Guidelines for Dublin Core™ Application Profiles. Website
• LOC Program for Cooperative Cataloging (2019). PCC Task Group on Metadata Application Profiles. Website
• UCLA Library [2022]. Best Practices, Standards, and Metadata Application Profiles (MAPs). (Last Updated Dec 12, 2022). Website section

7.8 Formal languages and specifications

XML and associated technologies

• The Extensible Markup Language (XML) Version 1.0, W3C Recommendation 26 November 2008. Website
• The W3C XML Schema Definition Language (XSD) Version 1.1 Part 1: Structures. W3C Recommendation 5 April 2012. Website
• The XML Path Language (XPath) Version 3.1, W3C Recommendation 21 March 2017. Website
• XSL Transformations (XSLT) Version 3.0, W3C Recommendation 8 June 2017. Website
• The Schematron language website by Rick Jelliffe, 1999–2021. Website

RDF and associated technologies

• The Resource Desciption Framework (RDF) Version 1.1 Concepts and Abstract Syntax. W3C Recommendation 25 February 2014. Website
• RDF Schema (RDFS) Version 1.1. W3C Recommendation 25 February 2014. Website
• The OWL 2 Web Ontology Language Document Overview (Second Edition). W3C Recommendation 11 December 2012. Website
• The SPARQL Query Language for RDF Version 1.1 Overview, W3C Recommendation 21 March 2013. Website

Schemas and protocols

• The Simple Knowledge Organization System (SKOS) Reference, W3C Recommendation 18 August 2009. Website
• The PROV Data Model (PROV-DM), W3C Recommendation 13 April 2013. Website
• The Geography Markup Language (GML) Encoding Standard Version 3.2. Open Geospatial Consortium Inc., 2016. PDF
• The OAI Protocol for Metadata Harvesting (OAI-PMH) Version 2.0. Open Archives Initiative 2002, Rev 2015. Website
• The Linked Data Platform (Rules for HTTP operations) Version 1.0, W3C Recommendation 26 February 2015. Website