dera: digital heritage reference architecture · dera 2.0 is an elaboration of these principles,...

DERA:Digital HeritageReference ArchitectureGoals, principles and business architecture

Version 2.0 | November 2018

Authors:Bram Gaakeer (OCW), Enno Meijers (National Library and NDE Usable), Sjors de Valk (NDE Usable), Willem Melder (Sound&Vision), Frans van der Zande (RCE), Laurents Sesink (Leiden University), Gijsbert Kruithof (National Archives), Annelot Vijn (Utrecht Archives), Joost van der Nat (NDE Sustainable), Wilbert Helmus (NDE Usable) and Marco Streefkerk (DEN).

Introduction 3National Strategy for Digital Heritage 5Relationships with other reference architectures 6Objectives made concrete 7Goals 8Principles 14Business architecture 197.1 Introduction 197.2 Defining business objects 207.3 Defining actors 267.4 Defining roles 277.5 Business functions 287.6 Linked Data 327.7 Defining services 33

1.2.3.4.5.6.7.

Contents

4 DERA – Version 2.0

DERA 1.0

DERA 2.0A.

ArchitectureVision

B.Business

Architecture

C.Information

SystemsArchitectures

D.TechnologyArchitecture

E.Opportunitiesand Solutions

F.MigrationPlanning

G.Implementation

Governance

H.Architecture

ChangeManagement

RequirementsManagement

Business

Application

Technology

Preliminary

1.

3DERA – Version 2.0

IntroductionThe purpose of the Digital Heritage Reference Architecture (DERA) is to create architecture frameworks that contribute to the realisation of the National Strategy for Digital Heritage. DERA is being developed step by step. The National Strategy distinguishes three domains: Visible, Usable and Sustainable. The focus of DERA 1.0 and 2.0 is on the Usable domain. DERA 3.0 will be intended to also pay attention to the Visible and Sustainable domains.

DERA 1.0 contained common principles. DERA 2.0 is the first step towards translating them into concrete requirements for organisations that are part of the network.

In the development of DERA, international standards are taken into account. The TOGAF standard is used as a method to shape the architecture process. ArchiMate is the standard for defining architecture concepts and describing architecture products.

TOGAFThe Open Group Architecture Framework (TOGAF) describes an approach to designing, planning and implementing an enterprise information architecture.At the core of TOGAF is the Architecture Development Method (ADM), which defines the connections between the various architecture processes. The development of DERA is described using ADM. In the diagram, DERA 1.0 and DERA 2.0 are set out against ADM.

In DERA 1.0, the strategy of the Digital Heritage Network (NDE) has been elaborated in the context of an Architecture Vision (A).

DERA 2.0 is an elaboration of these principles, which can be found in the Business Architecture (B). DERA 2.0 makes clear what participating in the Digital Heritage Network actually implies. It describes the consequences for the organisation, business functions, objects and services. The necessary changes are made explicit in terms of requirements (Requirements Management in ADM). DERA describes the desired situation.

The Business Architecture describes what needs to be done, not how it needs to be done, which is the domain of Application Architecture and Technology Architecture. DERA 3.0 will examine which cross-sectoral agreements can be made about the Application Architecture. This can be realised by linking with implementation issues. At this stage we will be able to identify that which individual organisations cannot solve, i.e. where common agreements are needed. Agreements about the standards to be used, as well as agreements about specific licensing forms for the publication of digital objects and metadata, will be dealt with in a later version.

The actual realisation of the change (ADM parts E, F, G) is the responsibility of the individual organisations. This will be facilitated by the NDE’s Sustainable, Usable and Visible domain groups. Several innovation projects will be driven by the domain groups. They have the full picture of the implementation agenda and the experiences gained during implementation. These experiences may give rise to changes to the architecture (ADM part H). The domain groups will collaborate with the DERA working group on any change.

1.


ArchiMateArchiMate is an open and independent description language for enterprise architectures. It is supported by various IT architecture modelling tools from different suppliers. The language is based on IEEE Standard 1471. Since 2008, ArchiMate has been supported and managed as an open standard by The Open Group.1 Many Dutch reference architectures make use of translated concepts from ArchiMate 2.1. In ArchiMate 3.0, some concepts are defined slightly differently. DERA is based on the English version 3.0.

DERA is owned by the Dutch Ministry of Education, Culture and Science (OCW). Further development of DERA is the joint responsibility of the participants in the Digital Heritage Network. It is being carried out by the Architecture working group.The National Library (KB), the Utrecht Archives, the National Archives (NA), National Cultural Heritage Agency (RCE), Sound and Vision, Leiden University, the Knowledge Institute for Digital Culture (DEN) and representatives of the NDE domain groups participate in this working group. In the coming period, we will consider how management of DERA can be given a more structural form.

1 https://nl.wikipedia.org/wiki/ArchiMate


National Strategy for Digital Heritage

The Digital Heritage Network’s National Strategy for Digital Heritage2 aims “to increase the social value of the collections held by archives, libraries, museums and other institutions.”Standardized cross-sectoral facilities should lead to better (digital) acces-sibility and thus increased awareness of the social value of what the heritage institutions have collected.

2 https://www.netwerkdigitaalerfgoed.nl/wp-content/uploads/2018/02/Nationale_Strategie_Digitaal_Erfgoed_MinOCW.pdf

2.



Relationships with other reference architecturesDERA contains agreements to facilitate collaboration. They refer to both internal collaboration within the NDE and external collaboration of the NDE with its envi-ronment. This means DERA touches upon sectors that it needs to coordinate with. These sectors often have their own reference architectures. This chapter describes the sectors that must be taken into account and the reference architectures they are using. The objectives of DERA 2.0 are in line with the objectives used in the reference architectures described in this chapter. In future versions, harmonisation possibilities will be explored.

