From ddafb75b24108b7e91f81d15b3079d0c667a5df6 Mon Sep 17 00:00:00 2001 From: Karin Bredenberg Date: Thu, 30 May 2019 09:16:02 +0200 Subject: [PATCH 01/10] Second take on METS profile for DIP New take on METS profile following how its made in e-ARK SIP --- profile/E-ARK-DIP.xml | 396 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 396 insertions(+) create mode 100644 profile/E-ARK-DIP.xml diff --git a/profile/E-ARK-DIP.xml b/profile/E-ARK-DIP.xml new file mode 100644 index 0000000..cb012f3 --- /dev/null +++ b/profile/E-ARK-DIP.xml @@ -0,0 +1,396 @@ + + + + https://earksip.dilcis.eu/profile/E-ARK-DIP.xml + E-ARK DIP METS Profile 2.0 + This is the extension of the E-ARK CSIP profile for creation of a E-ARK DIP. The profile describes the Dissemination Information Package (DIP) specification and the implementation of METS for packaging OAIS conformant Information Packages. The profile is accompanied with a textuall document explaning the details of use of this profile. + This will enable repository interoperability and assist in the management of the preservation of digital content. + 2019-05-31T12:00:00 + + DILCIS Board +
http://dilcis.eu/
+ info@dilcis.eu + + E-ARK CSIP METS Profile 2.0 + + + E-ARK DIP profile +

This profile together with the E-ARK SIP document describes an DIP conforming to the E-ARK SIP.

+ Principles for a package conforming to the Common Specification for Information Packages (CSIP) +

CSIP Principles

+ + + + +

No external schemas is used

+ + + +

The filepath must be decoded consistently throughout all file references within the information package.

+ + + + OAIS Package type + DILCIS Board + http://earkcsip.dilcis.eu/schema/CSIPVocabularyOAISPackageType.xml + Values for `@csip:OAISPACKAGETYPE` + +

Describes the OAIS type the package belongs to in the OAIS reference model.

+ + + + dmdSec status + DILCIS Board + http://earkcsip.dilcis.eu/schema/CSIPVocabularyStatus.xml + Values for `dmdSec/@STATUS` + +

Describes the status of the descriptive metadata section (dmdSec) which is supported by the profile.

+ + + + + + + + Package Identifier +

Note that the value of the `mets/@OBJID attribute` for the DIP is expected to be different from the SIP and AIP to reflect the creation of a new package.

+
+
METS XPath
mets/@OBJID
+
Cardinality
1..1
+
+ + + + + METS Profile +

The value is set to "https://earksip.dilcis.eu/profile/E-ARK-DIP.xml".

+
+
METS XPath
mets/@PROFILE
+
Cardinality
1..1
+
+ + + + + + + OAIS Package type information +

The in CSIP added attribute `@csip:OAISPACKAGETYPE` is used with the value "DIP".

+
+
METS XPath
metsHdr[@csip:OAISPACKAGETYPE=`DIP`]
+
Cardinality
1..1
+
+ + + + + + + Status of the descriptive metadata +

Indicates the status of the package using a fixed vocabulary. The status SHOULD in a DIP be set to "CURRENT".

+
+
METS XPath
dmdSec/@STATUS
+
Cardinality
0..1
+
+ + + + + + + Administrative metadata +

Follows the requirements in the CSIP profile.

+ + + + + + + File section +

Follows the requirements in the CSIP profile.

+ + + + + + + Structural description of the package +

Follows the requirements in the CSIP profile.

+ + + + + + + structLink +

Section not defined or used in CSIP or DIP, additional own uses may occur.

+ + + + + + + behaviorSec +

Section not defined or used in CSIP or DIP, additional own uses may occur.

+ + + + + + + + +

Requirements not stated in CSIP or DIP

+ + + + + + +

Requirements not stated in CSIP or DIP

+ + + + + + +

Requirements not stated in CSIP or DIP

+ + + + + + ESSArch (ETP, ETA, EPP, ECORE) + https://github.com/ESSolutions + +

A suite of tools for e-archiving and digital preservation. The tools provide functionality for producers to archive digital information, for archives to preserve digital information and for consumers to access archived information.

+ + +

ES Solutions - www.essolutions.se

+ + + + RODA + http://github.com/keeps/roda + +

RODA is a digital repository solution that delivers functionality for all the main units of the OAIS reference model. RODA is capable of ingesting, managing and providing access to the various types of digital objects produced by large corporations or public bodies. RODA is based on open-source technologies and is supported by existing standards such as the Open Archival Information System (OAIS), Metadata Encoding and Transmission Standard (METS), Encoded Archival Description (EAD), Dublin Core (DC) and PREMIS (Preservation Metadata).

+ + +

RODA is licensed under LGPLv3 for all source-code including interoperability libraries like SIP manipulation libraries.

+ + + + RODA-in + https://rodain.roda-community.org + +

RODA-in is a tool specially designed for producers and archivists to create Submission Information Packages (SIP) ready to be submitted to an Open Archival Information System (OAIS). The tool creates SIPs from files and folders available on the local file system.

+

+ RODA-in supports several Submission Information Package formats such as BagIt, E-ARK SIP and the Hungarian SIP format. +

+ + +

RODA-in is licensed under LGPLv3.

