Closed reviews

 

Content Information Type Specification for 3D Product Models, 3DPM

Opening date: July 15, 2024

Closing date: October 15, 2024

Abstract

The CITS 3DPM is a Content Information Type Specification (CITS) for 3D Product Models as used in the engineering and aerospace industries. The specification is designed to be used for the transfer to archives as well as for records exchange between different 3D Product Model systems. The specification is supported by METS profiles for the Root and Representation METS files and accompanying Guideline document. The 3D Product Model content specification limits its scope to the area of 3D digital product data such as computer aided design (CAD) or product data model (PDM) data where there is a current international standard for the long term archiving of this class of data in the LOTAR “Long Term Archiving and Retrieval of digital technical product information” ,  which is published as the EN and NAS 9300 series. However, although LOTAR extensively references and extends ISO 14721 the “Open reference model for Archiving Information System”, (OAIS) it does not extend into areas detailed in the E-ARK common specification for information packages (CSIP). LOTAR references and builds on ISO 10303, the Standard for the Exchange of Product model data (STEP) and so with this E-ARK 3DPM CITS we have the opportunity to add to an existing layered standards model.

If you would like to give suggestions on the documents please add these as comments in your downloaded version of the pdf documents and upload these in the designated area of the survey.

 

Documents

Specification: https://github.com/DILCISBoard/CITS-3DPM/tree/rel/v1.0.0/specification

Guideline : https://github.com/DILCISBoard/CITS-3DPM/tree/rel/v1.0.0/guideline

METS Profiles: https://github.com/DILCISBoard/CITS-3DPM/tree/rel/v1.0.0/profile

Example packages : https://github.com/DILCISBoard/CITS-3DPM/tree/rel/v1.0.0/examples

 

The questions we want you to answer in your feedback are the following

  • Do you think it is helpful to reference requirements in the LOTAR standard within the 3DPM CITS?
  • Should references to LOTAR be contained only in the Guideline document?
  • Are there requirements which you think are missing?
  • Are there requirements which you think are not relevant?
  • Are there requirements which you think are too ambitious?
  • Are there requirements which you think are not ambitious enough?
  • Do you disagree with any of the cardinality or levels?
  • Do you think that the example package is useful?
  • Is there anything else you would like to see in the repository?
  • Can you aid us with further examples?
  • Do you have any further comments regarding CITS 3DPM?

Your feedback can be entered here: Feedback period closed

 

2024 eHealth1 Review

Opened: 12 February 2024

Closed: 14 April 2024

Content Information Type Specification for Patient Medical Records, eHealth1

The CITS eHealth1 has undergone major and minor revisions following feedback from the National Health Archive (NHA) in Norway and from the E-ARK Validation Group regarding an issue with the use of representations within eHealth1 that could cause issues with validation. The documents have also received improvements from the author for usability and maintenance. The changes impact the specification, guideline and METS profiles for root and representation. The changes are as follows:

Major Changes

  • Change of patient record aggregation method in packages to remove issue of representations having different information content as identified by the E-ARK Validation Group
  • Updated representation METS profile

Minor Changes

  • Removal of duplication of requirements with CSIP and package specifications
  • Minor corrections to METS requirements cardinality and levels
  • Corrections to examples
  • Updated requirements format to match CSIP
  • Updated example METS to match CSIP
  • Updated standard text to align with CSIP
  • New diagrams
  • Updated glossary
  • Added general requirements
  • Added statement of principles
  • Added explanation of the use case for archiving patient medical records from database systems using SIARD
  • Further explanation given regarding the aggregation of patient medical records into single submissions by producers
  • Contextual and explanatory content moved to Guideline only
  • Example added to the Guideline of the piql E-ARK3 eHealth1 SIP Creator tool
  • Rationales added for statements of principle in the Guideline
  • Updated root METS profile

If you would like to give suggestions on the documents please add these as comments in your downloaded version of the pdf documents and upload these in the designated area of the survey.

Documents

Specification: https://github.com/DILCISBoard/CITS-EHEALTH1/tree/rel/2.0.0/specification

Guideline : https://github.com/DILCISBoard/CITS-EHEALTH1/tree/rel/2.0.0/guideline

METS Profiles: https://github.com/DILCISBoard/CITS-EHEALTH1/tree/rel/2.0.0/profile