1. E-government For e-government as a whole, there are architecture agreements enabling cross-sectoral

collaboration. They have been laid down in the Netherlands Government Reference Architecture (NORA)3. These agreements facilitate collaboration between organisations with a public task. DERA therefore follows the NORA principles. NORA definitions for concepts are also used wherever possible. DERA can be considered a NORA subsidiary.

2. Education Education is an important potential user group for heritage information (for the definition of this

term, see below: Heritage information). There is a reference architecture for education available, the Reference Education Sector Architecture (ROSA4). For higher education there is HORA5.

3. Science Scientific products, such as publications, research data and special collections, are forms of

heritage information too. In addition to being producers of heritage, researchers are also important users. The so-called FAIR principles6 have been defined as the starting point for making scientific research data accessible.

4. Sustainable archiving For sustainable archiving, principles for sustainable access to government information (DUTO)7

have been agreed. These principles are also included in NORA. In addition to improving findability, sustainable archiving is also an NDE objective. As a NORA subsidiary, DERA follows the DUTO principles.

5. Spatial planning Under the Environment Act, the RCE will have to publish information on national monuments.

In doing so, the RCE must take into account the connection requirements that apply to the Digital System for the Environment Act (DSO). The same digital information about national monuments is also made available to other users by RCE.

6. Basic registers Basic registers can be used to increase the visibility of heritage information. One example is the

Basic register of Addresses and Buildings (BAG). By establishing the relationship with a BAG address or BAG building, heritage information can be related to other information relevant to that address or building. The basic registers are described in the System Catalog8.

3.


Objectives made concreteAn architecture aims to realise a certain change. This requires an explicit motivation of why the change is desirable. The motivation for DERA is made explicit in the National Strategy. This motivation is systematically described and made concrete in DERA.

GoalArchiMate defines a goal as a high-level description of the desired direction or the desired final situation for an organisation and its stakeholders.

OutcomeArchiMate defines an outcome as an end result that has to be achieved. Outcomes are described in general, functional terms, i.e. at a high level. An organisation needs resources (“capabilities”) to achieve the outcomes.

PrincipleArchiMate defines a principle as a qualitative description of intentions that an architecture must comply with. These are, in fact, architectural goals. Principles describe the desired properties of systems in abstract terms.

RequirementArchiMate defines requirements as prerequisites for the capabilities needed to achieve the desired outcomes.

In DERA, the strategic objective of the National Strategy is developed into four operational goals. A strategic goal defines an effect that must be achieved (better accessibility). As this goal is so abstract, it is impossible to attach a measurable outcome to it. That is why a strategic goal is subdivided into operational goals that can be linked to measurable outcomes. The operational goals shall jointly lead to the effect intended by the overarching strategic goal.

The operational goals are translated into principles, which are actually architectural objectives. Principles are the bridge between DERA and the National Strategy. They clarify DERA’s contribution to the National Strategy. Based on these principles, DERA defines requirements that guide collaboration within the Digital Heritage Network.

3 https://www.noraonline.nl/wiki/NORA_online 4 https://www.noraonline.nl/wiki/ROSA_(Referentie_Onderwijs_Sector_Architectuur) 5 https://www.wikixl.nl/wiki/hora/index.php/Hoofdpagina 6 https://www.go-fair.org/fair-principles/7 https://www.nationaalarchief.nl/archiveren/kennisbank/duto8 http://www.stelselcatalogus.nl/

4.


GoalsThe National Strategy aims “to increase the social value of the collections of archives, libraries, museums and other institutions” through better (digital) accessibility. This should result in more awareness of the social value of what the heritage institutions have collected.

DERA develops this strategic objective into four operational goals:1. Users can freely navigate the shared heritage information.2. Users can determine the usefulness of specific heritage information.3. Whenever necessary, users can add new or external information themselves.4. Heritage institutions work together.

In the elaborated goals, the terms “user”, “heritage institution” and “NDE” are used. The terms “user” and “heritage institution” are defined in the section “Defining actors”.

Digital Heritage NetworkThe Digital Heritage Network is a joint venture of heritage institutions that subscribe to the National Strategy. They are developing a system of national facilities for improving the visibility, usability and sustainability of digital heritage in the Netherlands.

The strategic and operational objectives are described in a standardized manner below, including a rationale and implications. The rationale indicates how the goal contributes to the National Strategy or overarching objectives. The implications explain how the strategic goal is elaborated into operational goals and how the operational goals are elaborated into principles.

5.


Strategic goal

Increasing social value by putting the users first

Operational goals

Users can freely navigate heritage information

Users can determine the usefulness of heritage information

Users can add information

Heritage institutions work together

Principles

Ensure that the authenticity of heritage information is clear

Ensure that the availability of heritage information is clear

Ensure that information is presented in a recognisable and user-friendly way

Ensure an unambiguous description of heritage information

Ensure that heritage information refers

Ensure that heritage information is referable

Respect the diversity of heritage information

Provide distributed heritage information

Overview of the strategic goals, operational goals and principles of DERA.


Strategic goal 1: Putting the users first

DocumentationWhen managing or presenting heritage information, the heritage institutions focus on usability for the users.

RationaleUsers determine the social value of heritage. See the National Strategy for Digital Heritage.

ImplicationsIndividual heritage institutions already know their own users and provide them with the best possible access to their heritage information and functionality. The strategic goal of putting the user first has the following implications:1. Users must be able to consult and use heritage information from separately managed heritage

collections together. To this end, unnecessary differences between source providers or source holders are avoided through joint agreements and solutions. See Operational goal 1.1.

2. Users must be able to use heritage information for their purposes. To this end, users must be able to determine its usefulness. See Operational goal 1.2.

3. Users must be able to consult and use shared heritage information in combination with their own or third parties’ information. To this end, they must be able to add information. See Operational goal 1.3.

4. Heritage institutions must work together. See Operational goal 1.4.