+ + + + + + + + + + + + + + RODA-in + 2.1.0-beta.7 + + + + + + + + + + + + + RODA-in + 2.1.0-beta.7 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + From 25c4f834185f4b922ffce6b0ce431bdc7536b3a8 Mon Sep 17 00:00:00 2001 From: Carl Wilson Date: Thu, 30 May 2019 14:00:49 +0100 Subject: [PATCH 02/10] FEAT - publication workflow - added `spec-publisher` submodule; --- .gitmodules | 3 +++ spec-publisher | 1 + 2 files changed, 4 insertions(+) create mode 100644 .gitmodules create mode 160000 spec-publisher diff --git a/.gitmodules b/.gitmodules new file mode 100644 index 0000000..4250980 --- /dev/null +++ b/.gitmodules @@ -0,0 +1,3 @@ +[submodule "spec-publisher"] + path = spec-publisher + url = https://github.com/carlwilson/spec-publisher.git diff --git a/spec-publisher b/spec-publisher new file mode 160000 index 0000000..eaccce2 --- /dev/null +++ b/spec-publisher @@ -0,0 +1 @@ +Subproject commit eaccce25d5714dd060eed2a4101747fb46557ed3 From 5b83c84ff455a7bde1ef0ebb1835d1aab61b4758 Mon Sep 17 00:00:00 2001 From: Carl Wilson Date: Fri, 31 May 2019 15:49:31 +0100 Subject: [PATCH 03/10] FEAT - publication workflow - added `spec-publisher` sub-module for common material; - add Travis-CI build through `.travis.yml`; - Markdown master files for site and PDF generation, `PDF.md`, `SITE.md`; - added `Vagrantfile` for local VM build; - shell scripts to generates site and PDF, `create-site.sh` and `create-pdf.sh`; and - added basic pandoc metadata. --- .gitmodules | 2 +- .travis.yml | 39 ++++++++++++++++++ PDF.md | 3 ++ SITE.md | 7 ++++ Vagrantfile | 89 +++++++++++++++++++++++++++++++++++++++++ create-pdf.sh | 30 ++++++++++++++ create-site.sh | 30 ++++++++++++++ pandoc/bibliography.bib | 55 +++++++++++++++++++++++++ pandoc/metadata.yaml | 35 ++++++++++++++++ 9 files changed, 289 insertions(+), 1 deletion(-) create mode 100644 .travis.yml create mode 100644 PDF.md create mode 100644 SITE.md create mode 100644 Vagrantfile create mode 100644 create-pdf.sh create mode 100644 create-site.sh create mode 100644 pandoc/bibliography.bib create mode 100644 pandoc/metadata.yaml diff --git a/.gitmodules b/.gitmodules index 4250980..3741434 100644 --- a/.gitmodules +++ b/.gitmodules @@ -1,3 +1,3 @@ [submodule "spec-publisher"] path = spec-publisher - url = https://github.com/carlwilson/spec-publisher.git + url = https://github.com/DILCISBoard/spec-publisher.git diff --git a/.travis.yml b/.travis.yml new file mode 100644 index 0000000..61af53a --- /dev/null +++ b/.travis.yml @@ -0,0 +1,39 @@ +dist: trusty +sudo: required +language: java +jdk: + - openjdk8 + - oraclejdk8 +before_install: + - sudo apt-get update + - sudo apt-get install -y texlive texlive-base texlive-latex-extra texlive-fonts-extra + python-virtualenv librsvg2-bin + - wget https://github.com/jgm/pandoc/releases/download/2.5/pandoc-2.5-linux.tar.gz + - tar -xzvf pandoc-2.5-linux.tar.gz + - rm pandoc-2.5-linux.tar.gz + - sudo mv pandoc-2.5 /opt + - sudo chmod +x /opt/pandoc-2.5/bin/pandoc + - sudo ln -s /opt/pandoc-2.5/bin/pandoc /usr/local/bin/pandoc + - sudo ln -s /opt/pandoc-2.5/bin/pandoc-citeproc /usr/local/bin/pandoc-citeproc +script: + - cd spec-publisher + - mvn clean package + - java -jar target/mets-profile-proc.jar ../profile/E-ARK-DIP.xml + - cd .. + - bash create-site.sh + - bash create-pdf.sh + - bundle install + - bundle exec jekyll build -s ./docs -d ./_site + - bundle exec htmlproofer ./_site --file-ignore /javadoc/ --only-4xx --check-html +deploy: + provider: pages + skip_cleanup: true + github_token: $GH_TOKEN + keep_history: true + local_dir: docs + on: + branch: master +env: + global: + - NOKOGIRI_USE_SYSTEM_LIBRARIES=true + - secure: OT1rmJ/+ywbA88+8PwAojxy3uvzUk07hdHVTYPgYIFnTC0KBKSjrZZkJ+cwX9xtqRmVDGCGyl+x3WYy02tS9jubC9zWkArxJl1lT9AvXFn4tXzDoF1lRjp2Bgk6uEmk8BZbERs6Ef7C3aFj+qwuoioPEhCQosxTrEqt7gVuAyASsFm+7q1HJqKWwAV6hPAEHVsrNFaQGg84XO+TMT3l3UlXetGD9IhZsbo+HGHqp0F2zlUSVaGfEHC5MJPHWO9QQRVoPY2ZT8okhL/zAxivhwnn3qFdQwVObBFs4Q5q0gBkg/ahQ4hMFISfTqvxlL52C7JTCFWxX2apZwUIL5FQ3PIsr5JUn3yPvZTXzOPDGkzHZmIWPeMdzB5HcJEl73WOyQ7z08hGiwTw46BDWlZUQ8JwFEquNadKvX3iJA5u/TGQ17uB2h3ZZlb/0RtBxPuK59RBwBKtt5jgHq+RBH6o+Z6KPt/zyKDbFt9m6SC/FBdvLSk3paMke5mdONDPro02Yl0i5bk+0XPYhm5Ci5IMU8vfWPEn5SgRcprQ9dBM7NOwAi0retvj4FxCPbIZRxaTxuYbvZdJ4ZTnw/mT8oMBsrAnM6cu+sF4a4szjNjLvjsOs+NReFXBz6qvSLUn6PWfTsRwmNK8/RK3W0PUi18oRY/masUo+Mp/r2RsQlNuslsI= diff --git a/PDF.md b/PDF.md new file mode 100644 index 0000000..979381d --- /dev/null +++ b/PDF.md @@ -0,0 +1,3 @@ +!INCLUDE "spec-publisher/res/md/common-intro.md" + +!INCLUDE "specification/index.md" diff --git a/SITE.md b/SITE.md new file mode 100644 index 0000000..6ffd0d0 --- /dev/null +++ b/SITE.md @@ -0,0 +1,7 @@ +--- +title: E-ARK Dissemination Information Package +--- + +!TOC + +!INCLUDE "PDF.md" diff --git a/Vagrantfile b/Vagrantfile new file mode 100644 index 0000000..e161ef2 --- /dev/null +++ b/Vagrantfile @@ -0,0 +1,89 @@ +# -*- mode: ruby -*- +# vi: set ft=ruby : + +# All Vagrant configuration is done below. The "2" in Vagrant.configure +# configures the configuration version (we support older styles for +# backwards compatibility). Please don't change it unless you know what +# you're doing. +Vagrant.configure("2") do |config| + # The most common configuration options are documented and commented below. + # For a complete reference, please see the online documentation at + # https://docs.vagrantup.com. + + # Every Vagrant development environment requires a box. You can search for + # boxes at https://vagrantcloud.com/search. + config.vm.box = "geerlingguy/debian9" + + # Disable automatic box update checking. If you disable this, then + # boxes will only be checked for updates when the user runs + # `vagrant box outdated`. This is not recommended. + # config.vm.box_check_update = false + + # Create a forwarded port mapping which allows access to a specific port + # within the machine from a port on the host machine. In the example below, + # accessing "localhost:8080" will access port 80 on the guest machine. + # NOTE: This will enable public access to the opened port + # config.vm.network "forwarded_port", guest: 80, host: 8080 + + # Create a forwarded port mapping which allows access to a specific port + # within the machine from a port on the host machine and only allow access + # via 127.0.0.1 to disable public access + # config.vm.network "forwarded_port", guest: 80, host: 8080, host_ip: "127.0.0.1" + + # Create a private network, which allows host-only access to the machine + # using a specific IP. + # config.vm.network "private_network", ip: "192.168.33.10" + + # Create a public network, which generally matched to bridged network. + # Bridged networks make the machine appear as another physical device on + # your network. + # config.vm.network "public_network" + + # Share an additional folder to the guest VM. The first argument is + # the path on the host to the actual folder. The second argument is + # the path on the guest to mount the folder. And the optional third + # argument is a set of non-required options. + # config.vm.synced_folder "../data", "/vagrant_data" + + # Provider-specific configuration so you can fine-tune various + # backing providers for Vagrant. These expose provider-specific options. + # Example for VirtualBox: + # + # config.vm.provider "virtualbox" do |vb| + # # Display the VirtualBox GUI when booting the machine + # vb.gui = true + # + # # Customize the amount of memory on the VM: + # vb.memory = "1024" + # end + # + # View the documentation for the provider you are using for more + # information on available options. + + # Enable provisioning with a shell script. Additional provisioners such as + # Puppet, Chef, Ansible, Salt, and Docker are also available. Please see the + # documentation for more information about their specific syntax and use. + config.vm.provision "shell", inline: <<-SHELL + apt-get -y update + apt-get -y upgrade + apt-get install -y texlive texlive-base texlive-latex-extra texlive-fonts-extra python-virtualenv librsvg2-bin + if [ ! -d /opt/pandoc-2.5 ] + then + cd /tmp + wget https://github.com/jgm/pandoc/releases/download/2.5/pandoc-2.5-linux.tar.gz + tar -xzvf pandoc-2.5-linux.tar.gz + mv pandoc-2.5 /opt + chmod +x /opt/pandoc-2.5/bin/pandoc + ln -s /opt/pandoc-2.5/bin/pandoc /usr/local/bin/pandoc + ln -s /opt/pandoc-2.5/bin/pandoc-citeproc /usr/local/bin/pandoc-citeproc + fi + if [ ! -d /home/vagrant/.pandoc/templates ] + then + sudo -u vagrant mkdir -p /home/vagrant/.pandoc/templates + sudo -u vagrant cp /vagrant/spec-publisher/pandoc/templates/eisvogel.latex /home/vagrant/.pandoc/templates/eisvogel.latex + fi + cd /vagrant + sudo -u vagrant /vagrant/create-site.sh + sudo -u vagrant /vagrant/create-pdf.sh + SHELL +end diff --git a/create-pdf.sh b/create-pdf.sh new file mode 100644 index 0000000..0271f13 --- /dev/null +++ b/create-pdf.sh @@ -0,0 +1,30 @@ +#!/usr/bin/env bash +#!/usr/bin/env bash +echo "Generating PDF document from markdown" +SCRIPT_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" +cd "$SCRIPT_DIR" || exit + +if [ ! -d ~/.pandoc/templates ] +then + mkdir -p ~/.pandoc/templates +fi +cp spec-publisher/pandoc/templates/eisvogel.latex ~/.pandoc/templates/eisvogel.latex + +if [ ! -d "$SCRIPT_DIR/docs/pdf" ] +then + mkdir -p "$SCRIPT_DIR/docs/pdf/" +fi + +bash "$SCRIPT_DIR/spec-publisher/utils/create-venv.sh" +source "$SCRIPT_DIR/.venv/markdown/bin/activate" +markdown-pp PDF.md -o docs/eark-dip-pdf.md -e tableofcontents +deactivate + +cd docs || exit +pandoc --from gfm \ + --template eisvogel \ + --listings \ + --toc \ + eark-dip-pdf.md \ + --metadata-file ../pandoc/metadata.yaml \ + -o pdf/eark-dip.pdf diff --git a/create-site.sh b/create-site.sh new file mode 100644 index 0000000..7f1317e --- /dev/null +++ b/create-site.sh @@ -0,0 +1,30 @@ +#!/usr/bin/env bash +echo "Generating GitHub pages site from markdown" +SCRIPT_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" +cd "$SCRIPT_DIR" || exit + +if [ ! -d ./docs ] +then + mkdir ./docs +fi + +if [ -d ./docs/figs ] +then + rm -rf ./docs/figs +fi + +if [ -e ./docs/index.md ] +then + rm docs/index.md +fi + +bash "$SCRIPT_DIR/spec-publisher/utils/create-venv.sh" +source "$SCRIPT_DIR/.venv/markdown/bin/activate" +markdown-pp SITE.md -o docs/index.md +deactivate + +cp -R specification/media docs/ +cp -R spec-publisher/res/md/figs docs/ +cp -R profile docs/ +cp -R archive docs/ +cp -R examples docs/ diff --git a/pandoc/bibliography.bib b/pandoc/bibliography.bib new file mode 100644 index 0000000..34b8a00 --- /dev/null +++ b/pandoc/bibliography.bib @@ -0,0 +1,55 @@ +% This file was created with JabRef 2.10. +% Encoding: ISO8859_1 + + +@Manual{csip-2.0.0-DRAFT, + Title = {Common Specification for Information Packages (CSIP)}, + Author = {Karin Bredenberg and Bj{\"o}rn Skog and Anders Bo Nielsen and Kathrine Hougaard Edsen Johansen and Alex Thirifays and Sven Schlarb and Andrew Wilson and Tarvo K{\"a}rberg and Kuldar Aas and Luis Faria and Helder Silva and Miguel Ferreira and Carl Wilson}, + Edition = {2.0.0-DRAFT}, + Month = {July}, + Organization = {Digital Information LifeCycle Interoperability Standard Board (DILCIS Board)}, + Year = {2018}, + + Journal = {ERCIM News}, + Number = {114}, + Owner = {Sven Schlarb}, + Timestamp = {2018.06.28}, + Url = {http://earkcsip.dilcis.eu} +} + +@Manual{e-ark-d4.4, + Title = {D4.4 SIP-AIP Conversion Component}, + Author = {Luis Faria and Miguel Ferreira and Jan R{\"o}rden and Sven Schlarb}, + Year = {2017}, + + Timestamp = {2018.12.12}, + Url = {http://www.eark-project.com/resources/project-deliverables/89-d44} +} + +@Manual{OAIS2012, + Title = {{Reference Model for an Open Archival Information System}}, + Author = {OAIS}, + Edition = {CCSDS 650.0-M-2 (Magenta Book)}, + Month = {June}, + Organization = {CCSDS - Consultative Committee for Space Data Systems}, + Year = {2012}, + + Citeulike-article-id = {4688260}, + Citeulike-linkout-0 = {http://public.ccsds.org/publications/archive/650x0b1.pdf}, + Keywords = {oais, referencemodel, referenzmodell}, + Posted-at = {2009-05-31 11:14:14}, + Priority = {0}, + Url = {http://public.ccsds.org/publications/archive/650x0b1.pdf} +} + +@Manual{premis3.0-2017, + Title = {PREMIS Data Dictionary for Preservation Metadata, Version 3.0}, + Author = {PREMIS}, + Month = {December}, + Organization = {The Library of Congress}, + Year = {2017}, + + Timestamp = {2018.12.12}, + Url = {https://www.loc.gov/standards/premis/v3/index.html} +} + diff --git a/pandoc/metadata.yaml b/pandoc/metadata.yaml new file mode 100644 index 0000000..92754dd --- /dev/null +++ b/pandoc/metadata.yaml @@ -0,0 +1,35 @@ +--- +title: 'E-ARK Dissemination Information Packages (DIP)' +abstract: | + The DIP format is the last in sequence of the three IP formats defined + in the OAIS reference model. As with the two others, the SIP and the AIP + format, the E-ARK DIP builds upon the same foundation - the Common + Specification for Information Packages. The definition of an E-ARK DIP + is led by practical access considerations: a DIP is an Information + Package which is ready to be processed by its designated Access + Software; if it is not suited for processing and rendering by its + designated Access Software, it is not (yet) a DIP. + In order to meet the stated access scope, much of the specification + deals with scenario descriptions that are associated with specific + Content Information Types (Databases, Data warehouses, Electronic + Records Managements Systems, Simple File-System Based Records, and Geodata). +margin-left: 1in +margin-right: 1in + +date: "31.05.2019" +toc-title: 'Table of contents' +titlepage: true +titlepage-color: "186b9e" +titlepage-text-color: "3adeca" +titlepage-rule-color: "3adeca" +titlepage-rule-height: 1 +logo: ../spec-publisher/pandoc/img/DILCISlogo.png +footer-center: Version 2.0.0 +footer-left: 31.05.2019 +header-right: DILCIS Board +version: 2.0.0 +bibliography: ../pandoc/bibliography.bib +reference-section-title: 'Bibliography' +autoSectionLabels: True +listings-disable-line-numbers: True +... From 3958591d22e21ff058641652a98a8930c95014e1 Mon Sep 17 00:00:00 2001 From: Carl Wilson Date: Fri, 31 May 2019 15:53:59 +0100 Subject: [PATCH 04/10] FIX - create scripts now executable. --- create-pdf.sh | 0 create-site.sh | 0 2 files changed, 0 insertions(+), 0 deletions(-) mode change 100644 => 100755 create-pdf.sh mode change 100644 => 100755 create-site.sh diff --git a/create-pdf.sh b/create-pdf.sh old mode 100644 new mode 100755 diff --git a/create-site.sh b/create-site.sh old mode 100644 new mode 100755 From 57d82ee96c5ba4ef2e63ac5198c8a65f65598678 Mon Sep 17 00:00:00 2001 From: Carl Wilson Date: Fri, 31 May 2019 15:56:01 +0100 Subject: [PATCH 05/10] FIX - updated spec publisher. - removed TOC; - config for GH pages; - fixed dummy profile reqs; - added includes instead of embedded tables; - removed wierd unicode invisible spaces; - moved acknowledgements to end for now; and - added generated tables and examples. --- SITE.md | 2 - docs/_config.yml | 12 + profile/E-ARK-DIP.xml | 211 +++++------ spec-publisher | 2 +- specification/appendices/examples/examples.md | 64 ++++ .../appendices/requirements/requirements.md | 11 + specification/appendices/schema/schema.md | 27 ++ .../metadata/mets/amdsec/requirements.md | 3 + .../metadata/mets/dmdsec/examples.md | 10 + .../metadata/mets/dmdsec/requirements.md | 3 + .../metadata/mets/filesec/requirements.md | 3 + .../metadata/mets/mets-root/examples.md | 16 + .../metadata/mets/mets-root/requirements.md | 4 + .../metadata/mets/metshdr/examples.md | 12 + .../metadata/mets/metshdr/requirements.md | 3 + .../metadata/mets/structmap/requirements.md | 3 + specification/index.md | 355 +++++------------- 17 files changed, 379 insertions(+), 362 deletions(-) create mode 100644 docs/_config.yml create mode 100644 specification/appendices/examples/examples.md create mode 100644 specification/appendices/requirements/requirements.md create mode 100644 specification/appendices/schema/schema.md create mode 100644 specification/implementation/metadata/mets/amdsec/requirements.md create mode 100644 specification/implementation/metadata/mets/dmdsec/examples.md create mode 100644 specification/implementation/metadata/mets/dmdsec/requirements.md create mode 100644 specification/implementation/metadata/mets/filesec/requirements.md create mode 100644 specification/implementation/metadata/mets/mets-root/examples.md create mode 100644 specification/implementation/metadata/mets/mets-root/requirements.md create mode 100644 specification/implementation/metadata/mets/metshdr/examples.md create mode 100644 specification/implementation/metadata/mets/metshdr/requirements.md create mode 100644 specification/implementation/metadata/mets/structmap/requirements.md diff --git a/SITE.md b/SITE.md index 6ffd0d0..5830e04 100644 --- a/SITE.md +++ b/SITE.md @@ -2,6 +2,4 @@ title: E-ARK Dissemination Information Package --- -!TOC - !INCLUDE "PDF.md" diff --git a/docs/_config.yml b/docs/_config.yml new file mode 100644 index 0000000..ccf01c0 --- /dev/null +++ b/docs/_config.yml @@ -0,0 +1,12 @@ +github: [metadata] +encoding: UTF-8 +kramdown: + input: GFM + hard_wrap: false +future: true +jailed: false +theme: jekyll-theme-primer +gfm_quirks: paragraph_end +exclude: + - specification + - contents.md diff --git a/profile/E-ARK-DIP.xml b/profile/E-ARK-DIP.xml index cb012f3..893072e 100644 --- a/profile/E-ARK-DIP.xml +++ b/profile/E-ARK-DIP.xml @@ -1,15 +1,15 @@ - https://earksip.dilcis.eu/profile/E-ARK-DIP.xml E-ARK DIP METS Profile 2.0 @@ -106,42 +106,43 @@ - + Administrative metadata -