The questions we want you to answer in your feedback are the following

  • Do you foresee a need for hybrid packages with both structured document (case, document) and database content?
  • Are there requirements which you think are missing?
  • Are there requirements which you think are not relevant?
  • Are there requirements which you think are too ambitious?
  • Are there requirements which you think are not ambitious enough?
  • Do you disagree with any of the cardinality or levels?
  • Can you aid us with further examples?
  • Do you have any further comments regarding CITS eHealth1?

Your feedback can be entered here: Feedback period closed

 

2020 - 2021 Review Group 5

Opened: 15 June 2021

Closed: 18 July 2021

Specification for the E-ARK Content Information Type Specification for digital geospatial data records archiving (CITS Geospatial)

The CITS Geospatial draft version 3.0.0 is an updated version of the specification, defining the approach to preserve all types of digital geospatial records. Key changes in this version include a revised structure of geodata elements and its placement within the eArchiving Information Package. In addition, CITS GIS has now been integrated into CITS Geospatial.

CITS PDF: 25_DRAFT_CITS_Geospatial_v3.pdf

METS Profile for ROOT: E-ARK-Geospatial-ROOT.xml

METS Profile for REPRESENTATION: E-ARK-Geospatial-REPRESENTATION.xml

The questions we want you to answer in your feedback are the following:

  • Do you agree that a separate CITS GIS is not needed?
  • Are the requirements for data in CITS Geospatial specification suitable for your purpose in your organisation (archive, library, company, etc.)?
  • Do the proposed requirements for Documentation and Metadata cover your needs for preserving geospatial records?
  • Do you agree that the proposed subfolders of a documentation folder should be mandatory?
  • If the proposed subfolders of a documentation folder shouldn’t be mandatory how would you ensure that the mandatory elements are present?
  • Do you agree with the naming of the documentation subfolders?
  • Does this way of grouping documentation and data make sense to you?
  • Would you want to differentiate between “Rendering” and “Behaviour”?
  • Are the proposed requirements appropriate for your need for validation?
  • Do you already use any Long Term Preservation Profiles for geospatial records and its validation?
  • If you are using a Long Term Preservation Profile would you be willing to share it with us?
  • Do you use METS for describing information packages?
  • If you already are a METS user, is the level of information in the METS files suitable for your need for validation?
  • Do you need further requirements for how to group and reference files in an Information Package using the METS file?
  • Should files in the Information Package with relations between them be grouped using subfolders?
  • Would you be able to implement the CITS Geospatial specification as a suitable Information Package structure for preserving and documenting Geospatial data?

Your feedback can be entered here: Feedback closed

 

Guideline for the specification for the E-ARK Content Information Type Specification for digital geospatial data records archiving (CITS Geospatial)

The purpose of this guideline is to further explain and describe the “specification for the E-ARK Content Information Type Specification for digital geospatial data records archiving” (also called CITS Geospatial). The goal is that as many people as possible will be able to understand the specification and, therefore, to also preserve geodata.

Guideline PDF: 26_DRAFT_Guideline_CITS_Geospatial.pdf

Guideline Appendix 1 PDF: 27_DRAFT_Guideline_CITS_Geospatial_Appendix_1.pdf

Guideline Appendix 2 PDF: 28_DRAFT_Guideline_CITS_Geospatial_Appendix_2.pdf

Guideline Appendix 3 PDF: 29_DRAFT_Guideline_CITS_Geospatial_Appendix_3.pdf

The questions we want you to answer in your feedback are the following:

  • Does this guideline adequately describe the requirements in the CITS?
  • If the guideline does not fulfill your needs, where would more explanation be beneficial?
  • Do you have some further comments regarding this Guideline?
  • Can you help us with examples of the formats and standards you use when transferring geospatial records to aid with creating more profiles?
  • Will appendix 1 help you in preserving geodata in the form of GML 3.2.1?
  • Will appendix 2 help you in preserving geodata in the form of TIFF baseline 6?
  • Will appendix 3 will aid you in mapping the INSPIRE directive metadata to a finding aid?
  • Do you have any further comments regarding the appendixes?
  • Do you want to help with the future development of this guideline and its appendices?

Your feedback can be entered here: Feedback closed

 

Guideline for using the specification for the E-ARK Content Information Type Specification for digital geospatial data records archiving (CITS Geospatial) with GIS