Operational goal 1.1: Users can freely navigate

DocumentationUsers must be able to select relevant heritage information efficiently and be able to query the context of this information, without being hindered by the fact that the information is managed and provided by multiple institutions.

RationaleThe focus of attention is the user’s demand rather than the heritage institution’s supply. This demand may exceed the supply of an individual heritage institution.

ImplicationsSemantic connection is central to the description of heritage information:1. Heritage information must be provided and presented in an unambiguous way.

See Principle 3 and Principle 4.2. The context of heritage information can be managed and provided by another heritage institution,

but there must be an unambiguous reference to the source holder. See Principle 5 and Principle 6.


Operational goal 1.2: Users can determine the usefulness of heritage information

DocumentationUsers must be able to determine whether the heritage information they find meets the requirements of their application. Here, relevant aspects are the substantive usefulness of a specific object (is it a photograph of the subject in question?), the value of a selection (are these all the available photo-graphs of the subject in question?), or reliability (is the information authentic?).

RationaleThe usefulness of heritage information differs between users and between applications. It is impossible for source holders or providers to establish these differences and structure the heritage information accordingly. The source holder can only ensure that as much information as possible is accessible in the clearest possible way, so that users can determine whether the heritage information is useful.

Implications1. The authenticity of heritage information must be registered and published, e.g. through provenance

information. See Principle 1.2. The long-term availability of heritage information must be registered and published. See Principle 2.3. The contents and context of heritage information must be registered and published. See Principle 4.4. The restrictions that apply to disclosure must be registered and published. The reasons for

imposing restrictions are diverse. Examples include privacy protection, provisions of the Archives Act and intellectual property and usage rights. See Principle 2 and Principle 3.

5. Form and functionality of the heritage information provided must be specified, for example when the information can be retrieved in real time using a sustainable identifier, stating the format in which the answer to an information request is provided.


Operational goal 1.3: Users can add information

DocumentationUsers must be able to combine the shared heritage information with other information, or add information to it. This varies from information with the aim of making it public (such as for crowd-sourcing) to confidential information for personal use, as may be required in science. The added information may be new, for example in genealogical applications, or existing information, for example from Wikipedia. The source holder can decide whether the added information is suitable for inclusion in their source system.

RationaleApart from the shared heritage information, there is more information that is relevant to one or more users. This may be the user’s own non-public information or a third-party source of information. The user must be able to combine it with the shared heritage information. Optionally, a source holder may include this information, after it has been verified, into their shared heritage information.

Implications1. In order to be able to relate external information to shared heritage information, the latter must

be referable. See Principle 6.2. If external information is included in the shared heritage information being managed, its

authenticity and availability must be evident. The external information must refer to the shared heritage information. See Principle 1, Principle 2 and Principle 5.

3. If external information is included in the shared heritage information being managed, it must be unambiguously described and be presented in a recognisable, user-friendly and referable manner. See Principle 3, Principle 4 and Principle 6.


Operational goal 1.4: Heritage institutions work together

DocumentationHeritage institutions must work together to make their heritage information more useful for users. Collaboration leads to agreements about the way in which information is made accessible and exchanged. Collaboration enables heritage institutions to utilise each other’s knowledge and facilities.

RationaleThe efforts of heritage institutions must be aimed at the same goal: to increase the social value of heritage by putting the user first. Collaboration is key to this. See also the National Strategy for Digital Heritage.

Implications1. Source holders make agreements about the way in which they describe and publish their heritage

information, for example with regard to metadata standards and interfaces (see Principle 4).2. Source holders make agreements about the heritage information that they wish to obtain from

other source holders. Information can be better connected and more easily found when source holders use the same sources, such as terminology sources (see Principle 5).

3. Source holders make clear what the availability of their heritage information is (see Principle 2). Without this clarity, it is uncertain to what extent other source holders can use the information.


PrinciplesThe principles are described in a standardized manner, using a rationale. The rationale indicates how the principle realises the operational goals.

The DERA principles are an elaboration of the objective of the National Strategy to make heritage information findable and accessible. In this regard, account is taken of the domain-specific principles of information findability and accessibility already applied by the Digital Heritage Network, such as the DUTO and FAIR principles9.DUTO is a list of requirements for sustainable accessibility of government information, which is being developed by the National Archives on behalf of the Ministry of OCW. The DUTO requirements allow government bodies to determine which measures they need to take in order to make the digital information they receive and create permanently accessible. The FAIR principles serve as guidelines for making scientific data suitable for reuse, under clearly described conditions, by both humans and machines.The DERA, DUTO and FAIR principles are complementary. Nowhere are they incompatible.However, there is overlap. In future versions of DERA, harmonisation possibilities will be explored. At the moment this is not yet meaningful, since the DERA and FAIR principles still need to be tested in practice and will therefore be subject to change.

9 https://wiki.nationaalarchief.nl/pagina/DUTO:Kwaliteitseisen en https://www.go-fair.org/fair-principles/

6.


Principle 1: Ensure that the authenticity of heritage information is clear

Documentation Users must be able to establish the authenticity (e.g. provenance and adaptations) of heritage information.

RationaleAuthenticity proves that the information object is what it claims to be, that it was created or submitted by the person or organisation that claims to have created or submitted it, and that it was created and submitted at the time indicated by the information object (taken from NORA). See Goal 1.2.

Principle 2: Ensure that the availability of heritage information is clear

DocumentationUsers must be able to establish the availability. This concerns both the form (access, authorization, format) and the term of availability (is a video available in the long term and can it be streamed?).

RationaleThe availability determines whether and how the user can immediately use the information and whether it can also be used in the long term, for example when research results need to be verified. See Goal 1.2.

Principle 3: Ensure that information is presented in a recognisable and user-friendly way

DocumentationHeritage must be recognisable as such and must be provided in a user-friendly format.