Follows the requirements in the CSIP profile.

+

The DIP <amdSec> element should comply with amdSec requirements in the CSIP profile.

 - + File section -

Follows the requirements in the CSIP profile.

+

The DIP fileSec element should comply with fileSec requirements in the CSIP profile.

 - - - Structural description of the package -

Follows the requirements in the CSIP profile.

- - + + + Structural description of the package +

The DIP structMap element should comply with structMap requirements in the CSIP profile.

+ + - + structLink

Section not defined or used in CSIP or DIP, additional own uses may occur.

- +

Information regarding the structural links is found in the METS Primer

 - + behaviorSec

Section not defined or used in CSIP or DIP, additional own uses may occur.

+

Information regarding the behavior section is found in the METS Primer

 @@ -243,7 +244,7 @@ - - RODA-in @@ -265,105 +266,105 @@ - - - - - - - - @@ -371,22 +372,22 @@ - - - - diff --git a/spec-publisher b/spec-publisher index eaccce2..cdfe931 160000 --- a/spec-publisher +++ b/spec-publisher @@ -1 +1 @@ -Subproject commit eaccce25d5714dd060eed2a4101747fb46557ed3 +Subproject commit cdfe9315f6d6b86881db44350d840fba7594fb3b diff --git a/specification/appendices/examples/examples.md b/specification/appendices/examples/examples.md new file mode 100644 index 0000000..0d6fb5e --- /dev/null +++ b/specification/appendices/examples/examples.md @@ -0,0 +1,64 @@ + +**Example 1:** Example of a whole METS document describing an dissimination information package with no representations. + +```xml + + + + RODA-in + 2.1.0-beta.7 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +``` + diff --git a/specification/appendices/requirements/requirements.md b/specification/appendices/requirements/requirements.md new file mode 100644 index 0000000..a6a5c89 --- /dev/null +++ b/specification/appendices/requirements/requirements.md @@ -0,0 +1,11 @@ +| ID | Name & Location | Description & usage | Cardinality & Level | +| -- | --------------- | ------------------- | ------------------- | +| **DIP1** | **Package Identifier**