The purpose of this document is to extend the Guideline for CITS Geospatial with content describing preservation of selected elements from Geographical Information Systems (GIS). This document aims to extend the scope of preservation beyond the geospatial data records themselves and focus more on GIS elements defining geospatial information products.

Guideline for using CITS Geospatial with GIS PDF: 30_DRAFT_Guideline_CITS_Geospatial_with_GIS.pdf

The questions we want you to answer in your feedback are the following:

  • Does this guideline adequately describe the requirements in the CITS?
  • If the guideline do not fulfill your needs, where would more explanation be beneficial?
  • Are there topics you would like the guideline to address which are currently not mentioned?
  • Do you have some further comments regarding this Guideline?
  • Do you have your own guidelines for preservation of GIS that you could share?
  • Do you want to help with the future development of this guideline?

Your feedback can be entered here: Feedback closed

 

2020 - 2021 Review Group 4

Opened: 3 May 2021

Closed: 18 July 2021

 

Content Information Type Specification and guideline for eHealth 2

This is the first version of the eHealth2 specification. It defines an approach to preserve data sets exported from a cancer registry. It describes what elements need to be preserved to ensure future reuse of cancer registry export data. The eHealth2 specification defines an information package that aims to provide long-term usability and authentic interpretation of the content and context of the export created when the aggregator (international, national, researchers, etc.) requests data from the cancer registry. The eHealth2 specification is built upon ENCR, and JRC data calls in collaboration with Slovenian Cancer Registry and Slovenian National Archives.

The intended users of this document are:

  1. Cancer registries that preserve their exports long-term (that is, for example, the case in Slovenian Cancer Registry) and aggregators of exports (ENCR at JRC).
  2. Users of cancer registry data (researchers, health policymakers, etc.) who are interested in checking/researching the exports made.
  3. State/local archives, which will eventually decide which export is archival (is submitted to the archive and kept indefinitely).
  4. None of the above.

Attached to the specification is the first draft of the guidelines, indicating the structure and scope of guidelines’ content.

CITS PDF: 22_Draft_CITS_eHealth2.pdf

Guideline PDF: 23_Draft_Guideline_CITS_eHealth2.pdf

The questions we want you to answer in your feedback are the following:

  • Do you consider yourselves as users under 1), 2), 3), and/or 4)?
  • Do you have any experience with archiving the export from your database?
  • Do you think a document like this would make your work easier?
  • Can you aid us with examples?
  • Is this document self-explanatory?
  • Do you think it needs to be extended in any way?
  • Should mention and accommodation be made of any other international standards for eHealth?
  • Is the glossary of terms and their description appropriate with an adequate level of detail?
  • Does the guidelines document need more tutorial content for you to understand the specification?
  • What should we name this Content Information Type Specification?
  • Do you want to participate in the work?

Your feedback can be entered here: Feedback closed

 

E-ARK specification for Archival Information Packages (AIP) White Paper

E-ARK deliverable D4.1 (Rörden & Randmäe, 2014) introduced the concept of a pan-european AIP format. This aimed to avoid transfer costs by use of a standardised package format, enabling systems to ingest AIPs directly from storage systems without copying or restructuring. The pan-european AIP format would define standards for building modular and reusable components. These could be shared by the digital preservation community and memory organisations. With this white paper, we present the general position for a proposed change of the specification explaining to repository implementers what the benefits are. Further, it explains in rough lines what the changes would be.

PDF: 24_White_Paper_Re-purposing_the_E-ARK_AIP_format.pdf

The questions we want you to answer in your feedback are the following:

  • Do you agree with the positioning claims made in the white paper?
  • Do you agree with the aim of restructuring the AIP format as outlined in the white paper?

Your feedback can be entered here: Feedback closed

 

2020 - 2021 Review Group 3 

Opened: 14 February 2021

Closed: 16 May 2021

 

Guidelines

This group of review documents consist of Guidelines (Primers) to the content Information Type Specifications (CITS) some of the concepts are incoorporated and described in the first guideline "Guideline (Primer) for the Common Specification for Information Packages (CSIP), SIP, AIP, DIP, Preservation Metadata and Archival Information".

It is present here in its current draft form to aid with the concepts and uses of standards (OAIS, XML and more) not described in the guidelines (primers) now on review. This document does not require review comments in this review period.

PDF: 17. Draft Guideline_IP_v0_2.pdf

 