RationaleIf shared heritage information is presented as consistently as possible, users can quickly identify and compare the content and usefulness of objects from multiple providers. See Goal 1.1.User-friendliness ensures that users can easily consider whether the heritage information is interesting or relevant to them. See Goal 1.2.

Principle 4: Ensure an unambiguous description of heritage information

DocumentationHeritage information must be described in such a way that it is clear to users what type and form of heritage it is. Similar heritage information must be described in a similar way.

RationaleBy means of a clear description the user can assess the usefulness (see Goal 1.2). The unambiguous description creates the context that enables further navigation (see Goal 1.1).


Principle 5: Ensure that heritage information refers

DocumentationMeaning and interpretation of heritage information depend on the context. The context must be established by referring to related and managed heritage information, definitions, etc.

RationaleThe references are part of the context and help to determine the usability of the heritage information (see Goal 1.2). The references help to find an object from within the related context (see Goal 1.1).

Principle 6: Ensure that heritage information is referable

DocumentationHeritage information is referable when connections to other heritage information can be established. Users must be able to do so in order to reuse or enrich existing data via references.

RationaleThird-party references can provide contextual information that helps to determine the usefulness of heritage information (see Goal 1.2).When heritage information is referable, others can refer to it and it can be found more easily (see Goal 1.1).When heritage information is referable, third parties can be allowed to add information to it (see Goal 1.3).

Principle 7: Respect the diversity of heritage information

DocumentationHeritage information is very diverse, both in nature and size. This diversity is inherent to the organisational diversity of source holders. A large heritage institution, for example, has other possibilities than a small one. In addition, the diversity is inherent to the substantive diversity of source holders. For example, there are substantial differences between information from an archive and information from a museum, hence the differences in how the information is described. This diversity must be respected.

RationaleSource holders themselves must decide which heritage information they make available or obtain from others (see Goal 1.2). Generic facilities do not impose substantive, qualitative requirements on heritage information: the facilities are neutral.


Principle 8: Provide distributed heritage information

DocumentationDistributed heritage information is information that can be collected from multiple source systems. Information is not provided by one central organisation via one facility, but is available at a decentralized level through multiple facilities of several organisations. Each organisation is an independent node, every facility an independent application. Together, the organisations and their facilities form a network that exchanges information according to shared agreements.

RationaleThe network of heritage information is extensive and diverse. It is impossible to organise this network at a central level and to set up overarching facilities that satisfy all the various needs. In addition, centralization is undesirable because the sustainability of a central network is uncertain. That is why network participants must self-organise and take care of the provision and sharing of heritage information themselves. This autonomy prevents dependencies and enhances flexibility.At the same time, it makes everyone responsible for offering information in such a way that users of this information are not hindered by the diversity of the network (see Goal 1.1).


7. Business architecture7.1 Introduction

The business architecture describes (a) which tasks must be performed in order to realize the strategy, (b) who is responsible for this, and (c) which information is needed to perform these tasks. The business architecture is described using the following elements: • the business objects that are part of the heritage information and are relevant to the NDE; • the actors who play a role within the NDE; • the roles that the actors fulfil, with the corresponding tasks. Organisations can fulfil multiple

roles, for which they make their own choices. Some roles may also be outsourced; • the business functions that are necessary to make heritage information more accessible; • the services that NDE actors provide to each other.


7.2 Defining business objects

This chapter describes the most important business objects used in DERA. The data of these business objects must be suitable for automatic processing and must therefore comply with the ArchiMate definition of data objects. However, DERA 2.0 does not describe what these data objects look like.

Information or dataIn the definition of business objects, no distinction is made between the terms “information” and “data”. Whether something is information or data depends on the meaning a user attaches to it in a specific use case. In general, the same requirements apply to information and data. This is why a strict distinction between these terms in DERA is not very relevant.

ReuseWhen defining the business objects, the corresponding definitions from NORA10, DUTO11, DEN’s ABC of Digital Heritage12 , Europeana13, the Heritage Act14 and DMBOK15 have been used as far as possible. Where existing definitions from these sources have been adapted for use in the DERA context, this has been done without causing inconsistencies with the original definitions.

Business objects versus information objectsThe business architecture identifies the objects that are relevant from a business perspective: the business objects.

Metadata

Cultural-historical object

metadata

Enrichmentmetadata

Informationobject metadata

Datasetmetadata


Business object

Analogueinformation object

Born-digitalinformation

object

Digitizedinformation

object

Information object

Digitalinformation object

Digitized

Cultural-historical object Information object

describes

Conceptual cultural-

historical object

Material object

Immaterial cultural-

historical object

Digital cultural-historical object

Terminology sourcemetadata

A business object represents a concept used within a particular business domain (ArchiMate 3.0).

The concept of “information object” is frequently used in DERA. The ArchiMate application and information architecture contains the similar concept of “data objects”. In the context of DERA, most business objects are also information objects. The scope of DERA 2.0 is limited to the business architecture. That is why information objects are described here as ArchiMate business objects.

Object or entityThe term “object” is not confined to ArchiMate; it is also frequently used in the heritage sector, for example to refer to a cultural-historical artefact. In DERA, the term often occurs as part of a narrower concept. In DUTO, the term “entity” is defined, whereas DERA is mainly about objects. For this reason, we have included the term “object” as a synonym in the DUTO definition of “entity”.

10 https://www.noraonline.nl/wiki/Begrippenkader11 https://wiki.nationaalarchief.nl/pagina/DUTO:Begrippen12 http://www.den.nl/abc13 https://pro.europeana.eu/resources/standardization-tools/edm-documentation14 http://wetten.overheid.nl/BWBR0037521/2017-09-0115 https://dama.org/content/body-knowledge


An object or entity is a concrete or abstract thing that exists, existed or could exist, including the interrelationships between these things (derived from DUTO). Events are also treated as objects or entities in DERA.