`mets/@OBJID` | Note that the value of the `mets/@OBJID attribute` for the DIP is expected to be different from the SIP and AIP to reflect the creation of a new package. | **1..1**
MUST | +| **DIP2** | **METS Profile**
`mets/@PROFILE` | The value is set to "https://earksip.dilcis.eu/profile/E-ARK-DIP.xml". | **1..1**
MUST | +| **DIP3** | **OAIS Package type information**
`metsHdr[@csip:OAISPACKAGETYPE=`DIP`]` | The in CSIP added attribute `@csip:OAISPACKAGETYPE` is used with the value "DIP".
**See also:** OAIS Package type | **1..1**
MUST | +| **DIP4** | **Status of the descriptive metadata**
`dmdSec/@STATUS` | Indicates the status of the package using a fixed vocabulary. The status SHOULD in a DIP be set to "CURRENT".
**See also:** dmdSec status | **0..1**
SHOULD | +| **REF_CSIP_1** | **Administrative metadata**
| The DIP element should comply with
requirements in the CSIP profile. |
SHOULD | +| **REF_CSIP_2** | **File section**
| The DIP element should comply with
requirements in the CSIP profile. |
SHOULD | +| **REF_CSIP_3** | **Structural description of the package**
| The DIP element should comply with
requirements in the CSIP profile. |
SHOULD | +| **REF_METS_1** | **structLink**
| Section not defined or used in CSIP or DIP, additional own uses may occur. |
MAY | +| **REF_METS_2** | **behaviorSec**
| Section not defined or used in CSIP or DIP, additional own uses may occur. |
MAY | diff --git a/specification/appendices/schema/schema.md b/specification/appendices/schema/schema.md new file mode 100644 index 0000000..57de1dd --- /dev/null +++ b/specification/appendices/schema/schema.md @@ -0,0 +1,27 @@ +## External Schema + +### +**Location:** http://example.com
+**Context:**
+**Note:**
+No external schemas is used
+ +## Controlled Vocabularies + +### OAIS Package type + +**Maintained By:** DILCIS Board
+**Location:** http://earkcsip.dilcis.eu/schema/CSIPVocabularyOAISPackageType.xml
+**Context:** Values for `@csip:OAISPACKAGETYPE`
+**Description:**
+Describes the OAIS type the package belongs to in the OAIS reference model.
+ + +### dmdSec status + +**Maintained By:** DILCIS Board
+**Location:** http://earkcsip.dilcis.eu/schema/CSIPVocabularyStatus.xml
+**Context:** Values for `dmdSec/@STATUS`
+**Description:**
+Describes the status of the descriptive metadata section (dmdSec) which is supported by the profile.
+ diff --git a/specification/implementation/metadata/mets/amdsec/requirements.md b/specification/implementation/metadata/mets/amdsec/requirements.md new file mode 100644 index 0000000..9a3ab4f --- /dev/null +++ b/specification/implementation/metadata/mets/amdsec/requirements.md @@ -0,0 +1,3 @@ +| ID | Name & Location | Description & usage | Cardinality & Level | +| -- | --------------- | ------------------- | ------------------- | +| **REF_CSIP_1** | **Administrative metadata**
| The DIP element should comply with
requirements in the CSIP profile. |
SHOULD | diff --git a/specification/implementation/metadata/mets/dmdsec/examples.md b/specification/implementation/metadata/mets/dmdsec/examples.md new file mode 100644 index 0000000..4214602 --- /dev/null +++ b/specification/implementation/metadata/mets/dmdsec/examples.md @@ -0,0 +1,10 @@ + +**Example:** METS example of referencing the descriptive metadata which is described with an EAD document + +```xml + + + + +``` + diff --git a/specification/implementation/metadata/mets/dmdsec/requirements.md b/specification/implementation/metadata/mets/dmdsec/requirements.md new file mode 100644 index 0000000..31d6738 --- /dev/null +++ b/specification/implementation/metadata/mets/dmdsec/requirements.md @@ -0,0 +1,3 @@ +| ID | Name & Location | Description & usage | Cardinality & Level | +| -- | --------------- | ------------------- | ------------------- | +| **DIP4** | **Status of the descriptive metadata**
`dmdSec/@STATUS` | Indicates the status of the package using a fixed vocabulary. The status SHOULD in a DIP be set to "CURRENT".
**See also:** dmdSec status | **0..1**
SHOULD | diff --git a/specification/implementation/metadata/mets/filesec/requirements.md b/specification/implementation/metadata/mets/filesec/requirements.md new file mode 100644 index 0000000..20f486b --- /dev/null +++ b/specification/implementation/metadata/mets/filesec/requirements.md @@ -0,0 +1,3 @@ +| ID | Name & Location | Description & usage | Cardinality & Level | +| -- | --------------- | ------------------- | ------------------- | +| **REF_CSIP_2** | **File section**
| The DIP element should comply with
requirements in the CSIP profile. |
SHOULD | diff --git a/specification/implementation/metadata/mets/mets-root/examples.md b/specification/implementation/metadata/mets/mets-root/examples.md new file mode 100644 index 0000000..aa01786 --- /dev/null +++ b/specification/implementation/metadata/mets/mets-root/examples.md @@ -0,0 +1,16 @@ + +**Example:** METS root element showing use of `csip:@OTHERTYPE` attribute when an appropriate package content category value is not available in the vocabulary. The `@TYPE` attribute value is set to OTHER. + +```xml + + +``` + + +**Example:** METS root element illustrating the use of a custom `csip:@OTHERCONTENTINFORMATIONTYPE` attribute value when the correct content type value does note exist in the vocabulary. The `csip:@CONTENTINFORMATIONTYPE` attribute value is set to OTHER. + +```xml + + +``` + diff --git a/specification/implementation/metadata/mets/mets-root/requirements.md b/specification/implementation/metadata/mets/mets-root/requirements.md new file mode 100644 index 0000000..40365a7 --- /dev/null +++ b/specification/implementation/metadata/mets/mets-root/requirements.md @@ -0,0 +1,4 @@ +| ID | Name & Location | Description & usage | Cardinality & Level | +| -- | --------------- | ------------------- | ------------------- | +| **DIP1** | **Package Identifier**
`mets/@OBJID` | Note that the value of the `mets/@OBJID attribute` for the DIP is expected to be different from the SIP and AIP to reflect the creation of a new package. | **1..1**
MUST | +| **DIP2** | **METS Profile**
`mets/@PROFILE` | The value is set to "https://earksip.dilcis.eu/profile/E-ARK-DIP.xml". | **1..1**
MUST | diff --git a/specification/implementation/metadata/mets/metshdr/examples.md b/specification/implementation/metadata/mets/metshdr/examples.md new file mode 100644 index 0000000..16ed174 --- /dev/null +++ b/specification/implementation/metadata/mets/metshdr/examples.md @@ -0,0 +1,12 @@ + +**Example:** METS agent example of the mandatory agent + +```xml + + + RODA-in + 2.1.0-beta.7 + + +``` + diff --git a/specification/implementation/metadata/mets/metshdr/requirements.md b/specification/implementation/metadata/mets/metshdr/requirements.md new file mode 100644 index 0000000..3d98048 --- /dev/null +++ b/specification/implementation/metadata/mets/metshdr/requirements.md @@ -0,0 +1,3 @@ +| ID | Name & Location | Description & usage | Cardinality & Level | +| -- | --------------- | ------------------- | ------------------- | +| **DIP3** | **OAIS Package type information**
`metsHdr[@csip:OAISPACKAGETYPE=`DIP`]` | The in CSIP added attribute `@csip:OAISPACKAGETYPE` is used with the value "DIP".
**See also:** OAIS Package type | **1..1**
MUST | diff --git a/specification/implementation/metadata/mets/structmap/requirements.md b/specification/implementation/metadata/mets/structmap/requirements.md new file mode 100644 index 0000000..ef76cd2 --- /dev/null +++ b/specification/implementation/metadata/mets/structmap/requirements.md @@ -0,0 +1,3 @@ +| ID | Name & Location | Description & usage | Cardinality & Level | +| -- | --------------- | ------------------- | ------------------- | +| **REF_CSIP_3** | **Structural description of the package**
| The DIP element should comply with
requirements in the CSIP profile. |
SHOULD | diff --git a/specification/index.md b/specification/index.md index 2eb9588..fd79f23 100644 --- a/specification/index.md +++ b/specification/index.md @@ -1,86 +1,24 @@ -# I. Acknowledgements -The E-ARK Dissemination Information Package (DIP) Specification was first developed within the E-ARK project in 2014 – 2017. E-ARK was an EC-funded pilot action project in the Competiveness and Innovation Programme 2007- 2013, Grant Agreement no. 620998 under the Policy Support Programme. - -Since the scope of the E-ARK 2014-2017 DIP specification was linked to a reference implementation, specific Content Information Types, and product development with pilot actions it was a 100 pages long document. The scope of this E-ARK DIP Specification is not the same, the document has been shortened heavily and therefore we currently only have two authors credited. This does not mean that the current authors are the only ones behind this specification. We rely heavily on the work previously done. - -The authors of this specification would like to thank all national archives, tool developers and other stakeholders who provided valuable knowledge about their requirements for information packages and feedback to this and previous versions of the specification. - - -# II. Contact & Feedback -The E-ARK DIP specification is maintained by the Digital Information LifeCycle Interoperability Standard Board (DILCIS Board). For further information about the DILCIS Board or feedback on the current document please consult the website http://www.dilcis.eu/ or https://github.com/dilcisboard or contact us at   - -# III. Authors - - -| Name | Organisation | -| -------------------------------- | -------------------------------------------------- | -| Anders Bo Nielsen | Danish National Archives | -| Phillip Tømmerholt | Danish National Archives | - - -# IV. Revision History - -| Revision No. | Date | Authors(s) | Organisation | Description | -|--------------|------------|----------------------------------|--------------|----------------------------| -| 1.0 | 20.12.2018 | Phillip Tømmerholt
Anders Bo Nielsen | DNA | Review version | -| 1.0.1 | 20.03.2019 | Phillip Tømmerholt
Anders Bo Nielsen | DNA | Corrected typos | -| 1.0.2 | 26.04.2019 | Phillip Tømmerholt
Anders Bo Nielsen | DNA | Corrected typos | -| 1.1.0 | 27.05.2019 | Phillip Tømmerholt
Anders Bo Nielsen | DNA | Align with CSIP | - - # Introduction - -## Scope and purpose - -Key objectives of this E-ARK DIP specification are: - -- To define a generic structure of the DIP format in a way that it is suitable for a wide variety of archival records, such as document and image collections, databases or geographical data. -- To recommend a set of metadata related to the structural and the access aspects of the DIP. - -## Relations to other E-ARK specifications -The E-ARK DIP specification can be found in the following model (see Figure 1): - -![Figure 1](./media/Fig1DIP.svg) - - -_Common Specification for Information Packages_ - -Common Specification for Information Packages (CSIP) identifies and standardises the common aspects of information packages (SIP/AIP/DIP) which are equally relevant and implemented by any of the functional entities of the overall digital preservation process (i.e. Ingest, Data Management, Archival Storage, Preservation Planning, Access etc). -CSIP is a separate document as all the grey boxes are. Therefore, this E-ARK DIP specification does not aim at repeating the information presented there – only the information that is absolutely necessary to understand the DIP specification will be mentioned here. - -_SIP, AIP, and DIP Specification_ - -SIP, AIP, and DIP specifications are in some respects outlined to be "on the same level" in the hierarchical order of specifications, since they alle need to be compliant to the Common Specification for Information Packages. -But following the OAIS reference model, the above model can also be read from left to right since a DIP is *derived from one or more AIPs*. -Therefore there are some cases where the DIP specification heavily relies on what is stated in the SIP and AIP specifications. -Therefore, this E-ARK DIP specification does not aim at repeating the information presented there – only the information that is absolutely necessary to understand the DIP specification will be mentioned here. - - -_Content Information Type Specifications_ - -Content Information Type Specifications are content-dependent specifications which include detailed information on how content, metadata, and documentation for specific Content Information Types -(for example ERMS or relational databases) is to be handled within the SIP, AIP and DIP. It is in these specifications where most implementation issues are dealt with. - ## Definition of a DIP The OAIS reference model defines a DIP as: -> An Information Package, derived from one or more AIPs, and sent by Archives to the Consumer in response to a request to the OAIS. +> An Information Package, derived from one or more AIPs, and sent by Archives to the Consumer in response to a request to the OAIS. -The definition of an E-ARK DIP is that it corresponds to a CSIP which is ready to be processed by its designated Access Software; if it is not suited for processing and rendering by its designated Access Software, it is not (yet) a DIP. -This is a very generic, but handy, definition. To be more specific, an E-ARK DIP is: +The definition of an E-ARK DIP is that it corresponds to a CSIP which is ready to be processed by its designated Access Software; if it is not suited for processing and rendering by its designated Access Software, it is not (yet) a DIP. +This is a very generic, but handy, definition. To be more specific, an E-ARK DIP is: -- an IP which is sent (or is ready to be sent) to the user in an Access environment; +- an IP which is sent (or is ready to be sent) to the user in an Access environment; - supported by tools, i.e. can be rendered by Access Software. -First of all, the DIP looks like the AIP: It replicates the structure of the AIP from which it is derived. It also inherits metadata as well as the intellectual entities of the AIP. -An E-ARK AIP may in its entirety therefore also be a E-ARK DIP, however in most cases it is necessary to convert from an AIP to a DIP. The DIP allows for example for the inclusion of new DIP representation formats, which are more user-friendly than the AIP formats that are intended for long-term preservation purposes. +First of all, the DIP looks like the AIP: It replicates the structure of the AIP from which it is derived. It also inherits metadata as well as the intellectual entities of the AIP. +An E-ARK AIP may in its entirety therefore also be a E-ARK DIP, however in most cases it is necessary to convert from an AIP to a DIP. The DIP allows for example for the inclusion of new DIP representation formats, which are more user-friendly than the AIP formats that are intended for long-term preservation purposes. It also allows for the updating of the metadata as well as for the addition of new metadata elements. Representation Information, which is required for rendering and understanding the intellectual content, might also be added, and as a direct consequence, there may be a need for new folders and files, for example within the ‘Documentation’ folder. -# Structure +# Structure The folder structure of an E-ARK DIP must comply with the requirements for the folder structure for a CSIP, see [Folder structure of the CSIP](http://earkcsip.dilcis.eu/#41-folder-structure-of-the-csip). The CSIP folder structure and its requirements is visualised in the figure below: @@ -88,27 +26,26 @@ The CSIP folder structure and its requirements is visualised in the figure below ![IP Folder Structure](./media/Fig2DIP.svg) - Green boxes represent folders -- Red boxes represent files. +- Red boxes represent files. - Boxes with full lines represent mandatory files/folders -- Boxes with dotted lines represent optional files/folders. +- Boxes with dotted lines represent optional files/folders. -As can be seen from the figure - the requirements for the folder structure for a CSIP is at a bare minimum and makes it possible to have several extra optional folders and files in a CSIP (see boxes with dotted lines). -The first thing to be said about the E-ARK DIP structure in regard to CSIP structure is that an E-ARK DIP will always consist of some of those files and folders that are optional in the CSIP minimum structure. -There must be data to disseminate. Since the definition of an E-ARK DIP is that it corresponds to a CSIP which is ready to be processed by its designated Access Software, this leaves the question as to which data -in the CSIP should be chosen to be encompassed in the E-ARK DIP. +As can be seen from the figure - the requirements for the folder structure for a CSIP is at a bare minimum and makes it possible to have several extra optional folders and files in a CSIP (see boxes with dotted lines). +The first thing to be said about the E-ARK DIP structure in regard to CSIP structure is that an E-ARK DIP will always consist of some of those files and folders that are optional in the CSIP minimum structure. +There must be data to disseminate. Since the definition of an E-ARK DIP is that it corresponds to a CSIP which is ready to be processed by its designated Access Software, this leaves the question as to which data +in the CSIP should be chosen to be encompassed in the E-ARK DIP. -It is possible that an AIP in its current state and in its entirety can be delivered to a Consumer as is and still be considered an E-ARK DIP. -That E-ARK DIP can contain the submission representation, and one or more preservation representations. Often, however, the OAIS is interested in leaving out irrelevant data and metadata and only present the +It is possible that an AIP in its current state and in its entirety can be delivered to a Consumer as is and still be considered an E-ARK DIP. +That E-ARK DIP can contain the submission representation, and one or more preservation representations. Often, however, the OAIS is interested in leaving out irrelevant data and metadata and only present the Consumer with the data and metadata that the Consumer is interested in. This could be isolated to the content in one single representation in an E-ARK AIP, or maybe only a portion of a single representation in an E-ARK AIP. Maybe even only one specific file. The point here is that a plethora of different E-ARK DIPs can be created out of an E-ARK AIP or several E-ARK AIPs. +# Content Information Types -# **​Content Information Types** - -Content Information is *“A set of information that is the original target of preservation or -that includes part or all of that information. It is an Information Object composed of its Content +Content Information is *“A set of information that is the original target of preservation or +that includes part or all of that information. It is an Information Object composed of its Content Data Object and its Representation Information*” according to the OAIS Reference Model. -A Content Information Type can therefore be understood as a category of Content Information, for example +A Content Information Type can therefore be understood as a category of Content Information, for example relational databases, scientific data, electronic records management systems, digitised maps, etc.. According to the Common Specification for Information Package it is possible to [create specifications for @@ -119,19 +56,18 @@ Content Information Types](http://earkcsip.dilcis.eu/#61-content-information-typ - The DIP section should describe how to register access software - The DIP section could mention and list relevant access software for the Content Information Type - -# **​Metadata** +# Metadata The DIP metadata is based upon the existing CSIP, E-ARK SIP and E-ARK AIP specifications. -The metadata descriptions provided in this document cover the three core metadata categories: +The metadata descriptions provided in this document cover the three core metadata categories: - structural (see METS) - preservation (see PREMIS) - descriptive (see EAD) -It must be stated that the CSIP allows for and makes a disctinction between preservation metadata and descriptive metadata (or Descriptive Information according to OAIS). +It must be stated that the CSIP allows for and makes a distinction between preservation metadata and descriptive metadata (or Descriptive Information according to OAIS). One of the challenges when dividing metadata between preservation metadata and descriptive metadata is that the current metadata standards do not operate with the same distinction. Access rights information can for example both be stored in EAD (descriptive metadata) and in PREMIS (preservation metadata) or in METS. -This leaves the question - where should this access and dissementation information be registered? This E-ARK DIP specification describes two ways of using EAD and PREMIS for registering Access Rights and Access Software. These are possible ways and not yet recommendations. +This leaves the question - where should this access and dissemination information be registered? This E-ARK DIP specification describes two ways of using EAD and PREMIS for registering Access Rights and Access Software. These are possible ways and not yet recommendations. ## METS @@ -146,186 +82,68 @@ This limitation is made to reduce the complexity of the DIP. Future, more comple The chosen representation is itself an E-ARK IP and therefore follows the same structure. This is reflected in the IP being migrated from an AIP to a DIP. Below is a broad overview of the METS file. -  | Elements | | | Values |Comments ---------|-------------| ----------|-----------|----------------------------|--------------------- -**mets**| | | | | -  |**metsHdr** | | | | -  | |**agent** | | |software or archivist creating the DIP -  | **dmdSec** | | | | -  | |**mdRef** | |*EAD* |information about descriptive metadata files (e.g EAD) -  | **amdSec** | | | | -  | |**mdRef** | |*PREMIS* |information about preservation metadata files (e.g PREMIS) -  | **fileSec** | | | | -  | |**fileGrp**| |*Common Specification root* | -  | | |**fileGrp**|*metadata* | -  | | |**fileGrp**|*representations* | normally only one repr. in the DIP -  | | |**fileGrp**|*schemas* | -  | | |**fileGrp**|*documentation* | -  |**structMap**| | | | -  | | **div** | |*metadata* | -  | | **div** | |*representations* |mets pointer to mets file for the repr. -  | | **div** | |*schemas* | -  | | **div** | |*documentation* | +| | Elements | | | Values |Comments | +|----------|--------------| ----------|-----------|----------------------------|----------------------| +| **mets** | | | | | | +| | **metsHdr** | | | | | +| | | **agent** | | |software or archivist creating the DIP | +| | **dmdSec** | | | | | +| | | **mdRef** | | *EAD* |information about descriptive metadata files (e.g EAD) | +| | **amdSec** | | | | | +| | | **mdRef** | | *PREMIS* |information about preservation metadata files (e.g PREMIS) | +| | **fileSec** | | | | | +| | | **fileGrp** | | *Common Specification root* | | +| | | | **fileGrp** | *metadata* | | +| | | | **fileGrp** | *representations* | normally only one repr. in the DIP | +| | | | **fileGrp** | *schemas* | | +| | | | **fileGrp** | *documentation* | | +| | **structMap** | | | | | +| | | **div** | | *metadata* | | +| | | **div** | | *representations* | mets pointer to mets file for the repr. | +| | | **div** | | *schemas* | | +| | | **div** | | *documentation* | | In the following the major differences between an XML instance for METS for an E-ARK DIP vs an E-ARK AIP are listed. **Node level: mets root** -| ID | Name & Location | Description & usage | Cardi­nality & Level | E-ARK DIP requirement | -| -- | --------------- | ------------------- | ------------------- | --------------------- | -| **CSIP1** | **Package Identifier**
`mets/@OBJID` | The @OBJID attribute is mandatory, its value is a string identifier for the METS document. For the package METS document, this should be the name/ID of the package, i.e. the name of the package root folder.
For a representation level METS document this value records the name/ID of the representation, i.e. the name of the top-level representation folder. | **1..1**
MUST | The OBJID must change to reflect that the DIP is another information package | -| **CSIP2** | **Content Category**
`mets/@TYPE` | The @TYPE attribute MUST be used to declare the category of the content held in the package, e.g. book, journal, stereograph, video, etc.. Legal values are defined in a fixed vocabulary. When the content category used falls outside of the defined vocabulary the @TYPE value must be set to "OTHER" and the specific value declared in @csip:OTHERTYPE. The vocabulary will develop under the curation of the DILCIS Board as additional content information type specifications are produced.
**See also:** Content Category | **1..1**
MUST | No structural change from CSIP | -| **CSIP3** | **Other Content Category**
`mets[@TYPE=OTHER]/@csip:OTHERTYPE` | When the @TYPE attribute has the value "OTHER" the @csip:OTHERTYPE attribute MUST be used to declare the content category of the package/representation.
**See also:** Content Category | **0..1**
SHOULD | No structural change from CSIP | -| **CSIP4** | **Content Information Type Specification**
`mets/@csip: CONTENTINFORMATIONTYPE` | Used to declare the Content Information Type Specification used when creating the package. Legal values are defined in a fixed vocabulary. The attribute is mandatory for representation level METS documents. The vocabulary will evolve under the care of the DILCIS Board as additional Content Information Type Specifications are developed.
**See also:** Content information type specification | **0..1**
SHOULD |No structural change from CSIP | -| **CSIP5** | **Other Content Information Type Specification**
`mets[@csip:CONTENTINFORMATIONTYPE='OTHER'] /@csip:OTHERCONTENTINFORMATIONTYPE` | When the @csip:CONTENTINFORMATIONTYPE uses the value "OTHER" the @csip:OTHERCONTENTINFORMATIONTYPE must describe the content. | **0..1**
MAY | No structural change from CSIP | -| **CSIP6** | **METS Profile**
`mets/@PROFILE` | The URL of the METS profile that the information package conforms with. | **1..1**
MUST | Profile for DIP not made yet - Awaiting AIP profile | +!INCLUDE "implementation/metadata/mets/mets-root/requirements.md" + +!INCLUDE "implementation/metadata/mets/mets-root/examples.md" **Node level: metsHdr** -| ID | Name & Location | Description & usage | Cardi­nality & Level | E-ARK DIP requirement | -| -- | --------------- | ------------------- | ------------------- | ---------------------- | -| **CSIP117** | **Package header**
`mets/metsHdr` | General element for describing the package. | **1..1**
MUST | No structural change from CSIP | -| **CSIP7** | **Package creation date**
`mets/metsHdr/@CREATEDATE` | @CREATEDATE describes the date of creation of the package. | **1..1**
MUST | DIP - The name of the agent (software) that created the DIP from the AIP | -| **CSIP8** | **Package last modification date**
`mets/metsHdr/@LASTMODDATE` | @LASTMODDATE is mandatory if the package has been modified. | **0..1**
SHOULD | Change to creation date for DIP. The DIP is another and new information package | -| **CSIP9** | **OAIS Package type information**
`mets/metsHdr/@csip:OAISPACKAGETYPE` | @csip:OAISPACKAGETYPE is an attribute added by the CSIP for describing the type of the IP.
**See also:** OAIS Package type | **1..1**
MUST | The value must be "DIP"| -| **CSIP10** | **Agent**
`mets/metsHdr/agent` | One mandatory agent is used to describe the software used for creating the package. Other uses of agents are described in the own implementations extending profile. | **1..n**
MUST | No structural change from CSIP | -| **CSIP11** | **Agent role**
`mets/metsHdr/agent[@ROLE='CREATOR']` | The role of the mandatory agent is “CREATOR”. | **1..1**
MUST | No structural change from CSIP | -| **CSIP12** | **Agent type**
`mets/metsHdr/agent[@TYPE='OTHER']` | The type of the mandatory agent is “OTHER”. | **1..1**
MUST | No structural change from CSIP | -| **CSIP13** | **Agent other type**
`mets/metsHdr/agent[@OTHERTYPE='SOFTWARE']` | The other type of the mandatory agent is “SOFTWARE”.
**See also:** Other agent type | **1..1**
MUST | No structural change from CSIP | -| **CSIP14** | **Agent name**
`mets/metsHdr/agent/name` | The name of the mandatory agent is the name of the software tool which was used to create the IP. | **1..1**
MUST | No structural change from CSIP | -| **CSIP15** | **Agent additional information**
`mets/metsHdr/agent/note` | The mandatory agent has a note providing the version information for the tool which was used to create the IP. | **1..1**
MUST | No structural change from CSIP | -| **CSIP16** | **Classification of the agent additional information**
`mets/metsHdr/agent/note[@csip:NOTETYPE='SOFTWARE VERSION']` | The mandatory agent note is typed with the fixed value of "SOFTWARE VERSION".
**See also:** Note type | **1..1**
MUST | No structural change from CSIP | +!INCLUDE "implementation/metadata/mets/metshdr/requirements.md" + +!INCLUDE "implementation/metadata/mets/metshdr/examples.md" **Node level: dmdSec** -| ID | Name & Location | Description & usage | Cardi­nality & Level | E-ARK DIP require­ment | -| -- | --------------- | ------------------- | ------------------- | ---------------------- | -| **CSIP17** | **Descriptive metadata**
`mets/dmdSec` | Must be used if descriptive metadata for the package content is available. Each descriptive metadata section (dmdSec) contains one description and thus is repeated when more descriptions are available.
It is possible to transfer metadata in a package using just the descriptive metadata section and/or administrative metadata section. | **0..n**
SHOULD | No structural change from CSIP | -| **CSIP18** | **Descriptive metadata identifier**
`mets/dmdSec/@ID` | An xml:id identifier for the descriptive metadata section (dmdSec) used for referencing inside the package. It must be unique within the package. | **1..1**
MUST | No structural change from CSIP | -| **CSIP19** | **Descriptive metadata creation date**
`mets/dmdSec/@CREATED` | Creation date of the descriptive metadata in this section. | **1..1**
MUST | No structural change from CSIP | -| **CSIP20** | **Status of the descriptive metadata**
`mets/dmdSec/@STATUS` | Indicates the status of the package using a fixed vocabulary.
**See also:** dmdSec status | **0..1**
SHOULD | Normally the status should be CURRENT | -| **CSIP21** | **Reference to the document with the descriptive metadata**
`mets/dmdSec/mdRef` | Reference to the descriptive metadata file located in the “metadata” section of the IP. | **0..1**
SHOULD | No structural change from CSIP | -| **CSIP22** | **Type of locator**
`mets/dmdSec/mdRef[@LOCTYPE='URL']` | The locator type is always used with the value "URL" from the vocabulary in the attribute. | **1..1**
MUST | No structural change from CSIP | -| **CSIP23** | **Type of link**
`mets/dmdSec/mdRef[@xlink:type='simple']` | Attribute used with the value “simple”. Value list is maintained by the xlink standard. | **1..1**
MUST | No structural change from CSIP | -| **CSIP24** | **Resource location**
`mets/dmdSec/mdRef/@xlink:href` | The actual location of the resource. This specification recommends recording a URL type filepath within this attribute. | **1..1**
MUST | No structural change from CSIP | -| **CSIP25** | **Type of metadata**
`mets/dmdSec/mdRef/@MDTYPE` | Specifies the type of metadata in the linked file. Values are taken from the list provided by the METS standard. | **1..1**
MUST | No structural change from CSIP | -| **CSIP26** | **File mime type**
`mets/dmdSec/mdRef/@MIMETYPE` | The IANA mime type for the linked file.
**See also:** IANA media types | **1..1**
MUST | No structural change from CSIP | -| **CSIP27** | **File size**
`mets/dmdSec/mdRef/@SIZE` | Size of the linked file in bytes. | **1..1**
MUST | No structural change from CSIP | -| **CSIP28** | **File creation date**
`mets/dmdSec/mdRef/@CREATED` | The date the linked file was created. | **1..1**
MUST | No structural change from CSIP | -| **CSIP29** | **File checksum**
`mets/dmdSec/mdRef/@CHECKSUM` | The checksum of the linked file. | **1..1**
MUST | No structural change from CSIP | -| **CSIP30** | **File checksum type**
`mets/dmdSec/mdRef/@CHECKSUMTYPE` | The type of checksum following the value list in the standard which used for the linked file. | **1..1**
MUST | No structural change from CSIP | +!INCLUDE "implementation/metadata/mets/dmdsec/requirements.md" +!INCLUDE "implementation/metadata/mets/dmdsec/examples.md" **Node level: admSec** -| ID | Name & Location | Description & usage | Cardinality & Level | E-ARK DIP requirement | -| -- | --------------- | ------------------- | ------------------- | ---------------------- | -| **CSIP31** | **Administrative metadata**
`mets/amdSec` | If administrative / preservation metadata is available, it must be described using the administrative metadata section (amdSec) element.
All administrative metadata is present in one amdSec element.
It is possible to transfer metadata in a package using just the descriptive metadata section and/or administrative metadata section. | **0..1**
SHOULD | No structural change from CSIP | -| **CSIP32** | **Digital provenance metadata**
`mets/amdSec/digiprovMD` | For recording information about preservation the standard PREMIS is used. It is mandatory to include one digiprovMD element for each piece of PREMIS metadata.
The use if PREMIS in METS is following the recommendations in
2017 version of PREMIS in METS Guidelines | **0..n**
SHOULD | No structural change from CSIP | -| **CSIP33** | **Digital provenance metadata identfier**
`mets/amdSec/digiprovMD/@ID` | An xml:id identifier for the digital provenance metadata section (digiprovMD) used for referencing inside the package. It must be unique within the package. | **1..1**
MUST | No structural change from CSIP | -| **CSIP34** | **Status of the digital provenance metadata**
`mets/amdSec/digiprovMD/@STATUS` | Indicates the status of the package using a fixed vocabulary.
**See also:** dmdSec status | **0..1**
SHOULD | No structural change from CSIP | -| **CSIP35** | **Reference to the document with the digital provenance metdata**
`mets/amdSec/digiprovMD/mdRef` | Reference to the digital provenance metadata file stored in the “metadata” section of the IP. | **0..1**
SHOULD | No structural change from CSIP | -| **CSIP36** | **Type of locator**
`mets/amdSec/digiprovMD/mdRef[@LOCTYPE='URL']` | The locator type is always used with the value "URL" from the vocabulary in the attribute. | **1..1**
MUST | No structural change from CSIP | -| **CSIP37** | **Type of link**
`mets/amdSec/digiprovMD/mdRef[@xlink:type='simple']` | Attribute used with the value “simple”. Value list is maintained by the xlink standard. | **1..1**
MUST | No structural change from CSIP | -| **CSIP38** | **Resource location**
`mets/amdSec/digiprovMD/mdRef/@xlink:href` | The actual location of the resource. This specification recommends recording a URL type filepath within this attribute. | **1..1**
MUST | No structural change from CSIP | -| **CSIP39** | **Type of metadata**
`mets/amdSec/digiprovMD/mdRef/@MDTYPE` | Specifies the type of metadata in the linked file. Values are taken from the list provided by the METS standard. | **1..1**
MUST | No structural change from CSIP | -| **CSIP40** | **File mime type**
`mets/amdSec/digiprovMD/mdRef/@MIMETYPE` | The IANA mime type for the linked file.
**See also:** IANA media types | **1..1**
MUST | No structural change from CSIP | -| **CSIP41** | **File size**
`mets/amdSec/digiprovMD/mdRef/@SIZE` | Size of the linked file in bytes. | **1..1**
MUST | No structural change from CSIP | -| **CSIP42** | **File creation date**
`mets/amdSec/digiprovMD/mdRef/@CREATED` | Date the linked file was created. | **1..1**
MUST | No structural change from CSIP | -| **CSIP43** | **File checksum**
`mets/amdSec/digiprovMD/mdRef/@CHECKSUM` | The checksum of the linked file. | **1..1**
MUST | No structural change from CSIP | -| **CSIP44** | **File checksum type**
`mets/amdSec/digiprovMD/mdRef/@CHECKSUMTYPE` | The type of checksum following the value list in the standard which used for the linked file. | **1..1**
MUST | No structural change from CSIP | -| **CSIP45** | **Rights metadata**
`mets/amdSec/rightsMD` | A simple rights statement may be used to describe general permissions for the package. Individual representations should state their specific rights in their representation METS file.
Available standards include
RightsStatements.org
,
Europeana rights statements info
),
METS Rights Schema
created and maintaned by the METS Board, the rights part of
PREMIS
as well as own local rights statements in use. | **0..n**
MAY | No structural change from CSIP | -| **CSIP46** | **Rights metadata identifier**
`mets/amdSec/rightsMD/@ID` | An `xml:id` identifier for the rights metadata section (rightsMD) used for referencing inside the package. It must be unique within the package. | **1..1**
MUST | No structural change from CSIP | -| **CSIP47** | **Status of the rights metadata**
`mets/amdSec/rightsMD/@STATUS` | Indicates the status of the package using a fixed vocabulary.
**See also:** dmdSec status | **0..1**
SHOULD | No structural change from CSIP | -| **CSIP48** | **Reference to the document with the rights metadata**
`mets/amdSec/rightsMD/mdRef` | Reference to the rights metadata file stored in the “metadata” section of the IP. | **0..1**
SHOULD | No structural change from CSIP | -| **CSIP49** | **Type of locator**
`mets/amdSec/rightsMD/mdRef[@LOCTYPE='URL]` | The locator type is always used with the value "URL" from the vocabulary in the attribute. | **1..1**
MUST | No structural change from CSIP | -| **CSIP50** |
`mets/amdSec/rightsMD/mdRef[@xlink:type='simple]` | Attribute used with the value “simple”. Value list is maintained by the xlink standard. | **1..1**
MUST | No structural change from CSIP | -| **CSIP51** | **Resource location**
`mets/amdSec/rightsMD/mdRef/@xlink:href` | The actual location of the resource. We recommend recording a URL type filepath within this attribute. | **1..1**
MUST | No structural change from CSIP | -| **CSIP52** | **Type of metadata**
`mets/amdSec/rightsMD/mdRef/@MDTYPE` | Specifies the type of metadata in the linked file. Value is taken from the list provided by the METS standard. | **1..1**
MUST | No structural change from CSIP | -| **CSIP53** | **File mime type**
`mets/amdSec/rightsMD/mdRef/@MIMETYPE` | The IANA mime type for the linked file.
**See also:** IANA media types | **1..1**
MUST | No structural change from CSIP | -| **CSIP54** | **File size**
`mets/amdSec/rightsMD/mdRef/@SIZE` | Size of the linked file in bytes. | **1..1**
MUST | No structural change from CSIP | -| **CSIP55** | **File creation date**
`mets/amdSec/rightsMD/mdRef/@CREATED` | Date the linked file was created. | **1..1**
MUST | No structural change from CSIP | -| **CSIP56** | **File checksum**
`mets/amdSec/rightsMD/mdRef/@CHECKSUM` | The checksum of the linked file. | **1..1**
MUST | No structural change from CSIP | -| **CSIP57** | **File checksum type**
`mets/amdSec/rightsMD/mdRef/@CHECKSUMTYPE` | The type of checksum following the value list in the standard which used for the linked file. | **1..1**
MUST | No structural change from CSIP | - +!INCLUDE "implementation/metadata/mets/amdsec/requirements.md" **Node level: fileSec** -| ID | Name & Location | Description & usage | Cardinality & Level | E-ARK DIP requirement | -| -- | --------------- | ------------------- | ------------------- | ---------------------- | -| **CSIP58** | **File section**
`mets/fileSec` | The transferred content is placed in the file section in different file group elements, described in other requirements.
No more than one file section (fileSec) element should be present.
It is possible to transfer just descriptive metadata and/or administrative metadata without files placed in this section. | **0..1**
SHOULD | No structural change from CSIP | -| **CSIP59** | **File section identifier**
`mets/fileSec/@ID` | An xml:id identifier for the file section used for referencing inside the package. It must be unique within the package. | **1..1**
MUST | No structural change from CSIP | -| **CSIP60** | **Documentation file group**
`mets/fileSec/fileGrp[@USE='Documentation']` | All documentation pertaining to the transferred content is placed in one or more file group elements with @USE attribute value "Documentation".
**See also:** File group names | **1..n**
MUST | No structural change from CSIP | -| **CSIP113** | **Schema file group**
`mets/fileSec/fileGrp[@USE='Schemas']` | All XML schemas used in the information package should be referenced from one or more file groups with @USE attribute value "Schemas".
**See also:** File group names | **1..n**
MUST | No structural change from CSIP | -| **CSIP114** | **Representations file group**
`mets/fileSec/fileGrp[@USE='Representations']` | A pointer to the METS document describing the representation or pointers to the content being transferred must be present in one or more file groups with the categorisation "Representations".
**See also:** File group names | **1..n**
MUST | No structural change from CSIP | -| **CSIP61** | **Reference to administrative metadata**
`mets/fileSec/fileGrp/@ADMID` | If administrative metadata has been provided on the file group (fileGrp) level this attribute points to the correct administrative metadata section. | **0..1**
MAY | No structural change from CSIP | -| **CSIP62** | **Content Information Type Specification**
`mets/fileSec/fileGrp/@csip:CONTENTINFORMATIONTYPE` | An added attribute which states the name of the content information type specification used to create the package.
The vocabulary will evolve under the curation of the DILCIS Board as additional content information type specifications are developed.
This attribute is mandatory when the file group @LABEL attribute value is "Representations".
When the "Package type" value is "Mixed" and/or the file group describes a "Representation", then this element states the content information type specification used for the file group.
**See also:** Content information type specification | **0..1**
SHOULD | No structural change from CSIP | -| **CSIP63** | **Other Content Information Type Specification**
`mets/fileSec/fileGrp[@csip:CONTENTINFORMATIONTYPE='OTHER']/@csip:OTHERCONTENTINFORMATIONTYPE` | When the @csip:CONTENTINFORMATIONTYPE uses the value "OTHER" the @csip:OTHERCONTENTINFORMATIONTYPE must state a value for the Content Information Type Specification used. | **0..1**
MAY | No structural change from CSIP | -| **CSIP64** | **Description of the use of the file group**
`mets/fileSec/fileGrp/@USE` | The value in the @USE is the name of the whole folder structure to the data, e.g "Documentation", "Schemas", "Representations/preingest" or "Representations/submission/data". | **1..1**
MUST | No structural change from CSIP | -| **CSIP65** | **File group identifier**
`mets/fileSec/fileGrp/@ID` | An xml:id identifier for the file group used for referencing inside the package. It must be unique within the package. | **1..1**
MUST | No structural change from CSIP | -| **CSIP66** | **File**
`mets/fileSec/fileGrp/file` | The file group (fileGrp) contains the file elements which describe the file objects. | **1..n**
MUST | No structural change from CSIP | -| **CSIP67** | **File identifier**
`mets/fileSec/fileGrp/file/@ID` | A xml:id unique identifier for this file across the package. | **1..1**
MUST | No structural change from CSIP | -| **CSIP68** | **File mimetype**
`mets/fileSec/fileGrp/file/@MIMETYPE` | The IANA mime type for the linked file.
**See also:** IANA media types | **1..1**
MUST | No structural change from CSIP | -| **CSIP69** | **File size**
`mets/fileSec/fileGrp/file/@SIZE` | Size of the linked file in bytes. | **1..1**
MUST | No structural change from CSIP | -| **CSIP70** | **File creation date**
`mets/fileSec/fileGrp/file/@CREATED` | Date the linked file was created. | **1..1**
MUST | No structural change from CSIP | -| **CSIP71** | **File checksum**
`mets/fileSec/fileGrp/file/@CHECKSUM` | The checksum of the linked file. | **1..1**
MUST | No structural change from CSIP | -| **CSIP72** | **File checksum type**
`mets/fileSec/fileGrp/file/@CHECKSUMTYPE` | The type of checksum following the value list in the standard which used for the linked file. | **1..1**
MUST | No structural change from CSIP | -| **CSIP73** | **File original identfication**
`mets/fileSec/fileGrp/file/@OWNERID` | If an original ID for the file has been given by the owner it can be saved in this attribute. | **0..1**
MAY | No structural change from CSIP | -| **CSIP74** | **File reference to administrative metadata**
`mets/fileSec/fileGrp/file/@ADMID` | If administrative metadata has been described for the file this attribute points to the file's administrative metadata. | **0..1**
MAY | No structural change from CSIP | -| **CSIP75** | **File reference to descriptive metadata**
`mets/fileSec/fileGrp/file/@DMDID` | If descriptive metadata has been described per file this attribute points to the file's descriptive metadata. | **0..1**
MAY | No structural change from CSIP | -| **CSIP76** | **File locator reference**
`mets/fileSec/fileGrp/file/FLocat` | The location of each external file must be defined by the file location (FLocat) element using the same rules as for referencing metadata files. All references to files should be made using the XLink href attribute and the file protocol using the relative location of the file. | **1..1**
MUST | No structural change from CSIP | -| **CSIP77** | **Type of locator**
`mets/fileSec/fileGrp/file/FLocat[@LOCTYPE='URL']` | The locator type is always used with the value "URL" from the vocabulary in the attribute. | **1..1**
MUST | No structural change from CSIP | -| **CSIP78** | **Type of link**
`mets/fileSec/fileGrp/file/FLocat[@xlink:type='simple']` | Attribute used with the value “simple”. Value list is maintained by the xlink standard. | **1..1**
MUST | No structural change from CSIP | -| **CSIP79** | **Resource location**
`mets/fileSec/fileGrp/file/FLocat/@xlink:href` | The actual location of the resource. We recommend recording a URL type filepath within this attribute. | **1..1**
MUST | No structural change from CSIP | +!INCLUDE "implementation/metadata/mets/filesec/requirements.md" **Node level: structMap** -| ID | Name & Location | Description & usage | Cardinality & Level | E-ARK DIP requirement | -| -- | --------------- | ------------------- | ------------------- | --------------------- | -| **CSIP80** | **Structural description of the package**
`mets/structMap` | The structural map (structMap) element is the only mandatory element in the METS standard.
The structMap in CSIP describes the highest logical structure of the IP.
Each METS file must include ONE structural map (structMap) element used exactly as described here.
Institutions can add their own additional custom structural maps as separate structMap sections. | **1..n**
MUST | No structural change from CSIP | -| **CSIP81** | **Type of structural description**
`mets/structMap[@TYPE='PHYSICAL']` | The type attribute of the structural map (structMap) is set to value “PHYSICAL” from the vocabulary.
**See also:** Structural map typing | **1..1**
MUST | No structural change from CSIP. No change in value from CSIP| -| **CSIP82** | **Name of the structural description**
`mets/structMap[@LABEL='CSIP']` | The label attribute is set to value “CSIP” from the vocabulary.
**See also:** Structural map label | **1..1**
MUST | No structural change from CSIP. No change in value from CSIP| -| **CSIP83** | **Structural description identifier**
`mets/structMap[@LABEL='CSIP']/@ID` | An `xml:id` identifier for the structural description (structMap) used for referencing inside the package. It must be unique within the package. | **1..1**
MUST | No structural change from CSIP. Possible change in value from CSIP| -| **CSIP84** | **Main structural division**
`mets/structMap[@LABEL='CSIP']/div` | The structural map consist of one main division. | **1..1**
MUST | No structural change from CSIP| -| **CSIP85** | **Main structural division identifier**
`mets/structMap[@LABEL='CSIP']/div/@ID` | Mandatory, xml:id identifier must be unique within the package. | **1..1**
MUST | No structural change from CSIP. Possible change in value from CSIP| -| **CSIP86** | **Main structural division label**
`mets/structMap[@LABEL='CSIP']/div/@LABEL` | The package's top-level structural division (div) element must have an @LABEL attribute value identical to the package identifier, i.e. the same value as the mets/@OBJID attribute. | **1..1**
MUST | No structural change from CSIP. Value change from AIP ID to DIP ID.| -| **CSIP88** | **Metadata division**
`mets/structMap[@LABEL='CSIP']/div/div[@LABEL='Metadata']` | The metadata referenced in the administrative and/or descriptive metadata section is described in the structural map with one sub division.
When the transfer consist of only administrative and/or descriptive metadata this is the only sub division that occurs. | **1..1**
MUST | No structural change from CSIP| -| **CSIP89** | **Metadata division identifier**
`mets/structMap[@LABEL='CSIP']/div/div[@LABEL='Metadata']/@ID` | Mandatory, xml:id identifier must be unique within the package. | **1..1**
MUST | No structural change from CSIP. Possible change in value from AIP| -| **CSIP90** | **Metadata division label**
`mets/structMap/div[@LABEL='CSIP']/div[@LABEL='Metadata']` | The metadata division (div) element in the package uses the value "Metadata" as the value for the attribute LABEL.
**See also:** File group names | **1..1**
MUST | No structural change from CSIP | -| **CSIP91** | **Metadata division administrative metadata referencing**
`mets/structMap[@LABEL='CSIP']/div/div[@LABEL='Metadata']/@ADMID` | When there are administrative metadata and the amdSec is present, all administrative metadata MUST be referenced via the administrative sections different identifiers.
All the different identifiers is named in the same @AMDID using space as the divider. | **0..1**
SHOULD | No structural change from CSIP| -| **CSIP92** | **Metadata division descriptive metadata referencing**
`mets/structMap[@LABEL='CSIP']/div/div[@LABEL='Metadata']/@DMDID` | When there are descriptive metadata and one or more dmdSec is present, all descriptive metadata MUST be referenced via the descriptive section identifiers.
All the different identifiers is named in the same @DMDID using space as the divider. | **0..1**
SHOULD | No structural change from CSIP| -| **CSIP93** | **Documentation division**
`mets/structMap[@LABEL='CSIP']/div/div[@LABEL='Documentation']` | The documentation referenced in the file section file groups is described in the structural map with one sub division. | **0..1**
SHOULD | No structural change from CSIP| -| **CSIP94** | **Documentation division identifier**
`mets/structMap[@LABEL='CSIP']/div/div[@LABEL='Documentation']/@ID` | Mandatory, `xml:id` identifier must be unique within the package. | **1..1**
MUST | No structural change from CSIP. Possible change in value from AIP| -| **CSIP95** | **Documentation division label**
`mets/structMap[@LABEL='CSIP']/div/div[@LABEL='Documentation']` | The documentation division (div) element in the package uses the value "Documentation" from the vocabulary as the value for the attribute LABEL.
**See also:** File group names | **1..1**
MUST |No structural change from CSIP. No change in value from CSIP| -| **CSIP96** | **Documentation file referencing**
`mets/structMap[@LABEL='CSIP']/div/div[@LABEL='Documentation']/fptr` | All file groups contaning documentation described in the package are referenced via the relevant file group identifiers. One file group refrence per fptr-element | **0..n**
MUST | No structural change from CSIP. Possible change in value from AIP| -| **CSIP116** | **Documentation file group reference pointer**
`mets/structMap[@LABEL='CSIP']/div/div[@LABEL='Documentation']/fptr/@FILEID` | The pointer to the identfier for the "Documentation" file group.
Related to the requirements CSIP60 which describes the "Documentation" file group and CSIP65 which describes the file group identfier. | **1..1**
MUST | No structural change from CSIP | -| **CSIP97** | **Schema division**
`mets/structMap[@LABEL='CSIP']/div/div[@LABEL='Schemas']` | The schemas referenced in the file section file groups are described in the structural map within a single sub-division. | **0..1**
SHOULD |No structural change from CSIP| -| **CSIP98** | **Schema division identifier**
`mets/structMap[@LABEL='CSIP']/div/div[@LABEL='Schemas']/@ID` | Mandatory, xml:id identifier must be unique within the package. | **1..1**
MUST |No structural change from CSIP. Possible change in value from AIP| -| **CSIP99** | **Schema division label**
`mets/structMap[@LABEL='CSIP']/div/div[@LABEL='Schemas']` | The schema division (div) element in the package uses the value "Schemas" from the vocabulary as the value for the attribute LABEL.
**See also:** File group names | **1..1**
MUST | No structural change from CSIP. No change in value from CSIP| -| **CSIP100** | **Schema file referencing**
`mets/structMap[@LABEL='CSIP']/div/div[@LABEL='Schemas']/fptr` | All file groups containing schemas described in the package are referenced via the relevant file group identifiers. One file group refrence per fptr-element | **0..n**
MUST | No structural change from CSIP. Possible change in value from AIP| ?| -| **CSIP118** | **Schema file group reference pointer**
`mets/structMap[@LABEL='CSIP']/div/div[@LABEL='Schemas']/fptr/@FILEID` | The pointer to the identfier for the "Schema" file group.
Related to the requirements CSIP113 which describes the "Schema" file group and CSIP65 which describes the file group identfier. | **1..1**
MUST | No structural change from CSIP | -| **CSIP101** | **Content division**
`mets/structMap[@LABEL='CSIP']/div/div[@LABEL='Representations']` | When no representations are present the content referenced in the file section file group with @USE attribute value "Representations" is described in the structural map as a single sub division. | **0..1**
SHOULD | No structural change from CSIP| -| **CSIP102** | **Content division identifier**
`mets/structMap[@LABEL='CSIP']/div/div[@LABEL='Representations']/@ID` | Mandatory, xml:id identifier must be unique within the package. | **1..1**
MUST |No structural change from CSIP. Possible change in value from AIP| -| **CSIP103** | **Content division label**
`mets/structMap[@LABEL='CSIP']/div/div[@LABEL='Representations']/@LABEL` | The package's content division (div) element must have the @LABEL attribute value "Representations", taken from the vocabulary.
**See also:** File group names | **1..1**
MUST | No structural change from CSIP. No change in value from CSIP| -| **CSIP104** | **File division file referencing**
`mets/structMap[@LABEL='CSIP']/div/div[@LABEL='Representations']/fptr` | All file groups containing content described in the package are referenced via the relevant file group identifiers. One file group refrence per fptr-element | **0..n**
MUST |No structural change from CSIP. Possible change in value from AIP| -| **CSIP119** | **Content division file group references**
`mets/structMap[@LABEL='CSIP']/div/div[@LABEL='Representations']/fptr/@FILEID` | The pointer to the identfier for the "Representations" file group.
Related to the requirements CSIP114 which describes the "Representations" file group and CSIP65 which describes the file group identfier. | **1..1**
MUST |No structural change from CSIP| -| **CSIP105** | **Representation division**
`mets/structMap[@LABEL='CSIP']/div/div` | When a package consists of multiple representations, each described by a representation level METS.xml document, there is a discrete representation div element for each representation.
Each representation div references the representation level METS.xml document, documenting the structure of the package and its constituent representations. | **0..1**
SHOULD | Structural change from CSIP from 0..n to 0..1. The DIP must only contain one representation. The AIP to DIP migration choses which representation to migrate from the AIP to the DIP| -| **CSIP106** | **Representations division identifier**
`mets/structMap[@LABEL='CSIP']/div/div/@ID` | Mandatory, xml:id identifier must be unique within the package. | **1..1**
MUST | No structural change from CSIP. Possible change in value from AIP| -| **CSIP107** | **Representations division label**
`mets/structMap[@LABEL='CSIP']/div/div[@LABEL='CSIP']` | The package's representation division (div) element @LABEL attribute value must be the path to the representation level METS document.
This requirement gives the same value to be used as the requirement named "File group identifier" (CSIP64)
**See also:** File group names | **1..1**
MUST | No structural change from CSIP. Possible change in value from AIP| -| **CSIP108** | **Representations division file referencing**
`mets/structMap/div/div/mptr/@xlink:title` | The file group containing the files described in the package are referenced via the relevant file group identifier.
Related to the requirements CSIP114 which describes the "Representations" file group and CSIP65 which describes the file group identfier. | **1..1**
MUST | No structural change from CSIP. Possible change in value from AIP| -| **CSIP109** | **Representation METS pointer**
`mets/structMap/div/div/mptr` | The division (div) of the specific representation includes one occurrence of the METS pointer (mptr) element, pointing to the appropriate representation METS file. | **1..1**
MUST | No structural change from CSIP | -| **CSIP110** | **Resource location**
`mets/structMap/div/div/mptr/@xlink:href` | The actual location of the resource. We recommend recording a URL type filepath within this attribute. | **1..1**
MUST | No structural change from CSIP. Possible change in value from AIP| -| **CSIP111** | **Type of link**
`mets/structMap/div/div/mptr[@xlink:type='simple']` | Attribute used with the value “simple”. Value list is maintained by the xlink standard. | **1..1**
MUST | No structural change from CSIP. No change in value from CSIP| -| **CSIP112** | **Type of locator**
`mets/structMap/div/div/mptr[@LOCTYPE='URL']` | The locator type is always used with the value "URL" from the vocabulary in the attribute. | **1..1**
MUST | No structural change from CSIP. No change in value from CSIP| +!INCLUDE "implementation/metadata/mets/structmap/requirements.md" + ## PREMIS PREMIS (Preservation Metadata: Implementation Strategies) is a standard that mainly caters for long-term preservation and technical usability, which for example is used to facilitate a range of preservation strategies including migration and emulation. -From an Access perspective, PREMIS especially satisfies the requirements pertaining to the recording of Representation Information. It is practical to state in a formalised and consistent way how the Access Software should behave and where it should look when dealing with different pieces of information, such as which representation formats are included in the DIP. +From an Access perspective, PREMIS especially satisfies the requirements pertaining to the recording of Representation Information. It is practical to state in a formalised and consistent way how the Access Software should behave and where it should look when dealing with different pieces of information, such as which representation formats are included in the DIP. -### ​Metadata regarding Representations and Access Software +### Metadata regarding Representations and Access Software In PREMIS, a representation is a "set of files, including structural metadata, needed for a complete and reasonable rendition of an Intellectual Entity." See [PREMIS Editorial Committee (2015). "PREMIS Data Dictionary for Preservation Metadata", p.8](http://www.loc.gov/standards/premis/v3/premis-3-0-final.pdf). One of the core concepts in PREMIS is the above formulated definition of a representation, but it is also important to note that the CSIP structure also incorporates physical management of different representations. When implementing PREMIS in CSIPs one must therefore choose if there must exist PREMIS files at representation level or at root level only (see CSIP) and one must also choose how fine-grained each description should be. @@ -349,14 +167,14 @@ In order to describe the specific DIP representation format the semantic compone DIP representation format\ SIARD2\ - + ``` -Note that the object type is "representation" and that the objectIdentifierType value is "filepath", which according to the AIP specification is an IP scope value. The objectIdentifierValue is the filepath to the representation folder or could be a filepath to a file. +Note that the object type is "representation" and that the objectIdentifierType value is "filepath", which according to the AIP specification is an IP scope value. The objectIdentifierValue is the file path to the representation folder or could be a file path to a file. #### Description 2 - The description of Access Software -In PREMIS 3.0 a description of an environment has become an object itself, so that both non-environmental objects and environmental objects exist. Access Software is therefore an environmental object which per default is an intellectual entity. -The semantic unit "1.9 environmentFunction" is conceived to describe the environment object(s) with different levels of granularity. It is suggested to use [the vocabulary from Library of Congress](http://id.loc.gov/vocabulary/preservation/environmentFunctionType.html). +In PREMIS 3.0 a description of an environment has become an object itself, so that both non-environmental objects and environmental objects exist. Access Software is therefore an environmental object which per default is an intellectual entity. +The semantic unit "1.9 environmentFunction" is conceived to describe the environment object(s) with different levels of granularity. It is suggested to use [the vocabulary from Library of Congress](http://id.loc.gov/vocabulary/preservation/environmentFunctionType.html). The semantic unit "1.10 environmentDesignation" is used for information identifying the environment by using human-readable language which can be expected to be understood outside of a digital repository. See the example which follows this vocabulary: @@ -379,7 +197,7 @@ See the example which follows this vocabulary: Database Visualization Toolkit 2.4.1 - Lightweight web viewer for relational databases, specially if preserved in SIARD 2, that uses SOLR as a backend, and allows browsing, search, and export. Documentation at github.com/eark-project/software/DBVTK + Lightweight web viewer for relational databases, specially if preserved in SIARD 2, that uses SOLR as a back-end, and allows browsing, search, and export. Documentation at github.com/eark-project/software/DBVTK ``` @@ -390,8 +208,8 @@ In order to establish a connection between the DIP representation format to be r ```xml - - + + filepath xlink:href="representations\AVID.SA.18006.rep0" @@ -399,15 +217,15 @@ In order to establish a connection between the DIP representation format to be r DIP representation format SIARD2 - + - dependency + dependency requires local DBVTK - render + render ``` @@ -420,9 +238,9 @@ Since it is not always possible to render the DIP representation formats with on ## Descriptive metadata - e.g. EAD -Descriptive metadata are used to describe the intellectual contents of archival holdings, and they support finding and understanding individual information packages. The E-ARK DIP allows for the inclusion of any kind of descriptive metadata. +Descriptive metadata are used to describe the intellectual contents of archival holdings, and they support finding and understanding individual information packages. The E-ARK DIP allows for the inclusion of any kind of descriptive metadata. The E-ARK project reached the conclusion that EAD was one of the most used. See the full report -[D3.1 E-ARK Report on Available Best Practices](http://www.eark-project.com/resources/project-deliverables/6-d31-e-ark-report-on-available-best-practices). A common EARK EAD guideline is yet to be developed. But for information purposes and since the previous DIP specification described a way to register Access Rights Information the text is given here: +[D3.1 E-ARK Report on Available Best Practices](http://www.eark-project.com/resources/project-deliverables/6-d31-e-ark-report-on-available-best-practices). A common E-ARK EAD guideline is yet to be developed. But for information purposes and since the previous DIP specification described a way to register Access Rights Information the text is given here: ### Access restrictions OAIS states: @@ -430,10 +248,10 @@ OAIS states: > to the Content Information, including the legal framework, licensing terms, and access control. > It contains the access and distribution conditions stated within the Submission Agreement, > related to both preservation (by the OAIS) and final usage (by the Consumer). -> It also includes the specifications for the application of rights enforcement measures. +> It also includes the specifications for the application of rights enforcement measures. The E-ARK DIP specification does not require that access rights are stored in a specific way since different metadata standards -can be applied differently to different Content Information Types. See Content Information Types. +can be applied differently to different Content Information Types. See Content Information Types. Since it is possible to have different metadata information in the metadata folder it is recommended to systematically control where access rights metadata are stored. For example access rights metadata can be stored in both EAD and in PREMIS. The \ tag is "An element for information about conditions that affect the availability of the materials being described." See [EAD3](http://www.loc.gov/ead/EAD3taglib/index.html\#elem-accessrestrict). @@ -466,7 +284,7 @@ EAD example of \ type of the restriction (e.g. personal data) duration of the restriction in years (e.g. 25 years) - source of the restriction (e.g. Public access law AvTS §7) + source of the restriction (e.g. Public access law AvTS 7) additional description of the access restriction (e.g. The content can be made public if personal data is removed from the DIP) @@ -488,3 +306,32 @@ archive/650x0b1.pdf. PREMIS. 2017. PREMIS Data Dictionary for Preservation Metadata, Version 3.0. The Library of Congress. https://www.loc.gov/standards/premis/v3/index.html. + +# I. Acknowledgements +The E-ARK Dissemination Information Package (DIP) Specification was first developed within the E-ARK project in 2014 – 2017. E-ARK was an EC-funded pilot action project in the Competitiveness and Innovation Programme 2007- 2013, Grant Agreement no. 620998 under the Policy Support Programme. + +Since the scope of the E-ARK 2014-2017 DIP specification was linked to a reference implementation, specific Content Information Types, and product development with pilot actions it was a 100 pages long document. The scope of this E-ARK DIP Specification is not the same, the document has been shortened heavily and therefore we currently only have two authors credited. This does not mean that the current authors are the only ones behind this specification. We rely heavily on the work previously done. + +The authors of this specification would like to thank all national archives, tool developers and other stakeholders who provided valuable knowledge about their requirements for information packages and feedback to this and previous versions of the specification. + + +# II. Contact & Feedback +The E-ARK DIP specification is maintained by the Digital Information LifeCycle Interoperability Standard Board (DILCIS Board). For further information about the DILCIS Board or feedback on the current document please consult the website http://www.dilcis.eu/ or https://github.com/dilcisboard or contact us at   + +# III. Authors + + +| Name | Organisation | +| -------------------------------- | -------------------------------------------------- | +| Anders Bo Nielsen | Danish National Archives | +| Phillip Tømmerholt | Danish National Archives | + + +# IV. Revision History + +| Revision No. | Date | Authors(s) | Organisation | Description | +|--------------|------------|----------------------------------|--------------|----------------------------| +| 1.0 | 20.12.2018 | Phillip Tømmerholt
Anders Bo Nielsen | DNA | Review version | +| 1.0.1 | 20.03.2019 | Phillip Tømmerholt
Anders Bo Nielsen | DNA | Corrected typos | +| 1.0.2 | 26.04.2019 | Phillip Tømmerholt
Anders Bo Nielsen | DNA | Corrected typos | +| 1.1.0 | 27.05.2019 | Phillip Tømmerholt
Anders Bo Nielsen | DNA | Align with CSIP | From 29e8157b3a5b24730f621d7214f1993245b924fd Mon Sep 17 00:00:00 2001 From: Carl Wilson Date: Fri, 31 May 2019 19:02:19 +0100 Subject: [PATCH 06/10] FIX - added missing Gemfile. --- Gemfile | 4 ++++ 1 file changed, 4 insertions(+) create mode 100644 Gemfile diff --git a/Gemfile b/Gemfile new file mode 100644 index 0000000..13cf28b --- /dev/null +++ b/Gemfile @@ -0,0 +1,4 @@ +source 'https://rubygems.org' +gem 'github-pages', group: :jekyll_plugins +gem "jekyll-theme-primer", group: :jekyll_plugin +gem 'html-proofer' From fd85049044e54944c959f4632166a601b36761ea Mon Sep 17 00:00:00 2001 From: Carl Wilson Date: Fri, 31 May 2019 19:06:31 +0100 Subject: [PATCH 07/10] FIX - return to root after PDF publication. --- create-pdf.sh | 2 ++ 1 file changed, 2 insertions(+) diff --git a/create-pdf.sh b/create-pdf.sh index 0271f13..9a92941 100755 --- a/create-pdf.sh +++ b/create-pdf.sh @@ -28,3 +28,5 @@ pandoc --from gfm \ eark-dip-pdf.md \ --metadata-file ../pandoc/metadata.yaml \ -o pdf/eark-dip.pdf + +cd "$SCRIPT_DIR" || exit From 6b1247422f63a922cda24e93c56364758d6c86a8 Mon Sep 17 00:00:00 2001 From: Karin Bredenberg Date: Fri, 31 May 2019 20:24:27 +0200 Subject: [PATCH 08/10] Updated link to EAD3 access restrict Updated link to accessrestrict in EAD3. --- specification/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specification/index.md b/specification/index.md index 2eb9588..2228168 100644 --- a/specification/index.md +++ b/specification/index.md @@ -436,7 +436,7 @@ The E-ARK DIP specification does not require that access rights are stored in a can be applied differently to different Content Information Types. See Content Information Types. Since it is possible to have different metadata information in the metadata folder it is recommended to systematically control where access rights metadata are stored. For example access rights metadata can be stored in both EAD and in PREMIS. -The \ tag is "An element for information about conditions that affect the availability of the materials being described." See [EAD3](http://www.loc.gov/ead/EAD3taglib/index.html\#elem-accessrestrict). +The \ tag is "An element for information about conditions that affect the availability of the materials being described." See [EAD3](). The Access Rights Information that concerns the end-user has to be available in EAD - not in PREMIS - and \ is used for this purpose. The reasons being: It should be possible to find the Access Rights Information in one place and one place only, namely in the descriptive metadata, which, per default, are the metadata displayed in the Access Software (Finding Aids and different viewers). EAD supports the description of potentially very complex hierarchical levels of an IP and can therefore if necessary differentiate access restrictions all the way down to the individual file level. Descriptive metadata are very often added upon Ingest and Finding Aids can thus immediately be populated with this kind of information. The \

tag in \ is repeatable and can be used in the following way: From f2a301fe8535464e22b04d84179277a2808e2d7e Mon Sep 17 00:00:00 2001 From: Carl Wilson Date: Fri, 31 May 2019 19:35:33 +0100 Subject: [PATCH 09/10] FIX - disable link checking. --- .travis.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.travis.yml b/.travis.yml index 61af53a..f8f7690 100644 --- a/.travis.yml +++ b/.travis.yml @@ -24,7 +24,7 @@ script: - bash create-pdf.sh - bundle install - bundle exec jekyll build -s ./docs -d ./_site - - bundle exec htmlproofer ./_site --file-ignore /javadoc/ --only-4xx --check-html + # - bundle exec htmlproofer ./_site --file-ignore /javadoc/ --only-4xx --check-html deploy: provider: pages skip_cleanup: true From 9e7bf78829c8ea3dd5aedbffc3648a52c16f2fa1 Mon Sep 17 00:00:00 2001 From: Carl Wilson Date: Fri, 31 May 2019 20:12:37 +0100 Subject: [PATCH 10/10] FIX - correct publication token. --- .travis.yml | 44 ++++++++++++++++++++++---------------------- 1 file changed, 22 insertions(+), 22 deletions(-) diff --git a/.travis.yml b/.travis.yml index f8f7690..03d6334 100644 --- a/.travis.yml +++ b/.travis.yml @@ -2,33 +2,32 @@ dist: trusty sudo: required language: java jdk: - - openjdk8 - - oraclejdk8 +- openjdk8 +- oraclejdk8 before_install: - - sudo apt-get update - - sudo apt-get install -y texlive texlive-base texlive-latex-extra texlive-fonts-extra - python-virtualenv librsvg2-bin - - wget https://github.com/jgm/pandoc/releases/download/2.5/pandoc-2.5-linux.tar.gz - - tar -xzvf pandoc-2.5-linux.tar.gz - - rm pandoc-2.5-linux.tar.gz - - sudo mv pandoc-2.5 /opt - - sudo chmod +x /opt/pandoc-2.5/bin/pandoc - - sudo ln -s /opt/pandoc-2.5/bin/pandoc /usr/local/bin/pandoc - - sudo ln -s /opt/pandoc-2.5/bin/pandoc-citeproc /usr/local/bin/pandoc-citeproc +- sudo apt-get update +- sudo apt-get install -y texlive texlive-base texlive-latex-extra texlive-fonts-extra + python-virtualenv librsvg2-bin +- wget https://github.com/jgm/pandoc/releases/download/2.5/pandoc-2.5-linux.tar.gz +- tar -xzvf pandoc-2.5-linux.tar.gz +- rm pandoc-2.5-linux.tar.gz +- sudo mv pandoc-2.5 /opt +- sudo chmod +x /opt/pandoc-2.5/bin/pandoc +- sudo ln -s /opt/pandoc-2.5/bin/pandoc /usr/local/bin/pandoc +- sudo ln -s /opt/pandoc-2.5/bin/pandoc-citeproc /usr/local/bin/pandoc-citeproc script: - - cd spec-publisher - - mvn clean package - - java -jar target/mets-profile-proc.jar ../profile/E-ARK-DIP.xml - - cd .. - - bash create-site.sh - - bash create-pdf.sh - - bundle install - - bundle exec jekyll build -s ./docs -d ./_site - # - bundle exec htmlproofer ./_site --file-ignore /javadoc/ --only-4xx --check-html +- cd spec-publisher +- mvn clean package +- java -jar target/mets-profile-proc.jar ../profile/E-ARK-DIP.xml +- cd .. +- bash create-site.sh +- bash create-pdf.sh +- bundle install +- bundle exec jekyll build -s ./docs -d ./_site deploy: provider: pages skip_cleanup: true - github_token: $GH_TOKEN + github_token: "$GH_TOKEN" keep_history: true local_dir: docs on: @@ -37,3 +36,4 @@ env: global: - NOKOGIRI_USE_SYSTEM_LIBRARIES=true - secure: OT1rmJ/+ywbA88+8PwAojxy3uvzUk07hdHVTYPgYIFnTC0KBKSjrZZkJ+cwX9xtqRmVDGCGyl+x3WYy02tS9jubC9zWkArxJl1lT9AvXFn4tXzDoF1lRjp2Bgk6uEmk8BZbERs6Ef7C3aFj+qwuoioPEhCQosxTrEqt7gVuAyASsFm+7q1HJqKWwAV6hPAEHVsrNFaQGg84XO+TMT3l3UlXetGD9IhZsbo+HGHqp0F2zlUSVaGfEHC5MJPHWO9QQRVoPY2ZT8okhL/zAxivhwnn3qFdQwVObBFs4Q5q0gBkg/ahQ4hMFISfTqvxlL52C7JTCFWxX2apZwUIL5FQ3PIsr5JUn3yPvZTXzOPDGkzHZmIWPeMdzB5HcJEl73WOyQ7z08hGiwTw46BDWlZUQ8JwFEquNadKvX3iJA5u/TGQ17uB2h3ZZlb/0RtBxPuK59RBwBKtt5jgHq+RBH6o+Z6KPt/zyKDbFt9m6SC/FBdvLSk3paMke5mdONDPro02Yl0i5bk+0XPYhm5Ci5IMU8vfWPEn5SgRcprQ9dBM7NOwAi0retvj4FxCPbIZRxaTxuYbvZdJ4ZTnw/mT8oMBsrAnM6cu+sF4a4szjNjLvjsOs+NReFXBz6qvSLUn6PWfTsRwmNK8/RK3W0PUi18oRY/masUo+Mp/r2RsQlNuslsI= + - secure: E8DPoNhxnPHNIlBn5HiBb/D+LGyNETZjgMgS2Dyb26y8DSdQTnSexj0uFfLWDPeD6T6v0UEO+WOhChkCXdR/lOb6IjVuRtB0YTq/WJfROqtI3rtDQXoHKR+SeVsOZYoTDGfLZTdSrSPHH2+/Gk7H+3m00QmrIInHISQySKltlY5bge1udtcAFxoBkFX4iMslFC4a9GS1Hac6ZoiEBbCVwj+2qn9cz263hocMZfHsqXTMxbzWYIg02vgGrL3lZXLqsOcbkrRjxJevYfB1FPLxLU6jCwdII8VxfwMVoQBvS+NvvrMMydTLCEEEEJknpGxV9fE6ncZOLZ99xYqxmPzLtQ3ztvSN4ACavrzrsGeI5Vc0t5wX0IZ6CadSyXw9A47icWMdY/psH5og2GsV51XUx4iPB+VS3TxB8VyVvcVoHLH8xPYlntny+ZlqAGQPsuimfO76FpWse4EVA9+Eu/1VbiTGkbByNMUXNXcP6e6IxqbWk7rRRbvVYwxw6RUD7JP4f6z6MmgUyhvyN+W3wvt+8sxfbH9VFbGDQN+zHVarsRn3FAT/v5hUS1zFgO1J5q0g3PJEPxtvPvMOG+Mm3DpbWRVfR4ELn+FbXPhgk54gRJ/uM1n9/ZrJXgaHgSlV9jMaHiZPP1MNmDqewG8PCUjI4jXHZ2T0QGFjF5t5lml3Y/s=