Guideline (Primer) for CITS eHealth1

This guideline (primer) describes the eHealth1 Content Information Type Specification (CITS). Some notes regarding the scope of implementation are included, but in most cases, this will not be sufficient to explain how the specification will actually be applied, due to the complexity of each system. The guideline is an evolving document, and thoroughly explained examples will be added continuously. In this review, we would like you to focus on these questions.

PDF: 18. Draft Guideline_CITS_eHealth1.pdf

The questions we want you to answer in your feedback are the following:

  • Is this kind of document useful for you as a user?
  • Does the document need more detail for you to understand the specification?
  • Does the document need more tutorial content for you to understand the specification?
  • This document is a first draft version, is there anything missing that should be included?
  • Do you have any further comments regarding the Guidelines within the eArchiving Building Block?
  • Do you want to participate in the work?

Your feedback can be entered here: Feedback closed

 

Guideline (Primer) for CITS ERMS

This guideline (primer) describes the CITS ERMS specification. Some notes regarding implementation are also present, but, in most cases, these will not be enough to explain how it is conducted in each system because of the complexity of all the systems. The guideline is an evolving document, and thoroughly explained examples will be added continuously. In this review, we would like you to focus on these questions.

PDF: 19. Draft Guideline_CITS_ERMS.pdf

The questions we want you to answer in your feedback are the following:

  • Is this kind of document useful for you as a user?
  • Does the document need more detail for you to understand the specification?
  • Does the document need more tutorial content for you to understand the specification?
  • This document is a first draft version, is there anything missing that should be included?
  • Do you have any further comments regarding the Guidelines within the eArchiving Building Block?
  • Do you want to participate in the work?

Your feedback can be entered here: Feedback closed

 

Guideline (Primer) for the CITS SIARD

The purpose of the guideline is to further explain and describe the “Content Information Type Specification for Relational Databases using SIARD” also called CITS SIARD. The goal is that as many people as possible will be able to understand the specification and therefore also to preserve relational databases. Therefore it also includes introductory sections about relational databases and their preservation. This also includes the history of SIARD and the relationship between the SIARD specification and the CITS SIARD specification. The main chapter, however, is a walkthrough of the requirements where rationales/descriptions are provided to better understand the technical requirements. In this review we would like you to focus on these questions:

PDF: 20. Draft Guideline_CITS_SIARD.pdf

The questions we want you to answer in your feedback are the following:

  • Is this kind of document useful for you as a user?
  • Does the document need more detail for you to understand the specification?
  • Does the document need more tutorial content for you to understand the specification?
  • This document is a first draft version, is there anything missing that should be included?
  • Do you have any further comments regarding the Guidelines within the eArchiving Building Block?
  • Do you want to participate in the work?

Your feedback can be entered here: Feedback closed

 

Guideline (Primer) for GitHub

This guideline (primer) describes the use and interaction with GitHub in the eArchiving Building Block. The guideline is an evolving document, and thorough explanations will be added continuously. In this review, we would like you to focus on these questions:

PDF: 21. Draft Guideline_using_GitHub_in_eArchivingBB.pdf

The questions we want you to answer in your feedback are the following:

  • Is this kind of document useful for you as a user?
  • Does the document need more tutorial content for you to understand the use of GitHub?
  • This document is a first draft version, is there anything missing that should be included?
  • Do you have any further comments regarding the Guidelines within the eArchiving Building Block?
  • Do you want to participate in the work?

Your feedback can be entered here: Feedback closed

 

2020 - 2021 Review Group 2

Opened: 20 October 2020

Closed: 17 January 2021

 

Content Information Type Specification for Electronic Records Management Systems

The CITS ERMS have been extended with the textual document as well as undergone some changes in the XML-schema. The draft of the CS ERMS document is supplied as a supplementary document for understanding the XML-schema as well as the schema generated documentation. We would like you to focus your comments on the usability of the specification. We would also like your input into the name of the specification considering records management is not a solemnly system anymore; instead, it is built upon many different parts all possible to transfer using this CITS. If you want to give suggestions in the document please add these as comments in the pdf document and upload it in the designated area.

PDF: 7. Draft CITS_ERMS_ v2.0.0.pdf

ERMS Schema documentation: Schema Documentation

XML-schema: ERMS.xsd

Schematron: erms.sch