Cultural-historical object or heritage object

Metadata


metadata

Enrichmentmetadata


Datasetmetadata


Business object



object


object

Information object


Digitized


describes


historical object

Material object


historical object



DefinitionA cultural-historical object, or heritage object, is an object with a certain cultural-historical value.

ExplanationA cultural-historical object: • can be material (Rembrandt’s Night Watch), immaterial (a country dance), conceptual

(the Second World War) or digital (a tweet by Donald Trump); • exists, existed or could exist; • can be composed of multiple cultural-historical objects. In the Heritage Act, the concept of cultural heritage is legally delineated. A broader definition is used in DERA. The Heritage Act refers to “sources from the past”; in DERA, future versions can be part of the findable information.Europeana defines a “cultural heritage object” as follows: “The original object that is the focus of the metadata description. It may be either a physical object (painting, book, etc.) or a digital original”. This corresponds to the differentiation between material cultural-historical object and digital cultural-historical object.


Information object

Metadata


metadata

Enrichmentmetadata


Datasetmetadata


Business object



object


object

Information object


Digitized


describes


historical object

Material object


historical object



DefinitionAn information object is a self-contained set of data with its own identity. (See https://wiki.nationaalarchief.nl/pagina/DUTO:Informatieobject )

ExplanationAn information object: • contains information about one or more cultural-historical objects; • is born-digital, digitized or physical; • exists, existed or could exist; • can be composed of multiple information objects (aggregation).

Examples of information objects are a letter, an email, a video, a website (aggregation), a web page, a tweet, an application for funding, a permit, a dossier (aggregation), etc.

Cultural-historical object versus information object

Metadata


metadata

Enrichmentmetadata


Datasetmetadata


Business object



object


object

Information object


Digitized


describes


historical object

Material object


historical object



A cultural-historical object can also be an information object and an information object can also be a cultural-historical object. For example, the Act of Abjuration (the declaration of independence by many of the provinces of the Netherlands from the allegiance to Philip II of Spain, signed on 26 July 1581 in The Hague) is both a cultural-historical object and an information object.

According to DEN’s ABC of Digital Heritage, three digital manifestations of cultural heritage can be distinguished: 1. born-digital heritage: heritage materials that are digital in origin, such as electronic archives,

digital art or photographs taken with a digital camera; 2. digitized heritage: heritage materials that are not digital in origin but have been reproduced by

means of digitization; 3. digital information about heritage, such as descriptions, detailed photographs or digital

reconstructions of a heritage object. The information is usually made available in an organised form, for example a database.


Note that this is all about “appearances”. The similarities and differences with the “objects themselves” (as used in DERA) are explained below.

• Re 1. Born-digital heritage can thus be a cultural-historical object (digital art) or an information object (electronic archive).

• Re 2. Digitized heritage matches the definition of a digital information object and therefore always refers to an information object.• Re 3. Digital information about heritage is largely in line with the concept of a digital information

object used here. However, the structured information about cultural-historical objects referred to here is understood as “metadata” describing the cultural-historical object.

Metadata

DefinitionMetadata is data describing the context, content, structure and form of information and its management over time (derived from NORA).

ExplanationIt concerns structured data that describe other objects, either physical or digital. An object can be both a cultural-historical object and an information object. Metadata themselves are also information objects.The four main types of metadata, derived from DEN’s ABC of Digital Heritage, are:

• descriptive metadata (necessary for identifying and finding objects);• structural metadata (establishing the relationships between individual objects that • collectively form a unit);• technical metadata (information about the production of the object);• administrative metadata (focused on management of objects).

EnrichmentDefinitionEnrichment concerns information that does not explicitly appear in the original heritage information object. A source holder can accept enrichments after they have been approved.

ExplanationEnrichments have the following characteristics:

• Enrichments can be created by various roles or actors.• Enrichments can arise at various stages (management, editing, publication, use, etc.).• Enrichments can be additions or changes to information. (Note that only source holders

can delete information.)• Enrichments can be realised both automatically and manually.

Metadata


metadata

Enrichmentmetadata


Datasetmetadata


Business object



object


object

Information object


Digitized


describes


historical object

Material object


historical object




Enrichments can take the following forms:• corrections of typos and linguistic errors;• translations;• transcriptions (from handwritten sources);• Named Entity Recognition (NER);• alignments (links to or relations with other heritage information);• additional contextual information (who, what, where, when, why, how);• enhanced information;• Optical Character Recognition (OCR);• etc.

TermDefinitionA term is a word or a phrase which denotes a concept. Such concept-defining terms are included in a terminology source.

Explanation• Terms are used with or in the description of cultural-historical objects and information objects.• Terms can also refer to persons, places or periods.• Terms and concepts have sustainable identifiers.

Terms can relate to indirect geographical data, such as textual location identifiers, which can be provided with a geometry. Direct geographical data are geometries in the form of points, lines or planes which are related to a location on the surface of the earth. This type of data is treated as a separate discipline with its own standards, platforms and applications.

Terminology sourceDefinitionA source that consists of verified terms. Thesauruses and keyword lists are examples of terminology sources (derived from DEN’s ABC of Digital Heritage).

ExplanationA thesaurus is a terminology source of verified terms complemented by information about synonyms, more general, more specific, and related terms. Online thesauruses are useful for unlocking large amounts of digital information, for example by allowing users to browse the file with unified terms (derived from DEN’s ABC of Digital Heritage).

Dataset or data collectionDefinitionA dataset is a collection of heritage information objects.

ExplanationThere are datasets of information objects, enrichments, terms and metadata.


Heritage informationThe relationship between the concepts defined above is shown in the figure below. In its entirety, it shows what “heritage information” can be. Other layouts are conceivable, but this classification makes it possible to refer to the total information space using one term.

Source holders make digital heritage information available online as collections, or sub-collections, or as self-contained entities.

Heritage

Metadata

Metadataof cultural-

historical object

Metadatafor enrichment

Metadataof information

object

Metadatafor terminology

sources

Metadataof dataset

Enrichments

Digital information object

Analogueinformation

object

Informationobject


object


objectDataset

Terminology source

Term

Consists of

Describes

Describes

Describes

Digitized Contains

Describes

DescribesDescribes

Describes

Describes

Contains

Used with

Consists of

Cultural-historical

DEF versie...


7.3 Defining actors

ArchiMate defines a “business actor” as an organisational entity that is capable of performing behaviour. An actor can fulfil different business roles.

Actoren

User Heritageinstitution

Supplier

Roles

Business functions

Manage digital information objects

Publish dataset metadata

Publish digital information objects

Authentication and authorisation

Manage generic facility

Service to customers

Manage metadata

Manage cultural-historical object

metadata

Manage informationobject metadata

Manage enrichmentmetadata

Manage terminologysource metadata

Publish information object metadata

Generic facilitymanager Service providerSource holder Customer

Source holder of digitalinformation

Source holder of cultural-historical object metadata

Source holder of information object

metadata

Source holder ofenrichment metadata

Source holder ofterminology source

UserThere is a large variety of users of heritage information: • end users (citizens, businesses, teachers, pupils, etc.); • heritage institutions; • other government organisations (basic registers, ministries, Statistics Netherlands, etc.); • re-users, i.e. individuals or organisations who want to reuse heritage information, for example to develop an end product for a specific market or to provide a service. DERA does not focus on the information needs of specific users but on generic customer needs. Consequently, no specific target groups are defined. For DERA, the customer role suffices.

Heritage institutionA heritage institution is an organisation that manages heritage information. This mainly concerns libraries, museums, archives, scientific institutes and the audio-visual sector. In the Digital Heritage Network (NDE), a heritage institution can fulfil the roles of source holder, service provider, generic facilities manager, and customer.

SupplierA supplier is a party that selects, enriches or transforms heritage information for certain services. Examples are: • a party that supplies and realises software for heritage information management, such as a

collection management system or image bank; • a party that builds and maintains a portal.This may involve both commercial and non-commercial parties. DERA makes no distinction in this respect.


7.4 Defining roles

ArchiMate defines a “business role” as the responsibility for performing specified behaviour. The NDE roles are described in the figure below. In addition, there are external source holders, for example Wikidata and GeoNames, which are not recognized as roles. The generic facilities ensure that linking to these external sources is possible.

Actoren


Supplier

Roles

Business functions







Manage metadata


metadata









metadata



Source holderAn NDE source holder owns and is responsible for managing at least one source of heritage information. Based on the type of information, the following specialisations are distinguished: • source holder of digital information object; • source holder of cultural-historical object metadata; • source holder of information object metadata; • source holder of terminology source; • source holder of enrichment metadata.

Generic facility managerA facility is a standard solution (derived from NORA). In the NDE, the aim is to share facilities with others if possible. The scope of DERA is limited to the shared facilities. A subset of these are the generic facilities, which are only used jointly. In addition, source holders can offer the facilities they use, such as terminology sources, to third parties too.

Service providerA service provider is a person or organisation that provides for the delivery of a defined performance (service) to their environment (the customers). In DERA, “service provider” refers to the provision of services to end users or to internal services between source holders, generic facilities and service providers (derived from NORA).


CustomerA customer is “the person or organisation that receives a service. This can be a citizen, a company/institution or one of their staff, or a colleague from the same or another organisation” (derived from NORA). DERA only defines the reception of information services. Examples of NDE customers include source holders, service providers and service providers’ users.

7.5 Business functions

ArchiMate defines a “business function” as a collection of business behaviour based on a chosen set of criteria (typically required business resources and/or competencies).

The business functions that distinguish DERA as an ArchiMate model are described below. Subsequently, each the business functions is explained using a definition and requirements. Participation in the Digital Heritage Network entails additional requirements. The requirements describe whether additional tasks must be performed or if an activity is subject to other conditions. The objective is for actors to determine which roles they fulfil within the network and then see which business functions change as a result. This way it can be broadly determined whether there is an impact. Determining the size of that impact requires more information, particularly which requirements apply to the services. This is elaborated in a separate chapter.

Actoren


Supplier

Roles

Business functions







Manage metadata


metadata









metadata



Manage digital information objectenSee to the management of digital information objects such as scans, PDFs, films. Role: Source holder of digital information object.Requirements of Digital Heritage Network:No requirements are imposed from the NDE domain of Visibility. There are requirements from the Sustainable domain, but they fall outside the scope of DERA 2.0 because the emphasis in this release is mainly on Usable.


Manage metadataEnsure the quality of metadata.Based on the various types of metadata, the following specialisations can be distinguished:

Manage metadata of cultural-historical objects or information objectsRole: Source holder of cultural-historical object metadata. Requirements of Digital Heritage Network: • Use terminology sources. They are the keys to findability in the network, enabling “who”,

“what”, “where” and “when” queries. They also enable the use of standardized definitions when describing cultural-historical objects or information objects. By establishing connections with terms from terminology sources in metadating, findability is enhanced.

• When using terminology sources, create a link to the relevant term by means of a sustainable identifier.

• Ensure that metadating meets the minimum quality requirements (to be determined) regarding the metadating procedure.

• Accept meaningful enrichments supplied by third parties. • Ensure that the copyright status of the object is recorded. • Formulate the usage rights to the cultural-historical objects and information objects on the

individual level, based on your own understanding, knowledge and policy. These rights can even be different for different appearances of the object (physical, analogue, digital representation).

Manage enrichment metadataRole: Source holder of enrichment metadata. Requirements of Digital Heritage Network: • Make agreements about structuring and standards to allow enrichments to be automatically

accepted by a source holder of heritage metadata. • Ensure that enrichments are linked to heritage objects via sustainable identifiers. • Make sure that shared terminology sources are used for structured enrichments. • See to it that enrichments are stored independently from the website or collection management

system to ensure their preservation and long-term transferability. • Ensure that the copyright status of the enrichment is recorded.

Manage terminology source metadataRole: Source holder of terminology source.Requirements of Digital Heritage Network: • Make sure that each term has a sustainable identifier. • Create links to terms in other terminology sources. • Ensure that terminology sources are mutually consistent and have a content-related connection.

This requires agreements between source holders of terminology sources. This applies specifically to terminology sources that fall within the NDE’s sphere of influence. Use will also be made of external terminology sources, such as GeoNames. Reaching agreement with external terminology sources will be much more difficult, but the NDE can actively work on including references to external sources. Sources like DBpedia also offer possibilities in this respect.


• Make sure there is a solid process for passing on and processing change proposals for terminology sources that fall within the NDE’s sphere of influence. This means existing agreements will have to be tightened, because these terminology sources will be used more and more intensively by service providers and source holders. For example, users can suggest adding candidate terms.

Publish dataset metadataDatasets contain metadata, but they are themselves also described by metadata. Publishing these metadata ensures that customers can check which datasets are available, who provides them and what their quality is.Role: Source holder.Requirements of Digital Heritage Network: • Publish dataset metadata as Linked Data. • Ensure that metadata are open data which can always be used freely. The usage rights must

be machine-readable and must be explicitly indicated at the level of the entire dataset.

Publish metadata of cultural-historical objects and information objectsEnsure that metadata of information objects are made accessible to customers. Role: Source holder of information object metadata.Requirements: • Publish metadata as Linked Data. • Ensure that metadata are open data which can always be used freely. The usage rights must

be machine-readable and must be explicitly indicated at the level of the entire dataset.

Publish digital information objectsEnsure that digital heritage objects (such as scans, PDFs, films) are made accessible to customers.Role: Source holder of digital information objects. Requirements of Digital Heritage Network: • Ensure that the copyright status of the digital object is recorded. This concerns the rights

to use digital heritage objects (for example, limited access for reasons of legislation, copyright or privacy).

• Technology and copyright permitting, add a direct reference to the digital representation (file) wherever possible.

Authentication and authorisationEnsure that only those customers entitled to it have access to digital heritage objects such as scans, PDFs or films. Authentication verifies the customer’s identity. Authorisation determines whether the customer is entitled to the requested information.Role: Source holder of digital information object. Requirements of Digital Heritage Network: • Ensure that authentication and authorisation of customers is possible. This requires agreements

with service providers. When relevant agreements have been made, they will be elaborated in a subsequent version of DERA.


Manage generic facilityEnsure that generic facilities meet functional and non-functional requirements.The generic facilities support information exchange between source holders and service providers. The source holders and service providers must therefore formulate the requirements that the generic facilities must satisfy in order to enable them to provide services.Role: Generic facility manager Requirements of Digital Heritage Network: • Provide information about organisations and datasets in the network. • Provide information about standardized terms. • Monitor the availability of published metadata. This requires checking whether sustainable

identifiers are valid (“resolve”) to prevent customers’ queries from leading to dead links. The check can also be carried out by the source holder, who confirms with the generic facility that the check was performed on a certain date.

• Provide information about relationships between terms and digital information objects.

Service to customersEnsure that heritage information is made accessible, taking into account the needs of the target groups served by the service provider.Role: Service provider.Requirements of Digital Heritage Network: • Where possible, use heritage information that is made available by source holders

within the NDE. • Use the shared facilities to select heritage information. • Contribute to improving the accessibility of the network by enriching the metadata.


7.6 Linked Data

The scope of DERA 2.0 is largely limited to the business architecture. It describes what information is exchanged (functional requirements) and only to a limited extent which technical requirements are set for the exchange (non-functional requirements).However, the explicit choice has been made to assume the use of Linked Data. For publishing and connecting heritage information, DERA requires the application of Linked Data principles. This is necessary to be able to comply with principles 5 (“Ensure that heritage information refers”) and 6 (“Ensure that heritage information is referable”). To date, Linked Data is the only method which allows a variety of information from multiple source holders to be meaningfully integrated and made accessible to users.

This means: 1. Source holders shall use sustainable identifiers to identify their information, now and in the fu-

ture. A sustainable identifier is a URI that can be requested via HTTP, for example a “Cool URI” or a “persistent identifier”.

2. Source holders shall apply standards to provide information that is requested by customers using sustainable identifiers. Examples of such standards are RDF and SPARQL.

3. In their metadata, source holders shall refer to information from other source holders as much as possible. These references are sustainable identifiers (see 1) and lead to information that is provided according to standards (see 2).

4. Source holders shall make their metadata available under an open license. Metadata can be freely used. This ensures Linked Open Data.

5. Source holders shall make their digital information objects available with specific rights statements. This makes clear whether access is limited, for example for reasons of legislation, copyright or privacy. The rights statement can be indicated by referring to an (open) license or another form of legal expression.

6. Source holders shall refer to the license or rights statement in the metadata. This reference shall lead to a machine-readable, standardized definition (Principle 2).

7. Source holders shall register the reference to the license or rights statement with the dataset to which the information belongs.

In this way, DERA 2.0 signals the direction of future non-functional requirements. In a subsequent version of DERA, the application of Linked Data will be further elaborated, for example with regard to vocabularies or metadata standards.


7.7 Defining services

In the government sector, the term “service” is often used for a specific type of performance, such as the provision of a passport. In NORA the concept has a broader meaning: a service refers to anything that a government organisation does for a customer, who can be a citizen, a company or another organisation.

In DERA this broader meaning is conveyed by the ArchiMate concept of “product”. A product is a collection of services that is delivered to customers in accordance with a contract or set of agreements. The scope of DERA is limited to information products. The term “product” is often associated with physical products; we will therefore follow NORA and use the term “service”.

The scope of DERA 2.0 is limited to the business architecture. That is why in a product description, business services will be described, not application services. ArchiMate defines a business service as explicitly defined exposed business behaviour that is made available to the environment.

ArchiMate defines a contract as a formal or informal agreement between the supplier and the customer of a product. The agreement describes the rights and duties associated with the product. It also includes the functional and non-functional requirements related to the delivery of the product. In the context of the NDE, joint agreements are made which are included in DERA. DERA describes the requirements for each service, for example for publishing a term from a terminology source. An organisation may draw up more concrete requirements at the business service level (for example with regard to publishing a cultural-historical thesaurus).

This chapter defines which services are recognized in DERA. For each service, the requirements set by the NDE are described. A distinction is made between functional and non-functional requirements. Functional requirements describe which information must be provided. Non-functional requirements describe how this information must be delivered, for example which standards are used and which requirements apply with regard to availability, topicality, reliability and continuity. In DERA 2.0, an unambiguous choice has been made to use Linked Data. Many additional agreements have yet to be made about the way Linked Data can be applied. This will be done in close collaboration with pilot projects.

Published dataset metadataService where customers can request metadata of datasets from the source holder. Functional requirements: • The datasets that a source holder makes available are retrievable. • The datasets are described in a standardized manner.Non-functional requirements: • The datasets are provided with sustainable identifiers. • The source holder publishes the metadata as Linked Open Data.


Published digital information objectsService where customers can request digital information objects from the source holder. Functional requirements: • Customers can request a digital heritage object from the source holder using

a sustainable identifier.

Published cultural-historical object metadataService where customers can request metadata of digital information objects from the source holder.Non-functional requirements: • Customers can request metadata of cultural-historical objects from the source holder using a

sustainable identifier. • The source holder publishes the metadata as Linked Open Data.

Published information object metadataService where customers can request metadata of information objects from the source holder. Non-functional requirements: • Customers can request metadata of information objects from the source holder using a

sustainable identifier. • The source holder publishes the metadata as Linked Open Data.

Published terms from terminology sourcesService where customers can request terms from shared terminology sources. Functional requirements: • The meaning of a term is clear. • Any relationships with terms in other terminology sources are explicitly described. • The term is maintained. • The term is available in a sustainable manner.Non-functional requirements: • The term is provided with a sustainable identifier and can be searched using a

sustainable identifier. • The term is at least described with SKOS. A source holder may also offer their terms in

another standardized vocabulary. • Availability, reliability, scalability and accessibility are guaranteed. • The source holder publishes the metadata of terms as Linked Open Data.

Many different types of terms can be distinguished. All terms are at least described with SKOS so that the generic facilities can work with one standard for terms. A source holder may also offer other standardized vocabularies, which will often be dependent on the type of term. Two categories are described below. With the first category, SKOS will suffice. Additional vocabularies may be desirable for the second category.

Terms where the definition of concepts is centralThis often involves glossaries, for example the GTAA.

Terms that represent an object in realityExamples include historical persons, corporate bodies, events, and units of time. The same historical person can have identifiers and characteristics in different administrative systems. It must be possible to record that these different administrative realities relate to the same object.


For this purpose a core registration can be deployed. A core registration is a high-quality data file with explicit quality assurances. The core registration is considered (by law or by agreement) to be the authentic registration that other parties can refer to. Examples of core registrations are the basic registers established by law (land register; register of births, marriages and deaths; Chamber of Commerce, etc.). See NORA https://www.noraonline.nl/wiki/Basisregistratie.Other core registrations are, for example, the Actors Register of the National Archives or the Biography Portal of Huygens ING.

Published enrichment metadataService where customers can request metadata of enrichments. Functional requirements: • Enrichments are permanently available and can be referred to and retrieved separately. • Metadating of enrichments uses terms from shared terminology sources. • The registration method is agreed with source holders, so that they can automatically incorporate

the enrichments into their own registration. • The relationship between enrichment and source is retrievable. Non-functional requirements: • Enrichments have a sustainable identifier. • Enrichments use open standards. • The source holder publishes the metadata as Linked Open Data.

Authorised accessService which guarantees that only customers entitled to it have access to digital information objects.Functional requirements: • When digital information objects are requested, authentication and authorisation are applied to

objects with restricted access.Non-functional requirements: • The authentication and authorisation method is agreed with service providers.

Findable metadata of termsService that allows customers to find terms in a uniform, cross-sectoral way. Customers can request the meaning of a term and request its sustainable identifier. An example is the retrieval of terms from the GTAA of Sound and Vision. Functional requirements: • Publish the organisations that make datasets with heritage information available. • Publish datasets with heritage information. • Publish standardized terms. • Publish connections between digital information objects and metadata. • Prevent dead links with sustainable identifiers. • Indicate the relationship type when publishing relationships. • Relationship types defined by a source holder are related to generic terms that a customer

uses to select objects.Non-functional requirements: • Ensure availability, reliability, scalability and accessibility.


Digital Heritage Network Partners:

Service to customersService that answers customers’ information requests in a way that meets the needs of the target group.Functional requirements: • Handle customers’ information requests. • Track profiles of users. • Use shared terms for finding heritage objects. • Retrieve the metadata of heritage at the source. • Retrieve the digital heritage objects at the source. • Support the registration of enrichments by customers.Non-functional requirements: • Maintain indexes (if necessary to provide the desired performance). • Agree the authentication method with the source holder. • Agree the method of retrieving heritage objects with the source holder.

dera: digital heritage reference architecture · dera 2.0 is an elaboration of these principles,...

Documents