The questions we want you to answer in your feedback are the following:

  • What should we name this Content Information Type Specification?
  • Can you aid us with examples that show the use of the specification? Please upload these to us when replying to the survey.
  • Do you have any further comments regarding CITS ERMS? Make these as comments in the pdf and upload these to us when replying to the survey.

Your feedback can be entered here: Feedback closed

 

CITS SIARD (Content Information Type Specification for Relational Databases using SIARD)

The CITS SIARD specification is a brand new specification that describes how to package SIARD-files and any accompanying external LOBs in CSIP package(s). The specification also describes how to package extra metadata and context documentation so that long term preservation and dissemination can take place for relational databases.

For aiding with understanding the use of SIARD two Case Study documents have been created. Case Study 1 describes experiences with workflows and documentation practices when implementing database preservation with SIARD and Case Study 2 describes experiences working with large databases and their preservation. If you have comments to these two documents please add as comments in the pdf and upload in the designated area.

PDF: 8. Draft CITS_SIARD_v1.2.pdf

Case Study 1: 9. Draft SIARD_Case_Study 1.pdf

Case Study 2: 10. Draft SIARD_Case_Study 2.pdf

The questions we want you to answer in your feedback are the following:

  • Are there requirements which you think are missing?
  • Are there requirements which you think are not relevant?
  • Are there requirements which you think are too ambitious?
  • Are there requirements which you think are not ambitious enough?
  • Do you disagree with some of the MoSCoW?
  • Do you think that there are contradictory requirements? If so, which do you weigh the highest?
  • Do you think that there is a need for a specification (and supporting tools) for a submission agreement for relational databases?
  • Are the provided documents Case Study 1 and Case Study 2 a helpful resource for your understanding?

Your feedback can be entered here: Feedback closed

 

Request For Comments on the standard SIARD 2.2 RFC

The SIARD file format version 2.2 Request for Comments is based on SIARD 2.1.1 and is strictly focused on what is needed to ensure scalability, esp. handling large objects outside the SIARD file according to SQL:2008, chapter 9 SQL/MED. SIARD 2.2 should be fully backward compatible with SIARD 2.1.1. All other requests for change, be it additions, replacements or removals to the SIARD File format specification have been ignored and postponed to the next revision, which we expect will come soon after this, led by the DILCIS Board. We urge all current and coming users of SIARD to give their comments to this Request for Commons version 2.2 of SIARD. And those being part of the process of creating this RFC should hold themselves back from commenting again. Having received these comments the DILCIS Board will modify the specifications and issue a new version of SIARD named SIARD 2.2.

PDF: 11. SIARD 2.2.0.10 RFC.pdf

XML-schema: metadata.xsd

Example of a SIARD file: ech-0165_oe.siard

The questions we want you to answer in your feedback are collected in this PDF: 12. Questions for SIARD 2.2 RFC.pdf

Your feedback can be entered here: Feedback closed

 

Specification for the E-ARK Content Information Type Specification for digital geospatial data records archiving (CITS Geospatial)

The GeoCITS v 2.0.4 is an updated version of the specification, defining the approach to preserve digital geospatial records. It describes what elements need to be preserved in order to ensure future reuse of geospatial records and enable creation of information products that are based on those records. Key changes in this version include a revised structure of geodata elements and its placement within the eArchiving Information Package, additional examples of possible formats and technical standards to define representation information and documentation.

PDF: 13. Draft CITS Geospatial v2.0.4.pdf

The questions we want you to answer in your feedback are the following:

  • This document is a first draft version of version 2.1, is there anything missing that should be included?
  • Does the document need more detail for you to understand the specification and the standards it is built upon, and what specifically?
  • Can you aid us with examples of the formats and standards you use when transferring geospatial records?
  • Do you have any further comments regarding CITS Geospatial data? Make these as comments in the pdf and upload these to us when replying to the survey

Your feedback can be entered here: Feedback closed

 

Content Information Type Specification for eHealth 1

The eHealth1 specification is built upon work done by the Directorate for Health in Norway on the establishment of a standard for electronically extracting health records from healthcare provider Electronic Medical Records (EMR) systems and their submission to a central health archive. The use cases envisaged for the central health archive are: a. to provide records to next of kin in compliance with open information regulation and b. to harvest the vast amount of historical healthcare-related data for medical research. The CITS takes input from the Norwegian specification on the structure of extractions from submitting systems and puts this into a framework that is compliant with the EARK common and package specifications. The eHealth1 specification also recommends the use of international domain standards for descriptive metadata. The specification is accompanied by two METS profiles for the Root and Representations within the packages.

The specification is extending the CSIP and E-ARK SIP with more elements found in the two METS Profiles attached as extra information. The extending vocabulary is also present.

PDF: 14. Draft CITS_eHealth1_v1.0.pdf

METS Profile for ROOT: E-ARK-eHealth1-ROOT.xml

METS Profile for REPRESENTATION: E-ARK-eHealth1-REPRESENTATION.xml

Vocabulary for eHealth1: eHealth1Vocabulary.xml

The questions we want you to answer in your feedback are the following:

  • Are the scenarios described and the data structures defined adequate for all likely examples of extractions from host EMR systems?
  • Should the specification be extended to allow for extraction from for example centralised Electronic Health Record systems (EHRs) and for the archiving of clinical documents such as HL7 CDAs or eHealth DSIs?
  • Should any other international standards for eHealth be mentioned and accommodated in the specification?
  • Should any other use cases for a centralised health archive be considered other than those described by the Norwegian example?
  • What should we name this Content Information Type Specification?

Your feedback can be entered here: Feedback closed

 

Content Information Type Specification for Preservation Metadata

There is now a draft of a content information type specification for preservation metadata based upon the standard Preservation Metadata Implementation Strategies (PREMIS). The CITS specification has extended and contains the information previously found in CSIP, SIP, AIP and DIP and will be extended with an XML-schema with validation rules following the CITS. The specification itself is only a starting point giving the minimum needed since preservation planning and the implementation of PREMIS will differ in all available solutions.

If you want to give suggestions in the document please add these as comments in the pdf document and upload it in the designated area when replying to the survey.

PDF: 15. Draft CITS_Preservation_metadata_v1.0.pdf

The questions we want you to answer in your feedback are the following:

  • Is a specification for Preservation Metadata needed?
  • Do you see that this basic preservation metadata setup is enough or do you want to propose extensions and changes?
  • We are using the environment description part in PREMIS for describing softwares that can be used to show the digital object. We would like your input on this approach.
  • The specification only gives recommendations on identifiers. Do you think it should be more regulated and if yes can you aid with giving input on how it should look.

Your feedback can be entered here: Feedback closed

 

Content Information Type Specification for Archival Information

When the digital information is transferred, it needs to be accompanied in most cases by archival information giving the order of the material, and information about the creator. This specification endorses the use of currently available profiles using the formats, EAD, EAD2002, EAD3, EAC-CPF, EAG and RiC. The use of the Archives Portal Europe Profiles is specifically encouraged because they allow information to be transferred to the portal and Europeana thereby making digital objects available globally.

PDF: 16. Draft CITS_Archival_Information_v1.0.pdf

The questions we want you to answer in your feedback are the following:

  • Are the proposed types of archival information types sufficient for describing all the types of archival information needed? If, No, please give us examples of which more standards do you propose we should define to be used from the beginning?
  • In your experience of using the different available archival information standards what more can the eArchiving building block provide you with to be able to use them?
  • What do you see should be explained more regarding this CITS in the Guideline which covers the CSIP as well as the archival information?

Your feedback can be entered here: Feedback closed

 

2020-2021 Review Group 1

Opened: 31 August 2020

Closed: 15 November 2020

 

Guideline (Primer) for the Common Specification for Information Packages (CSIP), SIP, AIP, DIP, Preservation Metadata and Archival Information

This guideline (primer) describes the core IP specifications with the accompanying preservation metadata and archival information needed to create a complete package. The underlying standards, such as the OAIS Reference Model, XML, and METS, are described in a user-friendly way. Some notes regarding implementation are also present, but, in most cases, these will not be enough to explain how it is conducted in each system because of the complexity of all the systems. The principles for a package are also described and explained. The guideline will be an evolving document, and thoroughly explained examples will be added continuously. In this review, we would like you to focus on the questions below.

PDF: 1. Draft Guideline IP.pdf

The questions we want you to answer in your feedback are the following:

  • Is this kind of document useful for you as a user?
  • Does the document need more detail for you to understand the specifications and the standards they are built upon?
  • Does the document need more tutorial content for you to understand the specifications and the standards they are built upon?
  • This document is a first draft version, is there anything missing that should be included?
  • Do you have any further comments regarding the Guidelines within the eArchiving Building Block?

Your feedback can be entered here: Feedback closed

 

Guidelines for creating a new Content Information Type Specification

A series of procedures are required to create and maintain the specifications within the eArchiving Building Block. These include the creation of a specification, the review of a specification, and update of a specification. The following procedure considers the creation of a Content Information Type Specification (CITS).

PDF: 2. Draft Specification creation guideline v1.1.pdf

The questions we want you to answer in your feedback are the following:

  • Is this kind of document useful for you as a creator of a specification to be used in the eArchiving Building Block?
  • Can you provide any input to improve this procedure and document?
  • Based on your experience are there any steps missing in this procedure?
  • Do you have any further comments regarding the Procedures within the eArchiving Building Block?

Your feedback can be entered here: Feedback closed

 

Open review guidelines for eArchiving Building Block specifications and documentation

A series of procedures are required to create and maintain the specifications within the eArchiving Building Block. These include the creation of a specification, the review of a specification, and update of a specification. The following procedure considers the open review guidelines for eArchiving Building Block specifications and documentation.

PDF: 3. Draft Specification review guideline v0.1.pdf

The questions we want you to answer in your feedback are the following:

  • As a creator of a specification to be used in the eArchiving Building Block, is this kind of document useful for you when the specification will be subject for an open review?
  • Can you provide any input to improve this procedure and document?
  • Based on your experience are there any steps missing in this procedure?
  • Do you have any further comments regarding the Procedures within the eArchiving Building Block?

Your feedback can be entered here: Feedback closed

 

Guidelines for revision of Common Specifications and Content Information Type Specifications

A series of procedures are required to create and maintain the specifications within the eArchiving Building Block. These include the creation of a specification, the review of a specification, and update of a specification. The following procedure considers the Guidelines for revision of Common Specifications and Content Information Type Specifications.

PDF: 4. Draft Specification revision guideline v1.1.pdf

The questions we want you to answer in your feedback are the following:

  • As a maintainer of a specification to be used in the eArchiving Building Block, is this kind of document useful for you when the specification will be subject for an update through revision?
  • Can you provide any input to improve this procedure and document?
  • Based on your experience are there any steps missing in this procedure?
  • Do you have any further comments regarding the Procedures within the eArchiving Building Block?

Your feedback can be entered here: Feedback closed 

 

Figure production for eArchiving Building Block specifications and their guidelines

A series of procedures are required to create and maintain the specifications within the eArchiving Building Block. These include the creation of a specification, the review of a specification, and update of a specification. The following procedure considers figure production for eArchiving Building Block specifications and their guidelines.

PDF: 5. Draft figure creation guideline v0.1.pdf

The questions we want you to answer in your feedback are the following:

  • As a creator of a specification to be used in the eArchiving Building Block, is this kind of document regarding figure production useful for you?
  • Can you provide any input to improve this procedure and document?
  • Based on your experience are there any steps missing in this procedure?
  • Do you have any further comments regarding the Procedures within the eArchiving Building Block?

Your feedback can be entered here: Feedback closed

 

Procedure for vocabulary creation in a Common Specification or Content Information Type Specifications

A series of procedures are required to create and maintain the specifications within the eArchiving Building Block. These include the creation of a specification, the review of a specification, and update of a specification. The following procedure considers vocabulary creation for a Common Specification or Content Information Type Specifications.

PDF: 6. Draft Vocabularies guideline v0.1.pdf

The questions we want you to answer in your feedback are the following:

  • As a creator of a specification to be used in the eArchiving Building Block, is this kind of document regarding vocabulary creation useful for you?
  • Can you provide any input to improve this procedure and document?
  • Based on your experience are there any steps missing in this procedure?
  • Do you have any further comments regarding the Procedures within the eArchiving Building Block?

Your feedback can be entered here: Feedback closed 

 

2018 DILCIS specification review

We kindly invite you to review the following eArchiving specifications. Originally created by the E-ARK project and enhanced and stabilised by the E-ARK4ALL project, these specifications are a core component of the CEF eArchiving Building Block.

The specifications have been released for review in two groups. In the first group, the ‘Common Specification for information Packages’ and the ‘Common Specification for Electronic Records Management Systems’ were released for review. In the second group, the E-ARK SIP, E-ARK AIP, E-ARK DIP, the SIARD Format Specification and the Common Specification for Geodata were released for review.

Your completed feedback on the specifications can be entered on this page: Feedback closed

The closing date for the review is February 24, 2019.

 

The material to be reviewed can be found here:

Common Specification for information Packages (CS IP)

The core of E-ARK specifications is the Common Specification for Information Packages. This delivers a basic core specification providing a necessary minimum for institutions across Europe to securely package their data, and then customise their data as required. For CS IP we would like you to review the full document and give comments on its principles and structural requirements in Part 1 as well as the implementation in Part 2.

Text: http://earkcsip.dilcis.eu/

PDF: https://github.com/DILCISBoard/E-ARK-CSIP/blob/master/specification/pdf/E-ARK-CSIP-2_0_0-draft.pdf

XML: https://github.com/DILCISBoard/E-ARK-CSIP/tree/master/schema and https://github.com/DILCISBoard/E-ARK-CSIP/tree/master/profile

 

Common Specification for Electronic Records Management Systems

For CS ERMS we would like you to review the new XML-schema. The draft of the ERMS document is supplied as a supplementary document for understanding the XML-schema as well as the schema generated documentation.

XML-schema with its Schematron document: https://github.com/DILCISBoard/E-ARK-ERMS/tree/master/Schema

XML-schema documentation (PDF):https://github.com/DILCISBoard/E-ARK-ERMS/blob/master/Schema/ERMS_draft_Schema_Documentation/pdf/ERMS_draft.pdf

Draft CS ERMS specification (PDF): https://github.com/DILCISBoard/E-ARK-ERMS/blob/master/Specification/DRAFT_CS_ERMS.pdf

 

E-ARK Profile for Submission Information Packages (E-ARK SIP)

This customised profile for the E-ARK Submission Information Packages (SIP) is for sending material to a repository. It builds upon CSIP.

Text: https://github.com/DILCISBoard/E-ARK-SIP/blob/master/specification/E-ARK-SIP_specification-v2.0.0-DRAFT.md

PDF: https://github.com/DILCISBoard/E-ARK-SIP/blob/master/specification/pdf/E-ARK-SIP-specification-v2.0-DRAFT.pdf

XML: https://github.com/DILCISBoard/E-ARK-SIP/tree/master/schema and https://github.com/DILCISBoard/E-ARK-SIP/tree/master/profile

 

E-ARK Profile for Archival Information Packages (E-ARK AIP)

This customised profile for the E-ARK Archival Information Packages (AIP) is for storing material in a repository. This builds upon CSIP.

All information in GitHub: https://github.com/DILCISBoard/E-ARK-AIP/releases/tag/v1.1

PDF: https://github.com/DILCISBoard/E-ARK-AIP/releases/download/v1.1/aip-specification.pdf

 

E-ARK Profile for Dissemination Information Packages (E-ARK DIP)

This customised profile for the E-ARK Dissemination Information Packages (DIP) is for accessing material from a repository. This builds upon CSIP.

Text: https://github.com/DILCISBoard/E-ARK-DIP/blob/master/specification/index.md

PDF: https://github.com/DILCISBoard/E-ARK-DIP/blob/master/specification/index.md.odt.edt.pdf

 

Software Independent Archival of Relational Databases (SIARD 2.1)

SIARD (Software Independent Archival of Relational Databases) is a normative description of a file format for the long-term preservation of relational databases. The format was developed by the Swiss Federal Archives and revised in conjunction with E-ARK.

SIARD format 2.1 (English): https://github.com/DILCISBoard/SIARD/blob/master/specification/2018-12-04_SIARD_Format_Version-2_1-English.pdf

SIARD format 2.1 (German): https://github.com/DILCISBoard/SIARD/blob/master/specification/2018-12-04_SIARD_Foramt_Version-2_1-German.pdf

SIARD format XML-schema: https://github.com/DILCISBoard/SIARD/blob/master/schema/metadata.xsd

 

E-ARK Content Information Type Specification for Geodata (E-ARK Geodata)

This is the geodata specification.

PDF: https://github.com/DILCISBoard/E-ARK-Geodata/blob/master/Specification/CSGeo_v1_1_DRAFT.pdf

Latest news