├── .github └── workflows │ ├── on_push.yml │ └── on_release.yml ├── .gitignore ├── .markdownlintrc ├── .prettierrc ├── LICENSE.md ├── README.md ├── build ├── Dockerfile.book ├── Dockerfile.single ├── convert_book.sh └── convert_single.sh ├── files ├── drafts │ ├── RFC-0006 │ │ ├── RFC-0006.md │ │ └── Time-Machine_Information-Mushroom.png │ ├── RFC-0007 │ │ ├── 4Dmap.png │ │ ├── RFC-0007.md │ │ ├── TMO_pillars.png │ │ └── TMO_simulation.png │ ├── RFC-0008 │ │ └── RFC-0008.md │ ├── RFC-0070 │ │ └── RFC-0070.md │ └── RFC-0071 │ │ └── RFC-0071.md ├── preface │ └── preface.md ├── releases │ ├── RFC-0000 │ │ ├── RFC-0000.md │ │ └── rfc_process.jpg │ ├── RFC-0001 │ │ └── RFC-0001.md │ ├── RFC-0002 │ │ └── RFC-0002.md │ ├── RFC-0003 │ │ ├── RFC-0003.md │ │ └── images │ │ │ ├── phase_1.drawio │ │ │ ├── phase_1.png │ │ │ ├── phase_2.drawio │ │ │ ├── phase_2.png │ │ │ ├── phase_3.drawio │ │ │ └── phase_3.png │ ├── RFC-0004 │ │ └── RFC-0004.md │ ├── RFC-0005 │ │ ├── LTM_Map1.jpg │ │ ├── LTM_Map2.jpg │ │ ├── LTM_Project.jpg │ │ ├── LTM_Project_Data.jpg │ │ ├── LTM_Project_Description.jpg │ │ ├── LTM_Project_Description_Institution.jpg │ │ ├── LTM_Project_Geographic_AddLocation.jpg │ │ ├── LTM_Project_Geographic_LocationList.jpg │ │ ├── LTM_Project_Geographic_ZoneofCoverage.jpg │ │ ├── LTM_Project_Name_and_Period.jpg │ │ ├── LTM_Project_Review.jpg │ │ ├── LTM_Schema.jpg │ │ ├── LTM_Webspace.jpg │ │ └── RFC-0005.md │ ├── RFC-0014 │ │ └── RFC-0014.md │ ├── RFC-0033 │ │ ├── RFC-0033.md │ │ └── images │ │ │ ├── RFC-0033-pipeline.png │ │ │ └── pipelines.png │ ├── RFC-0034 │ │ └── RFC-0034.md │ ├── RFC-0035 │ │ └── RFC-0035.md │ ├── RFC-0036 │ │ └── RFC-0036.md │ └── RFC-0069 │ │ └── RFC-0069.md └── template │ └── RFC-template.md └── tm_logo.png /.github/workflows/on_push.yml: -------------------------------------------------------------------------------- 1 | name: Compile artifacts when pushing to any branch. 2 | 3 | on: push 4 | 5 | jobs: 6 | build: 7 | runs-on: ubuntu-latest 8 | 9 | steps: 10 | - uses: actions/checkout@v2 11 | 12 | - uses: rlespinasse/github-slug-action@v5 13 | 14 | - name: Create version number 15 | run: echo "VERSION=commit-${{ env.GITHUB_SHA_SHORT }}" >> $GITHUB_ENV 16 | 17 | - name: Build the Docker image that creates the RFC-PDFs 18 | run: docker build $GITHUB_WORKSPACE/build -f $GITHUB_WORKSPACE/build/Dockerfile.single -t time-machine-project/publish_pdfs 19 | 20 | - name: Create the drafts output directories 21 | run: mkdir -p out/drafts 22 | 23 | - name: Create the releases output directories 24 | run: mkdir -p out/releases 25 | 26 | - name: Create the draft PDFs 27 | run: 28 | docker run -e VERSION=${{ env.VERSION }} -v $GITHUB_WORKSPACE/files/drafts:/opt/input -v $GITHUB_WORKSPACE/out/drafts:/opt/output time-machine-project/publish_pdfs 29 | 30 | - name: Create the release PDFs 31 | run: docker run -e VERSION=${{ env.VERSION }} -v $GITHUB_WORKSPACE/files/releases:/opt/input -v $GITHUB_WORKSPACE/out/releases:/opt/output time-machine-project/publish_pdfs 32 | 33 | - uses: actions/upload-artifact@v4 34 | with: 35 | name: rfc_pdf_files 36 | path: out 37 | -------------------------------------------------------------------------------- /.github/workflows/on_release.yml: -------------------------------------------------------------------------------- 1 | name: Compile and attach artifact to release on release publication 2 | 3 | on: 4 | release: 5 | types: [released] 6 | 7 | jobs: 8 | build: 9 | runs-on: ubuntu-latest 10 | 11 | steps: 12 | - uses: actions/checkout@v4 13 | 14 | - name: Create version number 15 | run: echo "VERSION=${{ github.event.release.tag_name }}" >> $GITHUB_ENV 16 | 17 | - name: Build the Docker image that creates the PDF 18 | run: docker build $GITHUB_WORKSPACE/build -f $GITHUB_WORKSPACE/build/Dockerfile.book -t time-machine-project/publish_book 19 | 20 | - name: Create the output directory 21 | run: mkdir -p out 22 | 23 | - name: Create the PDF 24 | run: docker run -e VERSION=${{ env.VERSION }} -v $GITHUB_WORKSPACE/files:/opt/input -v $GITHUB_WORKSPACE/out:/opt/output time-machine-project/publish_book 25 | 26 | - name: Upload the artifacts 27 | uses: alexellis/upload-assets@0.4.0 28 | with: 29 | asset_paths: '["./out/*.pdf"]' 30 | env: 31 | GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} 32 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | # Folders 2 | .vscode 3 | .devcontainer 4 | output 5 | 6 | # Files 7 | *.pdf 8 | 9 | mermaid-images 10 | 11 | .DS_Store 12 | -------------------------------------------------------------------------------- /.markdownlintrc: -------------------------------------------------------------------------------- 1 | { 2 | "MD013": { 3 | "tables": false, 4 | "headings": false, 5 | "code_blocks": false 6 | }, 7 | "MD025": false, 8 | "MD046": { 9 | "style": "fenced" 10 | } 11 | } 12 | 13 | -------------------------------------------------------------------------------- /.prettierrc: -------------------------------------------------------------------------------- 1 | proseWrap: "always" 2 | -------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2022 Time Machine Project 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy of 6 | this software and associated documentation files (the "Software"), to deal in 7 | the Software without restriction, including without limitation the rights to 8 | use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of 9 | the Software, and to permit persons to whom the Software is furnished to do so, 10 | subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS 17 | FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR 18 | COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER 19 | IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN 20 | CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. 21 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | [![TM Logo](tm_logo.png)](https://www.timemachine.eu) 2 | 3 | # Requests for Comments 4 | 5 | This repository is the main location for work on and release of finalised Time 6 | Machine _Request for Comments_. 7 | 8 | ## RFCs in preparation 9 | 10 | | ID | Title | Draft file | 11 | | -------- | ------------------------------------------------ | ------------------------------------------------ | 12 | | RFC-0006 | RFC on Technical Charter | [RFC-0006.md](files/drafts/RFC-0006/RFC-0006.md) | 13 | | RFC-0007 | RFC on Vision Mission and Values Charter | [RFC-0007.md](files/drafts/RFC-0007/RFC-0007.md) | 14 | | RFC-0008 | RFC on Intellectual Property Rights and Licenses | [RFC-0008.md](files/drafts/RFC-0008/RFC-0008.md) | 15 | | RFC-0070 | RFC on Project Scouting Service | [RFC-0070.md](files/drafts/RFC-0070/RFC-0070.md) | 16 | | RFC-0071 | RFC on Time Machine Academies | [RFC-0071.md](files/drafts/RFC-0071/RFC-0071.md) | 17 | 18 | ## Published RFCs 19 | 20 | | ID | Title | File | 21 | | -------- | ------------------------------------------------- | -------------------------------------------------- | 22 | | RFC-0000 | RFC on RFCs | [RFC-0000.md](files/releases/RFC-0000/RFC-0000.md) | 23 | | RFC-0001 | RFC on RFC Glossary | [RFC-0001.md](files/releases/RFC-0001/RFC-0001.md) | 24 | | RFC-0002 | RFC on RFC Tree | [RFC-0002.md](files/releases/RFC-0002/RFC-0002.md) | 25 | | RFC-0003 | RFC on RFC Platform | [RFC-0003.md](files/releases/RFC-0003/RFC-0003.md) | 26 | | RFC-0004 | RFC on the RFC Editorial Committee | [RFC-0004.md](files/releases/RFC-0004/RFC-0004.md) | 27 | | RFC-0005 | RFC on LTM | [RFC-0005.md](files/releases/RFC-0005/RFC-0005.md) | 28 | | RFC-0014 | RFC on Digitisation Priorities and Data Selection | [RFC-0014.md](files/releases/RFC-0014/RFC-0014.md) | 29 | | RFC-0033 | RFC on Map and Cadaster Processing pipeline | [RFC-0033.md](files/releases/RFC-0033/RFC-0033.md) | 30 | | RFC-0034 | RFC on Audio Processing Pipeline | [RFC-0034.md](files/releases/RFC-0034/RFC-0034.md) | 31 | | RFC-0035 | RFC on Video Processing Pipeline | [RFC-0035.md](files/releases/RFC-0035/RFC-0035.md) | 32 | | RFC-0036 | RFC on Music Scores Pipeline | [RFC-0036.md](files/releases/RFC-0036/RFC-0036.md) | 33 | | RFC-0069 | RFC on Time Machine Organisation (TMO) | [RFC-0069.md](files/releases/RFC-0069/RFC-0069.md) | 34 | 35 | ## License 36 | 37 | The RFC documents, this means the content of the [files](./files) directory, are 38 | licensed under the 39 | [Creative Commons Attribution 4.0 International license (CC BY 4.0)](https://creativecommons.org/licenses/by/4.0/), 40 | while all accompanying source code, for instance the code responsible for 41 | creating the RFC Book, is licensed under the [MIT license](./LICENSE.md). 42 | -------------------------------------------------------------------------------- /build/Dockerfile.book: -------------------------------------------------------------------------------- 1 | FROM pandoc/latex:2.19 2 | 3 | RUN apk update && apk upgrade && apk add --no-cache \ 4 | bash \ 5 | dos2unix \ 6 | git \ 7 | python3 \ 8 | py3-pip \ 9 | nss \ 10 | freetype \ 11 | freetype-dev \ 12 | harfbuzz \ 13 | ca-certificates \ 14 | ttf-freefont \ 15 | ttf-dejavu 16 | 17 | RUN tlmgr install koma-script 18 | 19 | COPY ./convert_book.sh /opt/script/ 20 | 21 | RUN dos2unix /opt/script/convert_book.sh 22 | 23 | RUN chmod +x /opt/script/convert_book.sh 24 | 25 | ENTRYPOINT ["/opt/script/convert_book.sh"] 26 | -------------------------------------------------------------------------------- /build/Dockerfile.single: -------------------------------------------------------------------------------- 1 | FROM pandoc/latex:2.19 2 | 3 | RUN apk update && apk upgrade && apk add --no-cache \ 4 | bash \ 5 | dos2unix \ 6 | git \ 7 | python3 \ 8 | py3-pip \ 9 | nss \ 10 | freetype \ 11 | freetype-dev \ 12 | harfbuzz \ 13 | ca-certificates \ 14 | ttf-freefont \ 15 | ttf-dejavu 16 | 17 | COPY ./convert_single.sh /opt/script/ 18 | 19 | RUN dos2unix /opt/script/convert_single.sh 20 | 21 | RUN chmod +x /opt/script/convert_single.sh 22 | 23 | ENTRYPOINT ["/opt/script/convert_single.sh"] 24 | -------------------------------------------------------------------------------- /build/convert_book.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | # Initialize variables 4 | inpath=$1 5 | outpath=$2 6 | version=$3 7 | if [ -z "$inpath" ]; then 8 | inpath=/opt/input 9 | fi 10 | if [ -z "$outpath" ]; then 11 | outpath=/opt/output 12 | fi 13 | if [ -z "$version" ]; then 14 | version=${VERSION:=custom-build} 15 | fi 16 | pdfpath="$outpath"/RFC-Book_"$version".pdf 17 | tmppath="$outpath"/tmp 18 | mkdir -p "$tmppath" 19 | 20 | # Copy all markdown files into a single folder so relative 21 | # links to files still work in the final markdown 22 | cd "$inpath" || exit 23 | shopt -s globstar 24 | for i in **/*.md; do 25 | cp -r "$(dirname "$i")"/* "$tmppath" 26 | done 27 | 28 | cd "$tmppath" || exit 29 | 30 | # Create basic markdown content with yaml header 31 | read -r -d '' text < 47 | 48 | 49 | -------------------------------------------------------------------------------- /files/drafts/RFC-0006/Time-Machine_Information-Mushroom.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/time-machine-project/requests-for-comments/46f660f7b259c2c4a3ed4e79d9ccfc06f150f0f8/files/drafts/RFC-0006/Time-Machine_Information-Mushroom.png -------------------------------------------------------------------------------- /files/drafts/RFC-0007/4Dmap.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/time-machine-project/requests-for-comments/46f660f7b259c2c4a3ed4e79d9ccfc06f150f0f8/files/drafts/RFC-0007/4Dmap.png -------------------------------------------------------------------------------- /files/drafts/RFC-0007/RFC-0007.md: -------------------------------------------------------------------------------- 1 | --- 2 | # Don't change this header section 3 | title: "RFC on Vision, Mission and Values Charter " 4 | subtitle: "Time Machine RFC-0007" 5 | author: 6 | - Juha Henriksson 7 | header-includes: 8 | - \usepackage{fancyhdr} 9 | - \pagestyle{fancy} 10 | - \fancyhead[R]{} 11 | - \fancyfoot[L]{-release-version-} 12 | output: pdf_document 13 | --- 14 | 15 | # Motivation 16 | 17 | Globalisation, changing demographics and the dominant position of private social media platforms threaten Europe's cultural and democratic values and sense of belonging. Pluralistic and democratic dialogue in Europe has traditionally been facilitated by important intermediaries, such as cultural media and institutions acting as cornerstones of our shared values, principles, and memories. 18 | 19 | Today, the dialogue between different actors and the historical visions they embody is complicated by the rise of private digital platforms that have created a new space of opinion-leadership, as well as new forms of political expression and participation. Managed by proprietary algorithms, such platforms may prioritise popularity and personal agendas over historical and cultural data, opening the way to fake news. The resulting crisis of authority that affects journalism, academia and politics has led many people to distrust information received from these institutions. 20 | 21 | These unprecedented transformations create a vital need for Europe to restore and to intensify engagement with its past as a means of facilitating an evidence-based dialogue between diverse historical memories, including their values and mutual interdependencies, building a common path across generations. 22 | 23 | **Time Machine**[^tmo1] responds to this need by building, together with other communities and organisations, the required infrastructure, and an operational environment for developing the **Big Data of the Past** that will transform and enhance the role of history and culture across Europe. In turn, opening the way for scientific and technological progress to become a powerful ally to safeguarding European identity and democratic values, in line with Europe’s long-term development and democratic principles. 24 | 25 | The duty of this **RFC-0007** is to protect the core of Time Machine and sustain its future. Becoming a Time Machine network member implies ratification of the Vision, Mission and Values Charter. 26 | 27 | # Vision 28 | 29 | Time Machine aims to develop the Big Data of the Past, creating a huge distributed digital information system mapping the European social, cultural, and geographical evolution across times. This large-scale digitisation and computing infrastructure will enable Europe to turn its long history, as well as its multilingualism and interculturalism, into a living social and economic resource. 30 | 31 | Time Machine will have strong positive long-term effects on European cohesion, economy, and society, with concrete contributions to promoting critical thinking at all levels of decision making. Time Machine will strengthen the feeling of European identity, as well as boost scientific and technological competitiveness, entrepreneurship, and employment in knowledge-intensive and creative sectors across the European Union. 32 | 33 | By pushing the frontiers of scientific research in Information and Communication Technologies (ICT) and in the Social Sciences and Humanities (SSH), Time Machine will strongly impact key sectors of European economy: ICT software, especially Augmented/Virtual Reality (AR/VR) applications, the creative industries, and tourism. Moreover, it will offer new perspectives in urban planning, land management and developing smart cities. 34 | 35 | Time Machine will enable Social Sciences and Humanities to address bigger issues, allowing new interpretative models that can smoothly transition between the micro-analysis of single artefacts and the large-scale complex networks of European history and culture. Time Machine will be a driver of open science, as well as open (public) access to public resources. 36 | 37 | The scientific vision behind the Time Machine is structured around the concept of Big Data of the Past. By plotting the amount of digital information available today against time, a funnel-shaped figure is expected to be seen. Information about the most recent years is abundant, and the curve shrinks rapidly as one moves back in time. Time Machine aims to enlarge the stem of this funnel. Firstly, by developing the technology and infrastructure needed to conduct massive digitisation and processing of cultural heritage resources. Secondly, this enlarged dataset will be the basis for simulating possible pasts to reach an unprecedented density of information: the Big Data of the Past. This enormous volume of data will also boost modelling capacity, making evidence-based predictions for the future possible. 38 | 39 | ![75 % center](TMO_simulation.png) 40 | 41 | Figure 1: Creating the Big Data of the Past (A) Current situation. (B) Extension based on digitisation and processing of new sources. (C) Extension based on simulation. 42 | 43 | Immense amounts of historical documents, collections from museums and other geo-historical datasets – including the growing amount of ‘born digital’ heritage – will be converted into a distributed digital information system, associated with very powerful computing resources. This makes it possible to set the following goals: 44 | 45 | - To digitally move through time as easily as we do through space. 46 | - To change the nature and scale of research methods in Social Sciences and Humanities. 47 | - To simulate possible futures and possible pasts. 48 | 49 | Time Machine will give birth to a **mirror-world**, representing an up-to-date model of the world as it is, as it was and as it will be. Therefore, time will become a “palpable” fourth dimension. 50 | 51 | Time Machine will shape the mirror-world according to its democratic values and fundamental ethics such as open standards and interoperability. In the mirror world approach, each city will have a **3D digital twin**. This machine-readable version of the city will be annotated digitally, thus enabling the creation of a direct link between the digital information currently on the web or any social network platform to the digital copy of the city itself. 52 | 53 | As the city’s structure and shape continuously change over time, the city’s digital twin is inherently a **4D model**. In the Time Machine approach, each LTM strives to build a dense database of spatiotemporal information, laying the foundation of a 4D map. 54 | 55 | ![75 % center](4Dmap.png) 56 | 57 | Figure 2: 4D model of a city’s digital twin. 58 | 59 | The Time Machine technical infrastructure is based on the RFC on Technical Charter (**RFC-0006**). To ensure the long-term sustainability, the governance and coordinating of Time Machine is conceived around the Time Machine Organisation (**RFC-0069**). 60 | 61 | # Time Machine Pillars 62 | 63 | The measures related to implementation of Time Machine are divided into four pillars: 64 | 65 | - Pillar 1: Science and Technology for the Big Data of the Past 66 | - Pillar 2: Time Machine Operation 67 | - Pillar 3: Exploitation Avenues 68 | - Pillar 4: Outreach and innovation 69 | 70 | **Pillar 1** addresses the scientific and technological challenges in AI, Robotics, and ICT for developing the Big Data of the Past, while boosting these key enabling technologies in Europe. A modular, layered structure of interdependent modules is adopted in three directions: 71 | 72 | - Data, enabling persistent digital access to millennia of linked historical data 73 | - Computing, developing AI methods to explore, connect, and simulate historical information 74 | - Theory, focusing on SSH models of historical evidence that lead to new, plausible narratives 75 | - Radically transforming the way in which SSH engages with and interfaces with the past 76 | 77 | **Pillar 2** aims to design the operational infrastructure and the sustainable management model for creating and deploying Time Machine, with particular focus on: 78 | 79 | - Building the Time Machine infrastructure for digitisation, processing, and simulation 80 | - Drafting the community management systems 81 | - Setting out the principles and processes for a network of **Local Time Machines** (RFC-0005) 82 | 83 | **Pillar 3** will create innovation platforms in promising application areas, by bringing together developers and users to exploit scientific and technological achievements, therefore leveraging the cultural, societal, and economic impact of Time Machine. The main areas explored cover: 84 | 85 | - Scholarship 86 | - Education 87 | - Specific exploitation areas and uses in key economic sectors, including GLAM, Creative Industries, Smart Tourism, Smart Cities & Urban Planning, and Land Use and Territorial policies 88 | 89 | **Pillar 4** will develop favourable framework conditions for outreach to all critical target groups and for guiding and facilitating the uptake of research outcomes. The main areas of intervention cover: 90 | 91 | - Dissemination 92 | - Policy, legal issues & ethics 93 | - Knowledge transfer 94 | - Exploitation support structures 95 | 96 | ![75 % center](TMO_pillars.png) 97 | 98 | Figure 3: The Time Machine overall concept and pillars 1–3. 99 | 100 | # Principles and Values 101 | 102 | The following principles and values are at the centre of Time Machine policies and practices. 103 | These principles and values are adhered in Time Machine efforts, platforms, vision, objectives, and relations with stakeholders. 104 | 105 | - Time Machine is based on European values 106 | - Time Machine strives for cohesion and bases on already extant initiatives 107 | - Time Machine acts at global scale 108 | - Time Machine is governed and led by the community 109 | - Time Machine is sustainable 110 | - Time Machine promotes openness, transparency, and inclusiveness 111 | - Time Machine leads to a more competitive EU in the fields of AI and ICT 112 | - Time Machine improves economic resilience of European cities and regions through entrepreneurship and innovation 113 | - Time Machine creates new ways of working that drive greater societal relevance for Social Science & Humanities (SSH) 114 | - Time Machine creates the Big Data of the Past informing more effective policy making 115 | - Time Machine will make EU citizens digitally literate critical thinkers that feel more connected to their past and assured of their identity in a pluralistic Europe 116 | - Time Machine will provide tools to create data-driven stories and enable citizens and journalists to validate the trustworthiness of data and stories in the media 117 | 118 | # Linked RFCs 119 | 120 | - The Time Machine infrastructure is based on the Technical Charter (**RFC-0006**) 121 | - Local Time Machines are defined in **RFC-0005** 122 | - The Time Machine Organisation (TMO) is defined in **RFC-0069** 123 | 124 | 125 | 126 | [^tmo1]: 127 | -------------------------------------------------------------------------------- /files/drafts/RFC-0007/TMO_pillars.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/time-machine-project/requests-for-comments/46f660f7b259c2c4a3ed4e79d9ccfc06f150f0f8/files/drafts/RFC-0007/TMO_pillars.png -------------------------------------------------------------------------------- /files/drafts/RFC-0007/TMO_simulation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/time-machine-project/requests-for-comments/46f660f7b259c2c4a3ed4e79d9ccfc06f150f0f8/files/drafts/RFC-0007/TMO_simulation.png -------------------------------------------------------------------------------- /files/drafts/RFC-0008/RFC-0008.md: -------------------------------------------------------------------------------- 1 | --- 2 | # Don't change this header section 3 | title: "RFC on Intellectual Property Rights and Licenses" 4 | subtitle: "Time Machine RFC-0008" 5 | author: 6 | - Juha Henriksson 7 | - Roni Iilamo 8 | - Maria Virtanen 9 | header-includes: 10 | - \usepackage{fancyhdr} 11 | - \pagestyle{fancy} 12 | - \fancyhead[R]{} 13 | - \fancyfoot[L]{-release-version-} 14 | output: pdf_document 15 | --- 16 | 17 | # Motivation 18 | 19 | Defining licenses to preserve intellectual property rights (regulating data acquisition, sharing and publishing) and to sustain the interoperability and accessibility of the TM. 20 | 21 | # General Principles 22 | 23 | According to the Open Data (OD) Directive (2019/1024)[^eur-lex3], open access to information and the right to knowledge are fundamental rights. Where digital cultural heritage is concerned, unless the use or availability of material or metadata is restricted by law, contract or ethical reason, it should be freely available for re-use. 24 | 25 | European Commission recommendation on a common European data space for cultural heritage (2021/1970)[^eur-lex4] declares that Member States should ensure that data resulting from publicly funded digitisation projects become and stay findable, accessible, interoperable and reusable (‘FAIR principles’[^go-fair]) through digital infrastructures (including the data space) to accelerate data sharing. Furthermore, article 14 of the DSM directive (2019/790)[^eur-lex2] states that when the term of protection of a work of visual art has expired, any material resulting from an act of reproduction of that work is not subject to copyright or related rights, unless the material resulting from that act of reproduction is original in the sense that it is the author's own intellectual creation. 26 | 27 | It is highly recommended that restrictions on use and availability are distinguished. Rights holders should be expressed as unambiguously as possible. The metadata should also include necessary time limits and dates related to intellectual property rights, and these should be stated unambiguously and in accordance with the standards. 28 | 29 | The exact subject of the use restrictions should be as unambiguous and clear as possible (e.g., metadata, the entire collection, the material, or some individual information in the metadata or material, or a specific instance of the material). 30 | 31 | The OD Directive states that when the reuse of a document is subject to conditions the use of standard licenses is recommended. A standard licence is defined in the OD Directive as “a set of predefined reuse conditions in a digital format, preferably compatible with standardised public licences available online”. Thus, licences should be identified with URIs, which should resolve to the description of the licence[^joinup]. If a local or national licence is used, its description should link to a well-known licence on which it is based. 32 | 33 | “European Commission’s guidelines on recommended standard licences, datasets and charging for the reuse of documents”[^eur-lex1] regulates the use licences. In. addition, according to the “Decision of 22.2.2019 adopting Creative Commons as an open licence under the European Commission’s reuse policy”[^ec], the European Commission has adopted “Creative Commons – Attribution BY” as an open license for the Commission’s reuse policy. In addition, the Decision states that, “without prejudice to the preceding article, raw data, metadata or other documents of comparable nature may alternatively be distributed under the provisions of the Creative Commons Universal Public Domain Dedication deed (CC0 1.0)”. 34 | 35 | # Europeana Licensing Framework 36 | 37 | For licensing, Time Machine recommends to follow the Europeana Licencing framework if possible[^pro4]. 38 | Europeana uses 14 standardised rights statements[^pro3]: 39 | - Six Creative Commons[^creative] Licences 40 | - Two Creative Commons Tools 41 | - Six out of the twelve Rights Statements[^rights] 42 | 43 | Europeana encourages the use of Creative Commons Licences and Tools as much as possible to facilitate the reuse of digital cultural heritage. When they are not suitable, for example because the providing institution cannot legally apply them, Rights Statements by the Rights Statements Consortium should be used. A cultural heritage institution can only apply a CC licence if it holds all of the rights. 44 | 45 | Europeana's instructions may be followed to select the appropriate license[^pro5][^pro1]. A flowchart has been developed to facilitate selection[^pro2]. 46 | 47 | Europeana has also published Copyright management guidelines for cultural heritage insititutions[^pro6] 48 | 49 | Europeana uses two Creative Commons tools. These should be used on works that are in the public domain or that want to be dedicated to the public domain. 50 | 51 | - The Creative Commons CC0 1.0 Universal Public Domain Dedication (CC0) 52 | - The Public Domain Mark (PDM) 53 | 54 | Europeana recommends that Creative Commons Licences should be applied to works that are in copyright and for which the rightsholder wants to authorise some reuse. The six Creative Commons Licences that Europeana uses are: 55 | 56 | - Creative Commons - Attribution (BY) 57 | - Creative Commons - Attribution, ShareAlike (BY-SA) 58 | - Creative Commons - Attribution, No Derivatives (BY-ND) 59 | - Creative Commons - Attribution, Non-Commercial (BY-NC) 60 | - Creative Commons - Attribution, Non-Commercial, ShareAlike (BY-NC-SA) 61 | - Creative Commons - Attribution, Non-Commercial, No Derivatives (BY-NC-ND) 62 | 63 | Right Statements were designed to complement Creative Commons Licences. Only when CC licenses are not suitable for a specific situation, Rights Statements may be used. It should be noted that Rights Statements are not licences. 64 | 65 | The six Rights Staments that Europeana uses are: 66 | 67 | - No Copyright - non commercial re-use only (NoC-NC) 68 | - No Copyright - Other Known Legal Restriction (NoC-OKLR) 69 | - In Copyright (InC) 70 | - In Copyright - Educational Use Permitted (InC-EDU) 71 | - In Copyright - EU Orphan Work (InC-OW-EU) 72 | - Copyright Not Evaluated (CNE) 73 | 74 | 75 | # Licences for Indigenous Cultural Heritage 76 | 77 | The Europeana Licensing framework may not be suitable when licencing ingenous cultural heritage. Instead, the Traditional Knowledge (TK) Labels may be used[^local]. Labels are digital markers that define attribution, access, and use rights for Indigenous cultural heritage. Twenty TK Labels have been developed through direct community partnership and collaboration. Each TK Label can be adapted and customized to reflect ongoing relationships and authority including proper use, guidelines for action, or responsible stewardship and re-use. 78 | 79 | Provenance Labels identify the group or sub-group which is the primary cultural authority for the material, and/or recognizes other interest in the materials. Provenance Labels are TK Attribution (TK A), TK Clan (TK CL), TK Family (TK F), TK Multiple Communities (TK MC), TK Community Voice (TK CV), and TK Creative (TK CR). 80 | 81 | Protocol Labels outline traditional protocols associated with access to this material and invite viewers to respect community protocols. Protocol Labels are TK Verified (TK V), TK Non-Verified (TK NV), TK Seasonal (TK S), TK Women General (TK WG), TK Men General (TK MG), TK Men Restricted (TK MR), TK Women Restricted (TK WR), TK Cultural Sensitive (TK CS), and TK Secret / Sacred (TK SS). 82 | 83 | Permission Labels indicate what activities the community has approved as generally acceptable. Other uses require direct engagement with primary cultural authorities. Permission Labels are TK Open to Commercalization (TK OC), TK Non-Commercial (TK NC), TK Community Use Only (TK CO), TK Outreach (TK O), and TK Open to Collaboration (TK CB). 84 | 85 | 86 | 87 | [^creative]: 88 | [^ec]: 89 | [^eur-lex1]: 90 | [^eur-lex2]: 91 | [^eur-lex3]: 92 | [^eur-lex4]: 93 | [^go-fair]: 94 | [^joinup]: 95 | [^local]: 96 | [^pro1]: 97 | [^pro2]: 98 | [^pro3]: 99 | [^pro4]: 100 | [^pro5]: https://pro.europeana.eu/page/selecting-a-rights-statement 101 | [^pro6]: https://pro.europeana.eu/post/copyright-management-guidelines-for-cultural-heritage-institutions 102 | [^rights]: 103 | -------------------------------------------------------------------------------- /files/drafts/RFC-0070/RFC-0070.md: -------------------------------------------------------------------------------- 1 | --- 2 | # Don't change this header section 3 | title: "RFC on Project Scouting Service" 4 | subtitle: "Time Machine RFC-0070" 5 | author: 6 | - Juha Henriksson 7 | - Manuela Graf 8 | header-includes: 9 | - \usepackage{fancyhdr} 10 | - \pagestyle{fancy} 11 | - \fancyhead[R]{} 12 | - \fancyfoot[L]{-release-version-} 13 | output: pdf_document 14 | --- 15 | 16 | # Motivation 17 | 18 | The Time Machine Project Scouting Service aims to support Time Machine Organisation (TMO) members in the process of forming competitive project consortia and submitting high-quality project proposals relevant third-party funding schemes. The Project Scouting Service provides support in pre-proposal and networking areas. This will ultimately not only fortify the efforts of TMO members and their consortia but even more importantly enhance their chances at success in receiving funding. 19 | 20 | 21 | # Description 22 | 23 | The Time Machine **Project Scouting Service** [^tmo1] is a service offered exclusively to **Time Machine Organisation** (TMO) members (RFC-0069). This Service enables members of the Time Machine network to have better access to relevant third-party funding sources. 24 | 25 | Time Machine members benefit from tailored services provided by the Project Scouting team such as the identification of relevant calls for proposals and supporting the search for possible partners or capable project consortia from within the Time Machine network. 26 | 27 | The Time Machine Project Scouting Service is a free-of-charge service for founding and regular members of the Time Machine Organisation. 28 | 29 | # Benefits for TMO members 30 | 31 | The Project Scouting Service provides specialised services ranging from the initial identification of suitable calls to the connection of potential partners and consortia. 32 | 33 | This way, Time Machine members receive better access to funding resources. Furthermore, the Service enables enhanced partnerships and collaborations for greater research and innovation achievements. Finally, the Project Scouting Service paves the way for uptake of research results generated by joint efforts of the Time Machine Organisation and its members. 34 | 35 | # Services for TMO members 36 | 37 | 1. Pre-proposal Support Services 38 | - Identification of relevant calls and funding schemes for research and innovation fields matching the objectives and scope of Time Machine 39 | - Identification of possible collaborators (European research and innovation actors, projects and initiatives) for targeted calls 40 | 2. Networking Support 41 | - Organisation of partnering meetings, networking and brokerage events as well as call/project-based workshops for selected calls 42 | - Networking and matchmaking tool for members of the TMO to help forming project consortia and apply for funding 43 | 44 | # Participation Scheme 45 | 46 | Time Machine members are given the opportunity to cooperate with the Time Machine Organisation (TMO) in proposals targeted at calls within the research and innovation objectives and scope of Time Machine. 47 | 48 | The Time Machine Organisation may collaborate in various ways. Either with a Letter of Interest (LoI), by being a direct consortium partner or by acting as project coordinator. In this context, the transparent setting of rules and conditions of participation as well as the collaboration process by the Time Machine Organisation is guaranteed. 49 | 50 | A project proposal is eligible to receive support by the Project Scouting Service if: 51 | - The proposal is coordinated by a TMO member 52 | - The proposal targets a relevant third-party funding opportunity 53 | - The proposal conforms to the principles of the TMO, its vision and scope and contributes to the objectives of Time Machine (RFC-0069, RFC-0007, RFC-0002) 54 | 55 | ## Participation Case 1: TMO Cooperates with Letters of Interest (LOI) 56 | 57 | The Time Machine Organisation supports project applications of its members with a LoI if: 58 | - The proposed project is only using free-of-charge Time Machine services (e.g. project presentation on Time Machine platforms, inclusion of the project in the Time Machine project portfolio, application of public Time Machine tools within the project) 59 | - The proposed project conforms to the Time Machine principles, its vision and scope and contributes to the overall realisation of Time Machine objectives 60 | 61 | ## Participation Case 2: TMO as Consortium Partner 62 | 63 | The Time Machine Organisation may join a consortium as a partner if: 64 | - The proposed project applies Time Machine services (e.g. TMO manages the project´s dissemination tasks and community brokerage/endorsement, project sustainability is secured by integrating it´s tools into the TMO tool set) 65 | - TMO may deliver services for the proposed project itself or may contract partners with a handling fee 66 | - The proposed project conforms to the Time Machine principles, its vision and scope and contributes to the overall realisation of Time Machine objectives 67 | 68 | ## Participation Case 3: TMO Coordinates Project Proposals 69 | 70 | The Time Machine Organisation collaborates with its members in project applications that are of central interest to the Organisation. Applications of interest may be driven by the Time Machine Organisation as project coordinator if: 71 | - The proposed project in line with the overall principles of Time Machine 72 | - The proposed project conforms to the Time Machine principles, its vision and scope and contributes strategically to the overall realisation of Time Machine objectives 73 | 74 | ## Participation Case 4: TMO members receive support for their applications 75 | 76 | Members of the Time Machine Organisation are eligible to receive support in their efforts to prepare and submit project proposals even if the TMO does not directly participate in or support the application in question. Nonetheless, the following objectives must be met by the project proposal: 77 | - The proposed project in line with the overall principles of Time Machine 78 | - The proposed project conforms to the Time Machine principles, its vision and scope and contributes strategically to the overall realisation of Time Machine objectives 79 | 80 | # Linked RFCs 81 | 82 | - The Time Machine Organisation (TMO) is defined in **RFC-0069**. 83 | - Time Machine’s vision, mission, and values are defined in **RFC-0007**. 84 | - Time Machine’s scope is defined in the RFC Tree **RFC-0002**. 85 | 86 | 87 | 88 | [^tmo1]: 89 | -------------------------------------------------------------------------------- /files/drafts/RFC-0071/RFC-0071.md: -------------------------------------------------------------------------------- 1 | --- 2 | # Don't change this header section 3 | title: "RFC on Time Machine Academies" 4 | subtitle: "Time Machine RFC-0071" 5 | author: 6 | - Juha Henriksson 7 | - Ilaria Manzini 8 | - Isabella di Lenardo 9 | header-includes: 10 | - \usepackage{fancyhdr} 11 | - \pagestyle{fancy} 12 | - \fancyhead[R]{} 13 | - \fancyfoot[L]{-release-version-} 14 | output: pdf_document 15 | --- 16 | 17 | # Motivation 18 | 19 | Time Machine Academies, provided by the Time Machine Organisation (TMO), are learning events meant to foster the circulation of knowledge and expertise developed within the Time Machine community. Participants are provided with training, both theoretical and practical, on how to apply a particular tool or pipeline to their own project data. 20 | 21 | # Description 22 | 23 | **Time Machine Academies** [^tmo1] are open to **Time Machine Organisation** (RFC-0069) members and **Local Time Machine** (RFC-0005) Project partners. Some Academies may also be open to professionals from the broader GLAM and Digital Humanities sector. 24 | 25 | Time Machine members may suggest topics for these learning events, or express their interest in co-hosting a Time Machine Academy. 26 | 27 | Training provided in Time Machine Academies could, for instance: 28 | - provide information on how to build a strategy to digitise archival documents accurately and efficiently. 29 | - show how to apply VR software solutions to enhance the way visitors experience museum collections. 30 | - provide information on state of the art tools and codes for data extraction, analysis, and storage. 31 | 32 | Time Machine Academies follow the general rules for Time Machine Training (RFC-0009). 33 | 34 | # Academy structure 35 | 36 | Each Time Machine Academy consists of two to three separate classes, to allow participants to move from theory to practice by testing the tool or software on a dataset from their own project(s). There is ample space to ask detailed questions and receive tailored support from instructor(s). 37 | 38 | # Linked RFCs 39 | 40 | - The Time Machine Organisation (TMO) is defined in **RFC-0069**. 41 | - The Local Time Machines are defined in **RFC-0005**. 42 | - The general rules for Time Machine training are defined in **RFC-0009**. 43 | 44 | 45 | 46 | [^tmo1]: 47 | -------------------------------------------------------------------------------- /files/preface/preface.md: -------------------------------------------------------------------------------- 1 | # Preface 2 | 3 | This document summarizes the efforts of the Time Machine _Request for Comments_ 4 | effort. It is automatically created from the contents of the TM RFC 5 | repository[^tm_rfc_repo] and published following a loose semi-annual schedule 6 | with additional releases on important milestones. All RFCs are written by the 7 | Time Machine RFC Team and Editorial Committee as well as all individual RFC 8 | authors in a joint effort. 9 | 10 | -- _The Time Machine RFC Editorial Committee_ 11 | 12 | # License 13 | 14 | This document is licensed under the 15 | [Creative Commons Attribution 4.0 International license (CC BY 4.0)](https://creativecommons.org/licenses/by/4.0/). 16 | 17 | [^tm_rfc_repo]: 18 | -------------------------------------------------------------------------------- /files/releases/RFC-0000/RFC-0000.md: -------------------------------------------------------------------------------- 1 | --- 2 | # Don't change this header section 3 | title: "RFC on RFCs" 4 | subtitle: "Time Machine RFC-0000" 5 | author: 6 | - Frédéric Kaplan 7 | - Kevin Baumer 8 | - Mike Kestemont 9 | - Juha Henriksson 10 | - Daniel Jeller 11 | header-includes: 12 | - \usepackage{fancyhdr} 13 | - \pagestyle{fancy} 14 | - \fancyhead[R]{} 15 | - \fancyfoot[L]{-release-version-} 16 | output: pdf_document 17 | --- 18 | 19 | # Motivation 20 | 21 | Reaching consensus on the technology options to pursue in a programme as large 22 | as Time Machine is a complex issue. To ensure the open development and 23 | evaluation of work, a process inspired by the Request for Comments (RFC) that 24 | was used for the development of the Internet protocol[^ietf_rfc_791] is being 25 | adapted to the needs of Time Machine. Time Machine Requests for Comments are 26 | freely accessible publications, identified with a unique ID, that constitute the 27 | main process for establishing rules, recommendations and core architectural 28 | choices for Time Machine components. 29 | 30 | # Approach 31 | 32 | The Time Machine RFCs are based on the following principles: 33 | 34 | 1. Accessibility. **RFCs** are freely accessible, at no cost. 35 | 2. Openness. Anybody can write an **RFC**. 36 | 3. Identification. Each **RFC**, once published, has a unique ID and version 37 | number. It can nevertheless be revised over time as a living document, being 38 | republished with the same ID and a different version number. 39 | 4. Incrementalism. Each **RFC** should be useful in its own right and act as a 40 | building block for others. Each **RFC** must be intended as a contribution 41 | to, extension or revision of the Time Machine Infrastructure. 42 | 5. Standardisation. **RFCs** should aim to make use of standardised terms to 43 | improve the clarity level of its recommendation. 44 | 6. Scope. **RFCs** are designed contributions and implementation solutions for 45 | solving practical problems. **RFCs** are not research papers and may not 46 | necessarily contain experimental evidence. RFCs cover not only the technical 47 | infrastructure but the data standards, legal frameworks, and values and 48 | principles of Time Machine. 49 | 7. Self-defining process. As used for the development of the Internet, **RFCs** 50 | are the main process for establishing Time Machine Infrastructure and 51 | Processes and also the processes and roles for managing **RFCs** themselves. 52 | 53 | # RFC Publication Process 54 | 55 | ![75 % center](rfc_process.jpg) 56 | 57 | **RFC Editor** organises the publication process of the RFCs, maintains the 58 | consistency of the RFC System, appoints RFC teams to organise new RFCs and to 59 | improve existing RFCs, keeps track of RFC versioning and ensures the timely and 60 | regular publication of RFCs. The **RFC Editorial Committee** assists the RFC 61 | Editor in the publication process. The duties of the **RFC Editor**, as well as 62 | the organisation of the **RFC Editorial Committee**, are defined in 63 | **RFC-0004**. 64 | 65 | The publication process is the following : 66 | 67 | 1. The **RFC Editor** appoints authors to write the RFCs planned in the **RFC 68 | tree** (RFC-0002). Alternatively, authors may contact the **RFC Editor** to 69 | submit their candidature to write an RFC (planned in the **RFC tree** or 70 | not). 71 | 2. The authors produce an RFC draft which is reviewed by the RFC Editor, and if 72 | necessary, by the RFC Editorial Committee, for coherence with the rest of the 73 | RFC corpus, and then by a larger community. The RFC is revised and possibly 74 | sent for review again. 75 | 3. Once accepted by the **RFC Editor** after the review process, an RFC receives 76 | an official identifier and is officially published comparable to a 77 | peer-reviewed publication with proper scholarly credits assigned to the 78 | original author(s). 79 | 4. If necessary, the **RFC tree** is adapted to include the published RFC and 80 | any possible sub-RFCs planned during the writing of the RFC. 81 | 82 | # RFC Format 83 | 84 | The RFC Format and Guidelines are established iteratively by the **RFC Editor** and the 85 | **RFC Editorial Committee**. The most-up-to-date version can be found in the 86 | **RFC-0000**. 87 | 88 | Current Format 89 | 90 | 1. Motivation section 91 | 2. Series of sections describing the approach and solution 92 | 3. Question and answers (Q&A) section 93 | 4. Linked RFCs section 94 | 95 | # Question and Answers 96 | 97 | ## What are the main differences between Time Machine RFCs and Internet Society RFCs? 98 | 99 | The Time Machine RFCs are being developed over 50 years after the RFCs that 100 | shaped in the Internet. The main differences are the following: 101 | 102 | 1. Time Machine RFCs are exclusively used to describe motivated solutions and 103 | not general communication. 104 | 2. Time Machine RFCs can be revised and are redefined iteratively, whereas 105 | significant improvement on an Internet Society RFC leads to the creation of a 106 | new RFC. 107 | 108 | # Linked RFCs 109 | 110 | - The **RFC Tree** is kept up to date in **RFC-0002**. 111 | - The details of the RFC platform are defined in the **RFC-0003**. 112 | - The **RFC Editor** and the **RFC Editorial Committee** are defined in 113 | **RFC-0004**. 114 | 115 | 116 | 117 | [^ietf_rfc_791]: 118 | -------------------------------------------------------------------------------- /files/releases/RFC-0000/rfc_process.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/time-machine-project/requests-for-comments/46f660f7b259c2c4a3ed4e79d9ccfc06f150f0f8/files/releases/RFC-0000/rfc_process.jpg -------------------------------------------------------------------------------- /files/releases/RFC-0001/RFC-0001.md: -------------------------------------------------------------------------------- 1 | --- 2 | # Don't change this header section 3 | title: "RFC on RFC Glossary" 4 | subtitle: "Time Machine RFC-0001" 5 | author: 6 | - Frédéric Kaplan 7 | - Kevin Baumer 8 | - Daniel Jeller 9 | header-includes: 10 | - \usepackage{fancyhdr} 11 | - \pagestyle{fancy} 12 | - \fancyhead[R]{} 13 | - \fancyfoot[L]{-release-version-} 14 | output: pdf_document 15 | --- 16 | 17 | # Motivation 18 | 19 | The Time Machine Glossary's function is to provide clear definitions of the terms used in the RFCs and throughout related Time Machine documentation. It should be updated regularly as new RFCs are introduced and published. 20 | 21 | # Glossary 22 | 23 | 4D Map 24 | : A core element of the Time Machine which is used to locate resources, services and reconstructions. It is both the map where activities can be followed and the map that aggregates results. It is used for plotting **Local Time Machines** in particular. The density of the 4D Maps is not uniform, in particular some zones may be modelled only in 3D, 2D and even 1D, such as a list of included elements. 25 | 26 | 4D Simulator 27 | : One of the Time Machine **Engines**. It manages a continuous spatiotemporal simulation of all possible pasts and futures that are compatible with the data. The 4D Simulator includes a multiscale hierarchical architecture for dividing space and time into discrete volumes with unique identifiers. It is a simulation engine for producing new datasets based on the information stored, and each possible spatiotemporal multiscale simulation corresponds to a multidimensional representation in the 4D computing infrastructure. When a sufficient spatiotemporal density of data is reached, it can produce a 3D representation of the place at a chosen moment in History. In navigating the representation space, one can also navigate in alternative simulations of the past and future. Uncertainty and incoherence are managed at each stage of the process and are directly associated with the corresponding reconstructions of the past and the future. 28 | 29 | Annotators 30 | : Dedicated **Apps** for annotating images and documents. 31 | 32 | API 33 | : The abbreviation of *Application programming interface*. It is a contract and technical implementation that defines the ways to programmatically interact with a particular piece of software. 34 | 35 | App 36 | : An application, either web-based or not, that performs operations on Time Machine **Components**. Apps can be developed by the **Time Machine Organisation** or by third parties. Apps are pieces of software (in general built as part of official **Projects** but not necessarily) that enables users to experience and edit the information in the **Data Graph** and the **4D Map**. They can be grouped into families of Apps like the **Navigators** or the **Annotators**. 37 | 38 | Big Data of the Past 39 | : A huge distributed digital information system mapping social, cultural and geographical evolution. A key objective of Time Machine is to ensure that there is a system to bring together dense, interoperable, standardised (linked data, preferably open) and localised (marked up with spatial-temporal information) social, cultural and geographical heritage resources. 40 | 41 | Code Library 42 | : A collection of software components written in Python (and possibly later other languages) regrouping key **Operators** for processing Data in the Time Machine Environment. 43 | 44 | Component 45 | : A part of the Time Machine that is itself a Machine in the sense of systems reacting in a predictable manner to input given an internal State. Each component can react or be acted upon through a defined set of inputs / operations. Some of these operations can be internal, others can be external. Internal Operations change the internal structure or state of the Machine and therefore update its history. External Operations changes are characterised by the usage of a Component, producing an external output based on the current State of the Machine. Sequences of consecutive states permit the reconstruction of the current state of the component. 46 | 47 | Conflict Detectors 48 | : Specialized **Apps** that detect incoherence in the **Data Graph** and help users to solve them. 49 | 50 | Data Graph 51 | : A formal representation of knowledge using semantic web technologies and extracted by human or automatic processes. 52 | 53 | Data Synchronisation 54 | : An automated process that compares data documented by a project with conflicting data from another project or an inference. 55 | 56 | Digital Content Processor 57 | : An automated process extracting information from documents (images, video, sound, etc.). Level 1 Digital Content Processor labels mentions of entities. Level 2 Digital Content Processor labels relations between entities. The Digital Content Processor of Level 3 labels rules. Each process is fully traceable and reversible. The results of the processing constitute the core dataset of the **Big Data of the Past** and are integrated into the **Data Graph**. 58 | 59 | Digitisation Hubs 60 | : Decentral and local structures that offer digitisation services based on open-hardware technology. They are an example of a **Service to Local Time Machines** for digitisation (e.g. scanning of documents, streets, 3D scanning). Contractual aspects are dealt with via **Standard Contracts**. The Digitisation Hubs will enable Time Machine to seamlessly aggregate new documents and metadata into a **Data Graph** with the appropriate standards in terms of resolution, file formats and metadata assured during acquisition. As a service, it can be associated with a **Zone of Coverage** and will use **Standard Metrics** to determine the exact price of operations. As Digitisation Hubs are based on open-hardware technology they can be duplicated anywhere and can thus progressively create a dense network of service providers. 61 | 62 | Engine 63 | : An automated software mechanism that operates on the **Data Graph** to enrich it. Examples of Engines include: the **4D Simulator**, the **Large-Scale Inference Engine** and the **Universal Representation Engine**. 64 | 65 | Frontier Year 66 | : Assuming a strict **Retrochronological approach**, it is the oldest year in the past for which the **Information Skeleton** of a given place is established. This may, for instance, correspond to the data extracted from the most ancient cadastral map of a city. 67 | 68 | GeoEntities 69 | : Existing geographical entities (e.g. a list of Places documented in **OpenStreetMap**) defined as standard Geographical Information System objects (points - lines - polygons). 70 | 71 | Importers 72 | : **Apps** that enable linking of existing datasets to the **Data Graph**, for example: 73 | + IIIF Source Importer 74 | + Collection creator 75 | + Geographical Layer Importer (e.g. GeoJSON importer) 76 | + Datatable importer (e.g. CSV) 77 | + Cadastral Parcels Importer 78 | + Cloud Point Importer 79 | + Spherical Image Importer 80 | + 3D Model Importer 81 | 82 | Information Skeleton 83 | : A data structure that contains the core information of the **Data Graph**. It should be reconstructed first. 84 | 85 | Large-Scale Inference Engine 86 | : One of the Time Machine **Engines**, capable of inferring the consequences of chaining any information in the database. It enables Time Machine to induce new logical consequences of existing data and is used to shape and to assess the coherence of the **4D Simulations** based on human-understandable concepts and constraints. 87 | 88 | Local Datasets 89 | : Data produced and published about a particular place. Published Datasets are Open Access and can be freely downloaded, even if they are not yet integrated with the global **Data Graph**. They have authors and are possibly derived from other datasets. The history of their production must be documented, hence they cannot be unpublished once made available, and they appear in in the **Local Time Machine Webspace** 90 | 91 | Local Time Machine 92 | : Zones of high *rebuilding-the-past* activity density, consisting of one or multiple **Projects** operating in and on a particular zone. A Local Time Machine focuses on a **Municipality** and features the activities and the results of the Projects located in this Municipality. Standard values of activities are used to define a scale to represent a Local Time Machine. They are fully defined in *RFC-0005*. 93 | 94 | Local Time Machine Activities 95 | : Declared Activities (e.g. events, training sessions) undertaken by participants in the **Projects** of a **Local Time Machine**. 96 | 97 | Local Time Machine Community 98 | : The list of active users of a **Local Time Machine** . These include users active in **Projects** as well as users participating in crowdsourcing activities (e.g. transcription, correction, training, etc.). By default, the active users will be updated with news and announcements concerning **Local Time Machine Activities** in their declared Local Time Machine of interest. 99 | 100 | Local Time Machine Density of Operations 101 | : A key data point that characterises the number of activities underway in a given **Local Time Machine** at the given time. It characterises both the activities that are part of **Projects** and those related to Citizen Scientist activities. 102 | 103 | Local Time Machine Operations 104 | : A list of basic operations produced by **Projects** and concerning particular **GeoEntities**. They appear as a log of activities in the **Local Time Machines Webspace**. 105 | 106 | Local Time Machine Visual Plan 107 | : An automatically generated representation of the spatiotemporal focus of different **Projects** participating in a **Local Time Machine**. 108 | 109 | Local Time Machine Webspace 110 | : A part of the **Time Machine Website** dedicated to the **Local Time Machines**. It includes information on **Local Time Machine Activities**, **Services to Local Time Machines** and the **Local Datasets**. It also features information on all **Local Time Machine** **Projects** linked to a given **Municipality**. 111 | 112 | Long-term Preservation Service 113 | : Services offered by operators to enable the long-term preservation of particular datasets (e.g. IIIF repository). Some of these services may include innovative technology such as DNA storage. 114 | 115 | Memory Store 116 | : The aspect of physical artifacts as stores of complex information from and about the past. Local Time Machines use extraction tools to redocument the content of these memory stores into the **Data Graph**. 117 | 118 | Metadata 119 | : Data about data in its most narrow sense. This includes data about file formats or modification dates for digital files or information about the authorship of a book, creation date of a work of art or various handwriting patterns in a written text. 120 | 121 | Metadata Generation 122 | : The automatic generation of **Metadata** using methods of pattern recognition, machine learning and artificial intelligence. Such automated extraction methods are already being explored for hand-written text recognition and entity extraction. Yet this is only a first step, as today’s systems fail in identifying, for example, text in complex 2-D scenes such as paintings and maps and on 3-D objects such as vases and sculptures. Significant amounts of metadata currently being created by curators in museums and archives could, however, be generated automatically, such as classification of materials and object sizes, as well as linking to other public data sources such as wiki data given appropriate digitisation workflows and sensors. By doing so, Time Machine strives to create a new dimension of accessibility in digital history and cultural heritage. By indexing objects by their content, it will also be possible to link collection items at large scale, thus providing the capability to propagate metadata through these connections. In the current design, this help for metadatation will be provided through **Time Machine Tools and API**. This will enable Time Machine to combine automatic suggestions of metadata with expert curation. 123 | 124 | Municipalities 125 | : A geo-spatial division of the surface of earth into administratively non-ambiguous zones. The list of **Municipalities** is therefore that of potential Local Time Machines and is fixed and predetermined. Thus, this sets the granularity of the **Local Time Machines**. 126 | 127 | Navigators 128 | : Tools to view and query the data in Time Machine similar to the web browser for the World Wide Web. They interpret the **Data Graph** and the **4D Map** to create different processes for exploration. Various typologies of Navigators can be designed: Search Engines, Collection Browsers, 4D Browser (web-based or application-based for better performances), Data Graph Inspector / Editor, Pattern Finder / Navigators, Genealogical Explorers, etc. 129 | 130 | OpenStreetMap 131 | : A public project[^openstreetmap] to create a free and editable map of the world. It is commonly abbreviated *OSM*. 132 | 133 | Operator 134 | : Functions in the **Code Library** that can be chained in a procedural way. 135 | 136 | Operation Graph 137 | : A formal representation of the past, ongoing and future operations of the partners in the **Time Machine Network**. 138 | 139 | Place 140 | : An identified geo-spatial container in which activities can occur. A **Place** corresponds to a particular extent in space, usually determined in reference to another place. A place can be contained in another **Place** and can contain other **Places**. **Places** are symbolic entities in which temporarily extended processes can occur. A **Place** may not be determined by a geographical coordinate. Some moving entities are places (e.g. a car, a plane, a ship). 141 | 142 | Project 143 | : An operation, typically conducted by institutions or individuals that produces data for a particular or several **GeoEntities**. They may be new or redocumentation of ancient projects, can mine **Sources** and ingest their extracted data into the **Data Graph**. They are associated with a **Zone of Coverage** that links them with **Local Time Machines**, producing content for GeoEntities. They may also produce intermediary datasets that can be downloaded even if they are not yet integrated in the Data Graph. Projects can develop **Apps** that interact with the **4D Map** and the Data Graph and contribute to the **Code Library** by working on the GitHub repository of the Time Machine to produce new **Operators**. These different objectives are non-exclusive from one another. The **Project Development Space** is a space in the **Time Machine Website** that features the Apps relevant to the development of Projects. 144 | 145 | Project Repository 146 | : The central tool to monitor all active Time Machine projects. 147 | 148 | Retrochronological Approach 149 | : A way to model the traversal of information available about an entity starting from the present day and moving backwards in time, retropropagating the data precision found in the present through **Transfer**. 150 | 151 | RFC book 152 | : An automatically created PDF document containing all released and draft RFC texts for simpler reading and sharing. 153 | 154 | RFC Editor: The person responsible for managing the **Time Machine Request for Comments Process**. The role is fully defined in *RFC-0003*. 155 | 156 | RFC Editorial Committee 157 | : The people assisting the **RFC Editor** in managing the **Time Machine Request for Comments** process. This committee is fully defined in *RFC-0003*. 158 | 159 | RFC Tree 160 | : An information structure that is used to aid the production and planning of **Time Machine Request for Comments** . Its authoritative version is kept up-to-date in *RFC-0002*. 161 | 162 | Scouting Projects 163 | : **Projects** that operate beyond the **Frontier year** 164 | 165 | Segmenters 166 | : **Operators** that can be used for segmenting objects and persons in images, parcels in Cadastral Maps, performing Document Layout analysis or 3D object segmentation. 167 | 168 | Service to Local Time Machines 169 | : Services offered to **Local Time Machines**, appearing as active **Apps** for some Local Time Machines and using **Standard Contracts**. Services typically appear in the **Local Time Machine WebSpace**. Examples include **Digitisation Hubs**, **Time Machine Box** and **Long-term preservation Service**. 170 | 171 | Spatio-temporal Anchoring 172 | : The objective of Time Machine is to localise cultural objects in space and time. For instance, an object in a museum can be associated with several spatio-temporal references: its place of production, the various places it was stored before entering the museum and the spatio-temporal entity it represents. One consequence of this is that a museum in Paris may contribute to many **Local Time Machines** in the world, having, for instance, paintings representing Venice, Madrid or Budapest. Inversely, in many cases, the information for reconstructing the past of a city or a site is scattered in collections all over the world. The granularity of such spatio-temporal repositioning can be more or less precise or more or less uncertain. To be ingested in the **Data Graph**, the museum will create a dedicated project whose goal is to produce the spatio-temporal anchoring of some of its collections in one way or another and to document the process by which this repositioning has been done. In many cases, this work has already been done by the curator or researchers in the museums and the goal is thus only to redocument this work in the Time Machine framework. In other cases, dedicated projects must be conducted. 173 | 174 | Sources 175 | : Entities that contain information that can be extracted (mined). It is typical to distinguish primary sources (e.g. archival records) from secondary sources (e.g. academic articles). 176 | 177 | Standard Contracts 178 | : Sets of standard contracts used to facilitate the interaction between Time Machine partners, for instance in the case of **Digitisation Hubs**. 179 | 180 | Standard Metrics 181 | : Metrics that help partners in the **Time Machine Network** to compare performance with one another and to set benchmarks. 182 | 183 | Technical Charter 184 | : A document that defines the Time Machines Rules, Recommendations, Metrics and Official software. The document is periodically revised. 185 | 186 | Time Machine API 187 | : An **API** that can be used by **Projects** to interact with the **Data Graph**. 188 | 189 | Time Machine Box 190 | : A collection of hard- and software that allows partners to store their documents and metadata in a decentralised way, to easily integrate them into the **Time Machine Network** and to ensure they are appropriately documented in the **Data Graph**. The Time Machine Box is one of the **Time Machine Official Components**. 191 | 192 | Time Machine CSA 193 | : A project with 33 partners supported by European Commission, taking place from 2019-2020, to produce a 10-year roadmap for Time Machine. All deliverables and roadmaps are available publicly[^csa_info]. 194 | 195 | Time Machine Community 196 | : All users registered in the **Time Machine Website**. Each user's Time Machine ID can be used to login to third parties **Apps**, and, depending on their level of activity, users may reach different status types linked with particular privileges in terms of operations. These statuses are defined and organised taking inspiration from the Wikipedia systems of privilege (e.g. Administrators, Stewards, etc.). 197 | 198 | Time Machine Index 199 | : A global system for indexing different types of objects: e.g. documents; iconography; 3D geometries. It gathers all information on documents and their contents and can be used as a basis for additional search engine infrastructure. 200 | 201 | Time Machine Infrastructure Alliance 202 | : The coalition of the Time Machine partners consisting of in-kind donators of infrastructure components (server space and computing power). 203 | 204 | Time Machine Horizon 205 | : The asymptotic objective of the Time Machine. 206 | 207 | Time Machine Mirror World 208 | : The **Time Machine Mirror World** is a digital twin of the real world, enabling 4D navigation. It is based an advanced stage of the **4D Map** associated with dedicated **Apps**. The **Time Machine Mirror World** results from the the processing of the Time Machine **Engines** producing a continuous representation model that can be accessed as an information stratum overlaying the real world. 209 | 210 | Time Machine Network 211 | : The **Time Machine Network** is the set of all the partners actually interacting in the Time Machine as part of **Projects**. 212 | 213 | Time Machine Official Components 214 | : Pieces of hard- and software (e.g. **Time Machine Box**) that help partners conform to and interact with the **Time Machine Tools** and **Time Machine API** to simplify interaction with the **Data Graph**. 215 | 216 | Time Machine Organisation 217 | : A non-profit Association under the Austrian Law responsible for Time Machine governance and operations. 218 | 219 | Time Machine Request for Comments 220 | : A set of documents as well as a process of development and feedback for the progressive design of the Time Machine infrastructure, standards, recommendations and rules, inspired by the process which has been used for 50 years for the development of Internet Technology, today administrated by the Internet Engineering Task Force (IETF) as part of Internet Society (ISOC). Their functioning is described in *RFC-0000* and related RFCs. 221 | 222 | Time Machine Tools 223 | : Data ingestion and curation services offered to **Projects** to enter their data in the **Data Graph** 224 | 225 | Time Machine Website 226 | : Main website of the Time Machine[^tm_website]". Includes the **Local Time Machine WebSpace** 227 | 228 | Transfer 229 | : Transfer of a structure of a given year to the year before assuming no change has occurred. Linked with the principle of continuity. If the transfer of a given structure is not impossible, it means that an event occurred. This event must be modelled in order to push the information backward. 230 | 231 | Universal Representation Engine 232 | : One of the Time Machine **Engines**. It manages a multidimensional representation of latent space resulting from the integration of the pattern of extremely diverse types of digital cultural artefacts (text, images, videos, 3D), and permitting new types of data generation based on transmodal pattern understanding. 233 | 234 | Zone of Coverage 235 | : The geo-spatial zone of activity of a **Project**. 236 | 237 | 238 | 239 | [^csa_info]: 240 | [^openstreetmap]: 241 | [^tm_website]: 242 | -------------------------------------------------------------------------------- /files/releases/RFC-0003/RFC-0003.md: -------------------------------------------------------------------------------- 1 | --- 2 | # Don't change this header section 3 | title: "RFC on RFC Platform" 4 | subtitle: "Time Machine RFC-0003" 5 | author: 6 | - Daniel Jeller 7 | - Juha Henriksson 8 | - Frédéric Kaplan 9 | - Kevin Baumer 10 | header-includes: 11 | - \usepackage{fancyhdr} 12 | - \pagestyle{fancy} 13 | - \fancyhead[R]{} 14 | - \fancyfoot[L]{-release-version-} 15 | output: pdf_document 16 | --- 17 | 18 | # Motivation 19 | 20 | This Request for Comments (RFC) describes the inner workings and technical 21 | details of the RFC platform itself. It aims to provide the technical framework 22 | for authorship, review, community contribution and publication of all future 23 | Time Machine RFCs. 24 | 25 | # Introduction 26 | 27 | The Time Machine **Requests for Comments** (RFC) workflow is based on 28 | Git[^git_website], a tool initially designed to track changes to source code by 29 | multiple developers and GitHub[^github_about], currently the leading place to 30 | host open-source projects and to create and collaborate on software and many 31 | other kinds of projects. The contribution and review process used by RFCs builds 32 | on the basic _forking_ workflow that "is most often seen in public open source 33 | projects"[^bitbucket_forking]. This ensures that contributions will be tracked 34 | indefinitely, review decisions are documented correctly and it is possible to 35 | permanently access and reference older versions of the RFC drafts. 36 | 37 | The choice of this solution is motivated by the possibility to scale the number 38 | of users and contributions over time. It is likely that releasing and updating 39 | RFCs will ultimately be akin to maintaining a large software codebase. 40 | 41 | # Definitions 42 | 43 | Before describing the workflow in detail, this section gives an overview on the 44 | most important design decisions and distinct parts of the platform. 45 | 46 | ## RFC Editor, RFC Editorial Committee and RFC Team 47 | 48 | All strategic and aspects of the RFCs are managed by the **RFC Editor and the 49 | RFC Editorial Committee** appointed by the Time Machine Organisation board, the 50 | technical management, editorial work and support for RFC authors and other 51 | contributors is done by the **RFC Team**. 52 | 53 | ## Authorship 54 | 55 | An RFC author can be an individual person or a group of authors working together 56 | on a single RFC draft. _Note_: This document doesn't differentiate between 57 | individual and groups of authors when talking about _RFC authors_. 58 | 59 | ## New RFC proposal 60 | 61 | RFCs can be proposed by the RFC Editor, the RFC Editorial Committee, RFC authors 62 | appointed by the Time Machine Organization or any other interested public 63 | author. An up-to-date list of planned RFCs and their interconnection can be seen 64 | in RFC-0002. 65 | 66 | ## Identifiers 67 | 68 | Any accepted RFC proposal will be assigned an identifier by the RFC Team. 69 | Identifiers are based on the pattern `RFC-[number]`. The numbers contain leading 70 | zeros to pad them to be four digits long. An example is this RFC itself, called 71 | `RFC-0003`, pronounced as _RFC-three_. 72 | 73 | ## Document format 74 | 75 | RFCs are drafted in markdown[^orig_markdown_syntax] -- more specifically, in the 76 | extended syntax used by Pandoc[^pandoc_markdown], a tool to convert texts 77 | between different file formats. 78 | 79 | _Note_: A short introduction into the most important features of markdown can be 80 | found in the \*RFC-template document[^template] 81 | 82 | ## RFC content and contribution repository 83 | 84 | RFC documents are managed in Git and are hosted in a single repository on 85 | GitHub. The individual RFCs stored in directories and files named after the RFC 86 | number, for example `RFC-0003/RFC-0003.md`. Accompanying files like images are 87 | stored alongside the main RFC documents. Public contributions will be possible 88 | via issues, comments and pull requests, the RFC Team is responsible for the 89 | immediate interaction with the community as well as the maintenance of the 90 | repository. 91 | 92 | Content contributions to an RFC currently being drafted can be made by creating 93 | a fork[^github_forking] of the official RFC repository and submitting all 94 | modifications in the form of a GitHub Pull-Request[^github_pullrequest] 95 | containing the relevant changes to the RFC repository. 96 | 97 | _Note_: An author-pull-request is only allowed to contain changes to a single 98 | RFC (main document and accompanying files), otherwise it will be rejected by the 99 | RFC Team. Changes to multiple RFCs need to be submitted in separate RFCs. 100 | Contributions outside an active drafting phase will also be rejected. 101 | 102 | ## Document life cycle 103 | 104 | The life cycle phases for an RFC are `draft` and `release`. Draft phases will be 105 | open to the public for an arbitrary amount of time during which the RFC is being 106 | prepared by the authors and open to comments by the public. Drafts are stored in 107 | the `files/drafts` folder, and released RFCs in the `files/releases/` folder of 108 | the RFC repository. 109 | 110 | ## Publication 111 | 112 | In addition to the markdown-documents in the RFC repository, drafts and releases 113 | will be converted into PDF files using the above-mentioned Pandoc. These PDF 114 | files will be amended with the time of conversion as well as a unique release 115 | number, then stored as build artifacts[^github_job_details] in the GitHub 116 | repository. 117 | 118 | After significant releases and following a loose half-yearly schedule, all 119 | drafts and releases will be published in a combined versioned and timestamped 120 | PDF document called the **RFC-book**. This PDF document is built automatically 121 | when a GitHub release[^github_release] is created and attached to the GitHub 122 | release page. 123 | 124 | _Note_: It is to be expected that the automatic file preview for markdown files 125 | on GitHub (and possibly in other tools as well) will differ from the final PDF 126 | files, as Pandoc, the tool used to create these files, enables advanced features 127 | like footnotes which are not necessarily used by GitHub and their preferred 128 | markdown dialect.[^gfm] 129 | 130 | # Workflow phases 131 | 132 | This section describes the progression of the RFC from an initial idea to its 133 | final release in the RFC book. 134 | 135 | ## Phase 1: Conception 136 | 137 | ![Conception flow](images/phase_1.png) 138 | 139 | Ideas for RFCs can come from the RFC Editor, the RFC Editorial Committee, or 140 | public authors, both as individual or groups of authors working together. 141 | Potential authors with an idea for an RFC should contact the RFC Editor to 142 | coordinate the initial conception and drafting process. After accepting an RFC 143 | idea, the RFC Editor will assign an identifier and the RFC Team will prepare the 144 | draft file from a standardised template in the official RFC repository in the 145 | `files/drafts/[RFC-id]/` folder. 146 | 147 | Following this step, the draft author can work on the document as they wish but 148 | once they feel the RFC is in a submittable state they will create a pull request 149 | with the draft text to the RFC repository or submit the text so the RFC Team can 150 | do so on their behalf. 151 | 152 | The RFC Team will then conduct a brief internal review of the initial draft to 153 | ensure the formal correctness of the document. After this is concluded and 154 | necessary changes are made by the initial draft author in the scope of the 155 | original submission, the pull request is merged in the master branch of the 156 | official repository and the public drafting phase will start. 157 | 158 | ## Phase 2: Public drafting and review 159 | 160 | ![Drafting flow](images/phase_2.png) 161 | 162 | The drafting of an RFC is designed as a process that enables direct 163 | contributions by public participants as well as the official RFC Editor, RFC 164 | Editorial Committee and Team in a similar manner. Over the course of a limited 165 | timespan all contributors can work on improvements of the draft text or propose 166 | and review changes. The fork-and-pull-request-workflow on GitHub makes sure that 167 | each contribution is registered and stored in the official repository 168 | indefinitely. 169 | 170 | The official drafting and review phase begins with the merging of the initial 171 | RFC draft by the RFC Team and extends over an arbitrary period of time depending 172 | on the topic and scope of the RFC being drafted. The main RFC markdown document 173 | as well as accompanying files, for example images, are stored in the 174 | `files/drafts/[RFC-id]` folder for the duration of the drafting phase. 175 | 176 | Persons interested in contributing to the text directly, either by additions or 177 | changes to the existing content, can create a new fork (a full copy) of the 178 | official repository or pull the current state of its master branch into their 179 | own pre-existing fork. They can then either: use the inline editor on the GitHub 180 | website to change the content of the RFC document in their own forked 181 | repository, or clone their repository to their computer and use a markdown 182 | editor / Git client of their choice to work with the files. 183 | 184 | Changes to the RFC draft can be submitted at any time during the drafting phase 185 | in the form of pull requests from the forked repository to the so-called 186 | upstream repository, that is the official RFC repository. This enables the RFC 187 | Editor, RFC Editorial Committee, RFC Team and other contributors to review the 188 | proposed changes, suggest editions or point out problems directly next to the 189 | provided version of the draft document. 190 | 191 | All pull requests to the official RFC repository during the drafting and review 192 | phase can be reviewed and commented by any contributor but to be accepted and to 193 | be merged the changes have to be accepted and to be merged the changes have to 194 | be accepted by the RFC Editor, RFC Team and Editorial Committee or reviewers 195 | appointed by the RFC Editor or the RFC Editorial Committee. After a pull request 196 | with changes passes this review, it is accepted and will be merged by the RFC 197 | Team into the master branch of the RFC repository. This makes the newly merged 198 | version the new official version of the draft. Other open pull requests will 199 | have to be updated by their creators to integrate the new changes into their 200 | version if conflicts occur. 201 | 202 | Merged pull requests will trigger a _GitHub Action_[^github_action] that 203 | compiles the current version of all open draft documents and attaches them as a 204 | ZIP file accessible in workflow job details[^github_job_details]. These preview 205 | files are available for 90 days. 206 | 207 | Another way for potential contributors not familiar with markdown writing and 208 | the Git-based workflow to contribute are so-called GitHub 209 | Issues[^github_issues]. These are commonly used to give users the possibility to 210 | report software bugs to project developers and to track tasks to be done. In the 211 | TM RFCs issues can be created by any person that wants to just report a problem 212 | with the current version of the draft or to discuss specific topics or ideas 213 | related to the RFC. New issues will be tagged by the RFC Team with the 214 | identifier of the RFC they are directed at. It is the responsibility of the RFC 215 | author to react to these issues and up to the RFC Team to moderate the issues as 216 | necessary. 217 | 218 | ## Phase 3: Release 219 | 220 | ![Release flow](images/phase_3.png) 221 | 222 | If an RFC draft is considered fit for release by the community, the RFC Editor, 223 | the RFC Editorial Committee and reviewers after the drafting and review phase, 224 | the draft file is updated to include all contributors and to conform to the 225 | other formalities and is then moved from the `files/drafts` folder to 226 | `files/releases` by the RFC Team. After merging this change into the master 227 | branch of the repository, a new GitHub release[^github_release] will be created 228 | by the RFC Team. This will trigger the creation of a new timestamped version of 229 | the RFC book which will be attached to the release. This marks the formal 230 | release of the newly finished RFC document. 231 | 232 | # Updates at a later point 233 | 234 | Due to the fact that the RFCs describe aspects of the Time Machine, additions, 235 | amendments or changes to existing RFCs may be necessary. If this is the case, 236 | the RFC Team will move the RFC file to be amended from the `files/releases` 237 | folder back to the `files/drafts` folder and a new drafting phase can start. It 238 | will then again process through all the different phases as described above 239 | resulting in a new release version. 240 | 241 | # Q&A 242 | 243 | ## Question: Do I need a GitHub account to contribute to an RFC? 244 | 245 | Yes, you will need a GitHub account if you would like to contribute directly to 246 | the text of an RFC, to discuss issues or to comment on pull requests. It serves 247 | to make attributions of content and comments from individual persons possible 248 | and to help to ensure scientific standards for the drafting and review process. 249 | 250 | ## Question: I have an idea for an RFC. What do I do? 251 | 252 | Please contact the RFC Editor at [rfc@timemachine.eu](mailto:rfc@timemachine.eu) 253 | with your idea. They will assist you with the creation an initial draft version 254 | of the idea, if it is deemed to be suitable and feasible. 255 | 256 | ## Question: I would like to fix some errors in an RFC draft. How do I do that? 257 | 258 | The easiest way is for you to sign in to your GitHub account, create a fork of 259 | the main RFC repository into your own account, fix the error in your forked 260 | version of the document, commit it into your repository and open a pull request 261 | outlining your changes to the main RFC repository. It will then be visible, can 262 | be reviewed and then eventually merged into the main draft document if the 263 | changes are accepted by the reviewers. If you need any help with this, feel 264 | free to contact the RFC Editor at 265 | [rfc@timemachine.eu](mailto:rfc@timemachine.eu). 266 | 267 | ## Question: I have worked on a draft document myself and would like to preview the final PDF document to see how it would look. How can I do this? 268 | 269 | If you follow the official contribution process by forking the main RFC 270 | repository, anything you push to the `master` branch in your own repository will 271 | be automatically converted into a PDF document by triggering a GitHub action. 272 | You can access the ZIP file with the compiled draft documents in the GitHub job 273 | details page in the action section once you have enabled[^github_enable_actions] 274 | the execution of actions in your repository. 275 | 276 | ## Question: How do I see which drafts are currently available for contributions? 277 | 278 | You can see the current plan of work in the _README_[^github_repo_rfc_readme] 279 | file of the main RFC repository. 280 | 281 | 282 | 283 | 284 | 285 | [^bitbucket_forking]: 286 | 287 | 288 | [^gfm]: GitHub Flavored markdown (_GFM_) 289 | [^git_website]: 290 | [^github_about]: 291 | [^github_action]: 292 | [^github_enable_actions]: 293 | 294 | 295 | [^github_forking]: 296 | [^github_issues]: 297 | [^github_job_details]: 298 | 299 | 300 | [^github_pullrequest]: 301 | 302 | 303 | [^github_release]: 304 | 305 | 306 | [^github_repo_rfc_readme]: 307 | 308 | 309 | [^orig_markdown_syntax]: 310 | [^pandoc_markdown]: 311 | [^template]: 312 | 313 | -------------------------------------------------------------------------------- /files/releases/RFC-0003/images/phase_1.drawio: -------------------------------------------------------------------------------- 1 | 7Vpbc5s6EP41fmyGi43tR9dx0jPTzsk0nd7eVLMGnQpEJeHL+fWVQOIaJ8SNY+rxZMaB1QLSfvt9KwkG7jza3jKUhB+oD2TgWP524F4PHMe2LUf+U5ZdbpmMxrkhYNjXTqXhHv8P2mhpa4p94DVHQSkROKkblzSOYSlqNsQY3dTdVpTUn5qgAFqG+yUibesX7IvQjMIq7e8AB6EoBqxbImSctYGHyKebisldDNw5o1TkR9F2DkQFz8Qlv+5mT2vRMQax6HJBZH+aM+t2hrwF/fwv4t8Xd+zNVPdN7MyAwZfj16eUiZAGNEZkUVrfMprGPqi7WvKs9HlPaSKNtjT+B0LsNJgoFVSaQhER3RrTyu0yS3kTbVhhQuaUUJZ1ygXbH8FY2rlg9CdUWqbe2EVe0WIwctQ9aCwqntZI/Ul7O3A6lpymbAmPREvnskAsAPGI3yT3U6GsPEDDcgs0AsF20oEBQQKv66mGdMYGhV8JqjzQuD4DY93rNSKpftLHG3kn6x8fUAv+ElwFwybEAu4TlEVlIxleB/IlUNqLxhqYgO2j8TOthmJaY5zp1XQ6sZ1Rbt2UvC08wwpnPetIgR9eyPUMcrkdyeX0ilxui1yzVIabtaBPKI4FsMVaBoZrIIqSoLD2EQ8L4CuA7kdlH44E/QByRzkWmMaybQnqybJBUQrL2va+4fCDCkGjisOM4EA1CJV0b2kqCI5lF0yJVT1E2qW4uRxMosYabQM1FbiiqxVewlXKgfHs91j0H9bZ7w73sX/otck/Ohb57Qv7n8P+UUf2m3lhT+g/2lNbFz4WFxF4QAT4K6mA7Z2a/5Oe8r9Isf6KweTvFINipfeqkMvost1XfX128k2dXI3M6fW22ni9a0rNyfLgaXynL42vvvRO6XBVO+ri0VwR5AmrL2okSdGLw/Nm0ioi15gvU85xHGTXqnWaFDIZaRm0EORvXmU+AYpaKWckWCo4kaL99CouAYblEJR+m4vuStMBpeco+u5MGtM8q9vqbnI0gR/1VOAPFYR+1gKj8U+vC4evIxZeY7fBthsZlvf0aGphHvfQfk4s8ApL1qrOcDk1i0D34eAtnp6y3/Y60v9omzuO+zcV+55ye9qV2/3a9DH9rlDwhrKfebnOC3S28MGIZH1K6FmQcNjcaTk5B70LB//4nUbXlxpmQ60nHDT9rnDwS8FBGhdE9BlaqeqNSxPdxOdES8/qGy1PsvVx+vXs01wbduXauFdcc0881yml9Vu1bY/OchleMVPv/qUhpjEY2w1Ww9Y+XdF+fibVEvEVkuXld0n+jP3DljAPHI+ojQgfr+VhILK45CaeoLiWWd6vVH0RkeHxZoUiTCSus4ESMA9FSoG1QwhkDWqjutlQ3sM8bOb71bmZKQkSWnUq866+rZK180H+tUi2mqoWj+bELh+HDFU+lPrwpLk26DMoN81ZYA+WYif5iqWnJabri7S+lZj2rsZlEnFWCDvtd6VzBkgoUU1SkgvqrxS4qGvyOa6kx17PpuzuSdh26Eq6ywyvp+QddySva/eLvOMWeT/CGsOmOq9qsvgMiXr6yY5JjAoSH4AFD81vW6r62DT2DMCaNt/MHBEseVp+up2/2ik/gHcXvwE= -------------------------------------------------------------------------------- /files/releases/RFC-0003/images/phase_1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/time-machine-project/requests-for-comments/46f660f7b259c2c4a3ed4e79d9ccfc06f150f0f8/files/releases/RFC-0003/images/phase_1.png -------------------------------------------------------------------------------- /files/releases/RFC-0003/images/phase_2.drawio: -------------------------------------------------------------------------------- 1 | 7VtZc6M4EP41ftwUt53HxHGyWzWpTSU1NcfLlgwNaAOIFcLH/vqVQFxWnCWHA/bkIQ5qNUJ099eX7Ik5jzc3FKXhLfEgmhiat5mYVxPD0HXN4P8EZVtSZva0JAQUe5KpITzgf0ESNUnNsQdZh5EREjGcdokuSRJwWYeGKCXrLptPou5TUxSAQnhwUaRSv2GPhdVbaA39d8BByOoXljMxqpglIQuRR9YtkrmYmHNKCCuv4s0cIiG8Si7lfdd7ZuuNUUhYnxtmX30UfH8kGfy5tO9/rm7Y1v3NdOTm2LZ6Y/C4AOSQUBaSgCQoWjTUS0ryxAOxrMZHDc8XQlJO1Dnxb2BsK7WJckY4KWRxJGczRsljLU8uiUsfR9GcRIQWezBB92yY1pytmXNnaiKHz6ivLyWSkZy68Mw7V2aEaADsGT5puUIerQdI4d4AiYHRLWegECGGV12DQdLugpqvUQ2/kNp5gabkuisU5fJJd/kywm5p+4ziJRczVbSZEpwwoIsVF1NWib+yRKE+D2VhrUtFR09Jfp+uIrSE6I5kmGGS8DkXxJP5xAoowxxSX3YYloQxErcYLiIciAkm7OiS5CzCCd9ChWyxQyRZ6sX5y6TiXeNNIDzQGfF97MJZngHNis+/+N+Kk7InDW+vGYk9weZZxctZQ3o06eEsifd14y7s85IUtjxFRXt3QzkfAtFcenT7Xd5fDH6IwZldDa827cmrrRwN6wmMnp7AGpUnMBRP8IcHqAiM4tY4pYRvgQ9D8YlcliOx5v31XMRhinwmfYaQ166tNJYg1LoOMYOHFBVSXHN8dbX+cl0dBIB6FWL3I7BmaUPQ0Q7lq3VFricfVa2eWKoSu5GAyVLAdE3oI06CGkBuTgtpFBaZichlaMSvpytA+ZSHsopYBCHcgh2FVMQ9Inf8asQdVMcvCHmzkSFuNmzQa+Lcj/Zc76BXJ2Gv86qvR619lBFQH6Rqeb8cZ/Tq1selb1tx0reIlzX8r3TUv5q71Z2h/e3010twnJ7YsUcFHUeBTomQhYc/2wVPtQs+qk2gO7aCYctRIWwfrEgxjzuIfmjLUOsbOEfWNNQU+H+ry5uikukWMR5x87gsdnAzS9bJ6cVUyxpZCWMYY6phtHHjsW/nbmSJbLXvFh7nFPiDC0CKHl6aF6tQ+CeHjBX2yCW8i1M3REkA2UkA0dHGBsTPDnp/IPZt+xmzUQHRGsbZbjArfe3UlsPa1/LrRsNisG2ru7zLeGObaZyWoY/KMnS1I3wPKwzr0keLxcXpSSzSJCWP2vXeJ+ieh+89WMMULjV2jVdh94iyq/qLNkdW7dTG3UD3a+pV2ZWSWS1Rxg1C4tcH8JbIfRT7SgQVNgxoUvQUq6wrF4udSNY1dbqwNs+HzrpmivJugQbtkzhFgzgpjrzL2RhlosXD9UpR4oqcuXVK1+oQn1gdu6vI4f2zaX3mz31drdm3sWSOy9WaA9dIbz1wHaWO379ZUdx6QSnathiKHn/WWvlOEBqPsvt1GlPf+WLp//E7z/M7u6Gny88vyh031lm/+hsMVu2EXuTcAD+PQLpHIKKyyRO+tHjiR52FGDNdiVm2pYYse3YodzbwWchRubO+vddxHYRW297Tei1yfrWsx1mWi4y/3GRRLrRSzuIo9QRyyN3vF9TjA+SQfNj85qH07s0vR8zFfw== -------------------------------------------------------------------------------- /files/releases/RFC-0003/images/phase_2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/time-machine-project/requests-for-comments/46f660f7b259c2c4a3ed4e79d9ccfc06f150f0f8/files/releases/RFC-0003/images/phase_2.png -------------------------------------------------------------------------------- /files/releases/RFC-0003/images/phase_3.drawio: -------------------------------------------------------------------------------- 1 | 7VhLc9owEP41HJPxAww5EkrIIZ3JNIceM8JebDWy15XWPPrrKyH5QZww6YGENj2A7W8/W9rHp7U8CGf5diFZmX3FBMQg8JLtIPwyCALf9wJ9MMjOIpPR2AKp5IkjtcAD/wUO9Bxa8QTUAZEQBfHyEIyxKCCmA4xJiZtD2grF4aglS6EHPMRM9NHvPKGs9sJr8VvgaUaNw86Ss5rsAJWxBDcdKJwPwplEJHuWb2cgTPDquNj7bl6xNhOTUNBbbthOx95VNh3CT7WSF5Mymi7FxcjNjXa1w5Bo/90lSsowxYKJeYteS6yKBMxTPX3Vcu4QSw36GvwBRDuXTFYRaiijXDjrigsxQ4FyP2IIfjKCscYVSXyCjuUqGocsaix1AnTorvveu4AorGQMR1yuq4jJFOgIL7Q8E4/OAC62C8AcSO40QYJgxNeH9cJc2aUNr82MPnHJ+YNEueeumajcSPcStPu8SO0cgCkwOsO4yk1M9ByKxNQhri3n281sL56WrpwgQPaqoM2xSdgm4wQPJdvHdaOF/o75XIMk2B7NQG2tleaWmqG73LS6bShZR7ORd6KcDT+fuII3iss/K3EFPXFZscwTTtgXR4m8IJDztQ6PcmFvVneTtoSprMlhJzev5+C1rAm2BHGPihPHQttiMCNrg5EF123q7hlhiUSYdwhTwVNjIFM/11iR4IWeQt0tzQyZozQP186Uxtd8m5qufomrFY/hslIglf0/lYaHzyQ86kl4GPUVPDqVgv0P6Y9N+Xy8nsM36nl8VnoOe3qeSdDj7vsg078Fp9tq2W2c/0D/CyZn1v8mn1w80V8pnqgnnlot/9vgvg3q/rfWR3VpiJKJx5wVehto3rofne2d2qMfhT2Jj/wX+uPwRLUyPrbQUmY2JAVsrIvKZCbwcNWY7EvWEvGp2a0wIhZn9n5O9X7F0j/Fou1Hp1u19WX7uWFv63y0Cee/AQ== -------------------------------------------------------------------------------- /files/releases/RFC-0003/images/phase_3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/time-machine-project/requests-for-comments/46f660f7b259c2c4a3ed4e79d9ccfc06f150f0f8/files/releases/RFC-0003/images/phase_3.png -------------------------------------------------------------------------------- /files/releases/RFC-0004/RFC-0004.md: -------------------------------------------------------------------------------- 1 | --- 2 | # Don't change this header section 3 | title: "RFC on the RFC Editor and the RFC Editorial Committee" 4 | subtitle: "Time Machine RFC-0004" 5 | author: 6 | - Andreas Maier 7 | - Juha Henriksson 8 | - Daniel Jeller 9 | header-includes: 10 | - \usepackage{fancyhdr} 11 | - \pagestyle{fancy} 12 | - \fancyfoot[L]{-release-version-} 13 | output: pdf_document 14 | --- 15 | 16 | # Motivation 17 | 18 | This RFC defines the duties of the RFC Editor. It also outlines the basic 19 | policies and procedures related to the RFC Editorial Committee, many of which 20 | have been inspired by the IEEE Signal Processing Society [^ieee_sps_policy]. 21 | 22 | # The RFC Editor 23 | 24 | The Time Machine RFC Editor is appointed by the Time Machine Organisation’s Board. 25 | 26 | ## Main Duties 27 | 28 | - The RFC Editor recruits writers for RFC’s and guides the writing process of 29 | RFC’s 30 | - The RFC Editor maintains the consistency of the RFC System, appoints RFC teams 31 | to organise new RFCs and to improve upon existing RFCs. 32 | - In particular, the RFC Editor reviews changes to the GitHub version of the 33 | RFCs and comments on their technical soundness. 34 | - The RFC Editor is responsible for keeping track of RFC versioning, the timely 35 | and regular publication of RFCs, and publicly announcing new releases. 36 | - The RFC Editor helps to build and manage the RFC Editorial Committee 37 | - The RFC Editor also assists in organizing and running RFC-related workshops 38 | and other events 39 | 40 | # RFC Editorial Committee 41 | 42 | ## Organisation 43 | 44 | The RFC Editorial Committee consists of four members. The four members share 45 | equal rights and duties with regards to the editing process of the time machine 46 | RFCs. For decisions of the RFC Committee to be passed, a majority of more than 47 | 60% is required, in practice meaning three of the four members must agree on a 48 | decision. 49 | 50 | ## Appointment 51 | 52 | Vacancies in the RFC Editorial Committee are communicated to the general public 53 | by the Time Machine Organisation (TMO), and anybody is welcome to apply for a 54 | position in the Committee. After a period of 14 days following the public 55 | announcement, the TMO's Board reviews all applications and determines if the new 56 | member of the RFC Committee is approved by a majority vote. In the case of 57 | multiple applications that result in affirmative votes totalling less than 50% 58 | of the voting members' support, the top two candidates move on to a second 59 | ballot. The TMO Board may also remove RFC Editorial Committee Members with or 60 | without cause by affirmative vote of 66% of the voting members. 61 | 62 | ## Application Procedures 63 | 64 | In order to apply to a vacancy in the RFC Editorial Committee, applicants must 65 | submit their application in response to the public call initiated by the TMO 66 | Board. An application should consist of a letter of motivation, a curriculum 67 | vitae, and a list of publications which will serve to provide the TMO Board with 68 | a breadth and depth of information needed to make an appropriate decision. 69 | 70 | ## Length of Terms 71 | 72 | An RFC Editorial Committee Member is appointed for a period of three years. The 73 | post may be vacated earlier, should the RFC Editorial Committee Member wish to 74 | do so. The appointment may also be terminated by the TMO Board. At the end of 75 | their first term, members are permitted to run for a second term. In exceptional 76 | cases, the TMO Board may allow additional terms. 77 | 78 | 79 | 80 | [^ieee_sps_policy]: 81 | 82 | -------------------------------------------------------------------------------- /files/releases/RFC-0005/LTM_Map1.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/time-machine-project/requests-for-comments/46f660f7b259c2c4a3ed4e79d9ccfc06f150f0f8/files/releases/RFC-0005/LTM_Map1.jpg -------------------------------------------------------------------------------- /files/releases/RFC-0005/LTM_Map2.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/time-machine-project/requests-for-comments/46f660f7b259c2c4a3ed4e79d9ccfc06f150f0f8/files/releases/RFC-0005/LTM_Map2.jpg -------------------------------------------------------------------------------- /files/releases/RFC-0005/LTM_Project.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/time-machine-project/requests-for-comments/46f660f7b259c2c4a3ed4e79d9ccfc06f150f0f8/files/releases/RFC-0005/LTM_Project.jpg -------------------------------------------------------------------------------- /files/releases/RFC-0005/LTM_Project_Data.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/time-machine-project/requests-for-comments/46f660f7b259c2c4a3ed4e79d9ccfc06f150f0f8/files/releases/RFC-0005/LTM_Project_Data.jpg -------------------------------------------------------------------------------- /files/releases/RFC-0005/LTM_Project_Description.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/time-machine-project/requests-for-comments/46f660f7b259c2c4a3ed4e79d9ccfc06f150f0f8/files/releases/RFC-0005/LTM_Project_Description.jpg -------------------------------------------------------------------------------- /files/releases/RFC-0005/LTM_Project_Description_Institution.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/time-machine-project/requests-for-comments/46f660f7b259c2c4a3ed4e79d9ccfc06f150f0f8/files/releases/RFC-0005/LTM_Project_Description_Institution.jpg -------------------------------------------------------------------------------- /files/releases/RFC-0005/LTM_Project_Geographic_AddLocation.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/time-machine-project/requests-for-comments/46f660f7b259c2c4a3ed4e79d9ccfc06f150f0f8/files/releases/RFC-0005/LTM_Project_Geographic_AddLocation.jpg -------------------------------------------------------------------------------- /files/releases/RFC-0005/LTM_Project_Geographic_LocationList.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/time-machine-project/requests-for-comments/46f660f7b259c2c4a3ed4e79d9ccfc06f150f0f8/files/releases/RFC-0005/LTM_Project_Geographic_LocationList.jpg -------------------------------------------------------------------------------- /files/releases/RFC-0005/LTM_Project_Geographic_ZoneofCoverage.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/time-machine-project/requests-for-comments/46f660f7b259c2c4a3ed4e79d9ccfc06f150f0f8/files/releases/RFC-0005/LTM_Project_Geographic_ZoneofCoverage.jpg -------------------------------------------------------------------------------- /files/releases/RFC-0005/LTM_Project_Name_and_Period.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/time-machine-project/requests-for-comments/46f660f7b259c2c4a3ed4e79d9ccfc06f150f0f8/files/releases/RFC-0005/LTM_Project_Name_and_Period.jpg -------------------------------------------------------------------------------- /files/releases/RFC-0005/LTM_Project_Review.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/time-machine-project/requests-for-comments/46f660f7b259c2c4a3ed4e79d9ccfc06f150f0f8/files/releases/RFC-0005/LTM_Project_Review.jpg -------------------------------------------------------------------------------- /files/releases/RFC-0005/LTM_Schema.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/time-machine-project/requests-for-comments/46f660f7b259c2c4a3ed4e79d9ccfc06f150f0f8/files/releases/RFC-0005/LTM_Schema.jpg -------------------------------------------------------------------------------- /files/releases/RFC-0005/LTM_Webspace.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/time-machine-project/requests-for-comments/46f660f7b259c2c4a3ed4e79d9ccfc06f150f0f8/files/releases/RFC-0005/LTM_Webspace.jpg -------------------------------------------------------------------------------- /files/releases/RFC-0005/RFC-0005.md: -------------------------------------------------------------------------------- 1 | --- 2 | # Don't change this header section 3 | title: "RFC on LTM" 4 | subtitle: "Time Machine RFC-0005" 5 | author: 6 | - Isabella di Lenardo 7 | - François Ballaud 8 | - Gael Paccard 9 | - Frederic Kaplan 10 | - Daniel Jeller 11 | header-includes: 12 | - \usepackage{fancyhdr} 13 | - \pagestyle{fancy} 14 | - \fancyfoot[L]{-release-version-} 15 | output: pdf_document 16 | --- 17 | 18 | # Motivation 19 | 20 | In order to build a planetary scale Time Machine, it is necessary to define an 21 | organic incremental strategy. To succeed, the Time Machine must enable to 22 | progressively anchor itself in local territories, directly bringing locally 23 | higher value to the activities, favouring the creation of new projects to mine 24 | information about the past in surviving objects and documents. Local Time 25 | Machines can be defined as zones of higher density of activities of past 26 | reconstruction. This RFC defines the dynamics that permit to bootstrap Local 27 | Time Machines, facilitate onboarding of new projects, valorise the data 28 | extracted, facilitate the involvement of the local population, develop use cases 29 | for exploitation avenues and eventually find sustainable regime where **Big Data 30 | of the Past** are fruitfully exploited leading to a constant increase of such 31 | activities. This RFC defines an approach based on the standardisation of a core 32 | infrastructure and independent development of Apps. 33 | 34 | # Approach 35 | 36 | ## Openness By Design: Autonomy of Projects, Emergence of Local Time Machines 37 | 38 | The first principle for the development of Local Time Machine is 39 | **Openness-by-design**. The general idea is that **Local Time Machines** do not 40 | have a hierarchical structure managed by a coordinator or leader, but represent 41 | an aggregation of different projects, which arose in different contexts and 42 | which have their own independent structure and governance, specific purposes, 43 | development context and method of financing. Consequently, **Local Time 44 | Machines** are areas characterised by **Density of Operations**. There is no 45 | single coordination that aims to manage all the **Projects** that have arisen in 46 | a specific area. All those involved in the various projects and activities, 47 | through their organisation charts, can in any case converge towards a community 48 | which will therefore have an autonomous logic of structuring and functioning 49 | that emerges locally. The projects involved can include projects with national 50 | and international grants, institutional projects having internal funding, 51 | projects financed by local administrative institutions, projects hold by 52 | companies on cultural heritage benefiting of services and tools implemented by 53 | the **Time Machine Organisation** through the **Local Time Machines 54 | Infrastructure**, but also small-scale projects led by individuals. 55 | 56 | The project-based horizontal structure has key advantages. 57 | 58 | - Standard processes facilitate easy on-boarding of new projects and 59 | members.They ensure openness by-design 60 | - Standard operations and libraries of standard operators guaranty by design the 61 | desired level of compatibility between processes and datasets. 62 | - Centralised repositories for projects, operations and data sets enable a 63 | constantly up-to-date map of activities in progress. 64 | 65 | ## Scalability by Design: Core Component, Apps, Code Library and Local Time Machines 66 | 67 | The second development principle of the Local Time Machine is scalability by 68 | design. To maximise growth of the Time Machine environment, the right balance 69 | must be found between part of the infrastructure under the control of the **Time 70 | Machine Organisation** and pieces of software independently developed. The Time 71 | Machine should be as distributed as possible but as centralized as necessary. 72 | 73 | In the structure defined in this RFC, the **Time Machine Organisation** is 74 | responsible for the development of the **Core Infrastructure** which includes. 75 | 76 | - The definition of the structure of the **Data Graph** and the creation of the 77 | interfaces to read and write it. 78 | - The curation of the **4D Map** including both the activities of the projects 79 | and the results of the reconstructions. 80 | - The curation of the **Project repository**, list of officially recognised 81 | projects transforming the **Data Graph** and **4D Map** and building Tools to 82 | read it and write it. 83 | - The curation of the **Code Library** regrouping key functions for processing 84 | Data in the Time Machine Environment. 85 | 86 | The **Apps** are pieces of software (in general built as part of official 87 | **Projects** but not necessarily) that permits to experience and edit the 88 | information in the **Data Graph** and the **4D Map**. They can be grouped into 89 | families of **Apps** like the **Navigators** or the **Annotators**. 90 | 91 | In this context, Local Time Machines defined as zones of higher density of 92 | activities, correspond to part of the **Data Graph** and **4D Maps** where 93 | **Project** activities are more intense. The level of intensity corresponding to 94 | the different labelling (**RFC on LTM Value Scale**, planned 2020) and 95 | corresponds to different modes of visualisation in the **Time Machine Website** 96 | 97 | This principle of development permits a cost-effective strategy in which a 98 | variety of actors can be build tools and services around the activities of 99 | **Local Time Machines** 100 | 101 | ## Project Zone of Coverage and Local Time Machine Municipalities 102 | 103 | **Local Time Machines** focus on **Municipalities**, i.e. zone of territories 104 | dividing the surface of earth on administratively non-ambiguous zones. The list 105 | of **Municipalities** (and therefore the list of the potential Local Time 106 | Machines) is fixed and predetermined. This determines a priori the granularity 107 | of the **Local Time Machines**. 108 | 109 | **Projects** focus on a **Zone of Coverage** corresponding to one of several 110 | **GeoEntities**. The list of based on existing geographical entities (e.g. a 111 | list of Places documents in Open Street Map (OSM)) defines as standard 112 | Geographical Information System objects (points - lines - polygons). Some 113 | **GeoEntities** can include **Municipalities** or be included in 114 | **Municipalities**. In both cases, the **Project** will be featured in the 115 | corresponding **Local Time Machines**. 116 | 117 | # Core Components related to Local Time Machines 118 | 119 | ![70 % center](LTM_Schema.jpg) 120 | 121 | ## Data Graph 122 | 123 | The **Data Graph** is the central component of the Time Machine, containing all 124 | the information modelled in the Time Machine. The graph is constructed both 125 | manually using editing **Apps** and automatically through the processing of the 126 | **Digital Content Processor** (3 RFCs planned in 2021). The **Data Graph** is 127 | intrinsically composed of two subparts. 128 | 129 | - The bright (actual) graph composed of information that has been manually 130 | mapped and integrated with other large database 131 | - The dark (virtual) graph composed of information extracted automatically from 132 | (massive) documentation which has been used so far apart as individual 133 | historic items. 134 | 135 | **Apps** permit visualise and edit the **Data Graph**, thus performing Internal 136 | (e.g. inclusion of Nodes and Links) and External Operations (e.g. 137 | Visualisation). As any **Component** of the Time Machine, the **Data Graph** is 138 | fully constructed in a procedural way, entirely defined by a sequence of 139 | operations. 140 | 141 | The first definition of the Data Graph is established by the **RFC on Time 142 | Machine Data Graph** (planned 2021, RFC2) 143 | 144 | ## 4D Map 145 | 146 | The **4D Map** is a second central component of Time Machine. It plots both 147 | ongoing projects and the dataset of these projects. This means that the **4D 148 | Map** is both the map where activities can be followed and the map aggregating 149 | results. The density of the **4D Map** is not uniformed. In particular some 150 | zones may be modelled only in 3D, 2D and even 1D, as a list of included 151 | elements. The **4D Map** includes a layer of **Municipalities** on which **Local 152 | Time Machines** can be anchored. The **4D Map** can be navigated using the 153 | several **4D interfaces** 154 | 155 | The Time Machine Website and **App** can perform specific internal operations 156 | like : 157 | 158 | - Addition of a new Local Time Machine on a **Municipality** of the **4D Map**. 159 | - Registration of an **Event** on the **4D Map** 160 | 161 | **Apps** can also feature 4D interfaces, application-based or web-based, that 162 | permit to perform external operations like : 163 | 164 | - Navigate in Space and see activities of **Local Time Machines** 165 | - Navigate in Space and Time to see the State of the 4D reconstruction 166 | 167 | The **4D Map** has a series of standard Layers that are fully defined in a 168 | dedicated RFC (**Not currently planned in RFC2**) 169 | 170 | 1. The **Municipalities** segmentation that defines the granularity of the 171 | **Local Time Machines** 172 | 2. The **Points of View** Layer that corresponds to the perspectives of 173 | photographs or paintings. 174 | 3. The **Parcel Layer** : 2D polygon with temporal extension typically defined 175 | by an administrative source (e.g. Parcels of the Napoleonic Cadaster of 176 | 1808). Each parcel has a unique ID in the Time Machine system. 177 | 4. The **Place names** Layer 178 | 5. The **Spherical Image** Layer 179 | 6. The **Cloud Point** Layer 180 | 7. The **4D Vectorial** Layer 181 | 8. The **Homologous Point Network**, connecting images with one another through 182 | homologous point 183 | 184 | In the meantime, a simplified version of the **4D Map** is used : The **Local 185 | Time Machines Map** 186 | 187 | ## Code Library 188 | 189 | The **Code Library** is a library accessible in Python (and possibly later other 190 | languages) regrouping key **Operators** function for processing Data in the Time 191 | Machine Environment. 192 | 193 | ## Projects Repository 194 | 195 | The **Projects Repository** monitors all the active projects of the Time 196 | Machine. **Projects** are usually conducted by institutions but can also be 197 | launched by individuals. Projects may be new or documentation of ancient 198 | projects. 199 | 200 | - Projects can mine **Sources** and ingest their extracted data into the **Data 201 | Graph**. These **Projects** are associated with a **Zone of Coverage** that 202 | associated them with **Local Time Machines**, producing content for 203 | **GeoEntities**. Projects may also produce intermediary datasets that can be 204 | downloaded even if they are not yet integrated in the **Data Graph** 205 | - Projects can also develop **Apps** that interact with the **4D Map** and the 206 | **Data Graph**. 207 | - Projects can contribute to the **Code Library** by working on the GitHub 208 | repository of the Time Machine to produce new **Operators** 209 | 210 | These different objectives are non-exclusive from one another. 211 | 212 | The **Project Development Space** is a space in the Time Machine Website that 213 | features the **Apps** relevant to develop the **Projects**. 214 | 215 | ## Time Machine Community 216 | 217 | The Time Machine Community is constituted of all users registered in the Time 218 | Machine Website. Each user will get an ID that can be used to login in third 219 | parties **Apps**. Depending on their level of activity, users may reach 220 | different status linked with particular privileges in terms of operations. These 221 | statuses are organised taking inspiration from the Wikipedia systems of 222 | privileges. 223 | 224 | # Characteristics of Local Time Machines 225 | 226 | A **Local Time Machine** is defined as the activities and results of the 227 | **Projects** concerning a **Municipality** 228 | 229 | - The **Local Time Webspace** features the information of all the **Projects** 230 | linked with the **Municipality** corresponding to the **Local Time Machine** 231 | - The **Local Time Machine Visual Plan** is an automatically generated 232 | representation of a spatiotemporal focus of the different projects 233 | participating to a **Local Time Machine** 234 | - The **Local Time Machine Datasets** are extracted datasets that can be freely 235 | downloaded, even if they are not yet integrated with the global **Data Graph** 236 | - The **Local Time Machine Operations** are the list of basic operations 237 | produced by **Projects** and concerning the **Municipality**. They appear as a 238 | log of activities in the **Local Time Machines Webspace**. The **Local Time 239 | Machine Density of Operations** characterises the number of activities going 240 | on in the **Local Time Machine**. It characterises both the activities that 241 | are going on inside **Projects** and for Citizen Scientist activities. 242 | Standards values of activities define a scale to represent Local Time Machine 243 | (**RFC on LTM Value Scale**, planned 2020) 244 | - The **Local Time Machine Community** is the list of active users of a **Local 245 | Time Machine** . These include users active in **Projects** and users active 246 | in crowdsourcing activities (e.g. transcription, correction, training, etc.). 247 | By default, the active users may get updated about announcement concerning 248 | **Local Time Machine Activities** 249 | 250 | # First Phases of Development 251 | 252 | ## Phase I : Development of the Project Environment and LTM Webspace 253 | 254 | The first release develops the following components, essentially meant for 255 | introducing the basic structure of the LTM infrastructure functioning. At this 256 | stage, the LTM Webspace essentially consists in the documentation of the 257 | existing. 258 | 259 | ### Local Time Machines Map 260 | 261 | A first interface to visualise and navigate in a simplified version of **4D 262 | Map** as a 2D visualisation. The first planetary-scale representation could be 263 | done using Open Street Map data. Each city which corresponds to a **Local Time 264 | Machine** (i.e. each city which has a **Project** actively working on it) would 265 | be highlighted. By clicking of corresponding city, the user access the **Local 266 | Time Machine WebSpace**. The interface should give access to the General Menu 267 | permitting to create a new project. 268 | 269 | Various versions of the **Local Time Machines Map** could be envisioned. The 270 | following schemas are illustrating various possible visualisations. The 271 | interface could be quite different in practice. 272 | 273 | Version 1 : A zoom features permits to focus on the most active **Local Time 274 | Machines** 275 | 276 | ![75 % center](LTM_Map1.jpg) 277 | 278 | Version 2 : Simple dots are showing the Local Time Machines on the map. 279 | 280 | ![75 % center](LTM_Map2.jpg) 281 | 282 | ### Local Time Machine Webspace 283 | 284 | The Local Time Machine Webspace features all the information available about a 285 | given Local Time Machine 286 | 287 | 1. The **Projects** covering the corresponding **GeoEntity** 288 | 2. The **Local Time Machine Visual Plan**, a synthetic summary of the activity 289 | of the **Projects** 290 | 3. The **Local Time Machine Agenda** of past and forthcoming Events 291 | 4. The combined log of the operations of the **Projects** 292 | 5. The **Local Time Machine Partners**, i.e list of institutions participating 293 | in at least one projects linked with the **Local Time Machine** 294 | 295 | Wireframes of Local Time Machine Webspace including **Local Time Machine Visual 296 | Plan**, **Local Time Machine Datasets**, **Projects** associated with the 297 | **Local Time Machine**, the **Local Time Machine Agenda**, the news section 298 | covering the combined log of the **Projects** and the **Local Time Machine 299 | Partners**. 300 | 301 | ![50 % center](LTM_Webspace.jpg) 302 | 303 | ### Project Environment 304 | 305 | The **Project Environment** includes basic tools for performing Internal 306 | Operations on **Projects** 307 | 308 | 1. Updating the Project Name and basic description 309 | 2. Updating the List of institutions involved 310 | 3. Updating the list **Municipalities** on which the **Project** operates (the 311 | first version of this list is automatically generated by the selection on the 312 | **Local Time Machines Map** using the **Zone of Coverage** ) 313 | 4. Updating of Project Spatiotemporal Data Focus. This information will be used 314 | for positioning the project in the **Local Time Machine Visual Plan** 315 | 5. Announcing activities to be displayed in the corresponding Local Time Machine 316 | Agendas. 317 | 318 | Each of the project operations, i.e. the project history, can be seen and edited 319 | in the Project log. Projects operations include : Publication of Datasets, 320 | Scientific Publications, Press Article, Addition of new Partner, etc. 321 | 322 | Wireframes of Project Page including link with external pages, datasets, contact 323 | person. related events, related news and associated institutions 324 | 325 | ![50 % center](LTM_Project.jpg) 326 | 327 | When a new project is created, the user follows in a script to enter all the 328 | necessary information. 329 | 330 | In the first Phase, the **Project Environment** will only enable the creation of 331 | projects whose primary goal is mining data from sources. The on-boarding process 332 | includes the following 5 steps : Name and Period, Geographic Coverage, 333 | Description, Public Data and Review/Publish 334 | 335 | Step 1: Entering Project Name and Period : 336 | 337 | ![50 % center](LTM_Project_Name_and_Period.jpg) 338 | 339 | Step 2: Adding a Location from the list of **GeoEntities** . The **Zone of 340 | Coverage** of the **GeoEntity** may correspond directly to a **Municipality**, 341 | may include **Municipalities** or may be a sub-part of a **Municipality**. 342 | 343 | ![50 % center](LTM_Project_Geographic_AddLocation.jpg) 344 | 345 | Step 2: Alternatively, one can draw a **Zone of Coverage** to select a list of 346 | **Municipalities** : 347 | 348 | ![50 % center](LTM_Project_Geographic_ZoneofCoverage.jpg) 349 | 350 | Step 2: Editing the list of **Municipalities** associated with the **Project** 351 | 352 | ![50 % center](LTM_Project_Geographic_LocationList.jpg) 353 | 354 | Step 3 : Entering Description : 355 | 356 | ![50 % center](LTM_Project_Description.jpg) 357 | 358 | Step 4: Entering Public Data : 359 | 360 | ![50 % center](LTM_Project_Data.jpg) 361 | 362 | Step 4: Institution Picker : 363 | 364 | ![50 % center](LTM_Project_Description_Institution.jpg) 365 | 366 | Step 5 :Project Review : 367 | 368 | ![50 % center](LTM_Project_Review.jpg) 369 | 370 | All these parameters can also be edited afterwards from the **Project 371 | Environment** Menus. 372 | 373 | ### User Manager 374 | 375 | The **User Manager** includes basic tools : 376 | 377 | 1. User Login system including Password recovery 378 | 2. User Profile manager including photos, link to other users' pages 379 | 380 | ## Phase II : Development of the App and Code Library Environment 381 | 382 | In the Phase II creates the environment for the development of the first Apps 383 | and the Code Library. 384 | 385 | The **Code Library** is a joint effort to create Operators (function) that can 386 | transform data based on parameters and that can be chained in a procedural 387 | manner. They can be called in Python and used for instance in a Jupyter 388 | Notebook. 389 | 390 | The **Apps** are dedicated environment with user interfaces to interact with the 391 | **Data Graph** and the **4D Map**. Some **Apps** may use Operators of the **Code 392 | Library** 393 | 394 | The **Project Environment** is extended to include projects creating **Apps** 395 | and operators for the **Code Library**. 396 | 397 | ### Examples of Apps 398 | 399 | #### Navigators 400 | 401 | Navigators are the equivalent of Browsers on the World Wide Web. They interpret 402 | the **Data Graph** and the **4D Map** to create different processes for 403 | exploration. Various typologies of \*\*Navigators can be designed : 404 | 405 | 1. Search Engines (including Visual Search Engines). A generic Search Engine can 406 | search the **Data Graph** globally giving results for IIIF documents, images, 407 | GeoEntities, Named Entities (Person, Place, Organisation, etc.), Conceptual 408 | Class of Object, and potentially Time Machine Users. 409 | 2. Collection Browsers 410 | 3. 4D Browser (web-based or application-based for better performances) 411 | 4. Data Graph Inspector / Editor 412 | 5. Pattern finder / navigators 413 | 6. Genealogical Explorer 414 | 415 | #### Importers 416 | 417 | Importers permit to link existing datasets to the **Data Graph** 418 | 419 | 1. IIIF Source Importer (Import an existing IIIF source). An imported source is 420 | immediately searchable in the Search Engine. 421 | 2. Collection creator: Create a new Time Machine hosted IIIF source, includes 422 | ingestion of a whole directory of images of limited size) 423 | 3. Geographical Layer Importer (e.g. Geojson importer) 424 | 4. Datatable importer (e.g. CSV) 425 | 5. Cadastral Parcels Importer 426 | 6. Cloud point Importer 427 | 7. Spherical Image Importer 428 | 8. 3D Model Importer 429 | 430 | #### Annotators 431 | 432 | Annotators are dedicated tools for annotating images and documents 433 | 434 | 1. Image Annotator: Permit to annotate zone of images in IIIF collection by 435 | defining zones and associate them with Time Machine or Wikidata ID). This 436 | makes these elements immediately searchable. 437 | 2. Transcription tool: Permit to input structure data (from based) to the Data 438 | Graph. For each document a **Data Mask** can be defined. 439 | 3. Parcel Annotator : Edit the Parcel Layer of the **4D Map** using a document 440 | as input 441 | 4. Point of View Annotator. Input a Point of View associated with an image in 442 | the **4D Map** 443 | 5. Place Name Annotator. Associated a segment of an image with a Place in Place 444 | Name layer of the **4D Map** 445 | 6. Homologous Point Annotator : update the homologous point network 446 | 7. Spherical Image Annotator 447 | 8. Table Annotator 448 | 9. Parsers dedicated to specific document structure (Cadaster, Directories) 449 | 450 | #### Aligners 451 | 452 | 1. Georeferencing tool : Permit to Georeference a map part of the IIIF source by 453 | clicking on a number of **Homologous Points** 454 | 2. Photoalignment tools : Permits to connect a photo with a map and with other 455 | photos based on **Homologous Points**. 456 | 457 | #### Conflict Detectors 458 | 459 | **Conflict Detectors** detect incoherence in the **Data Graph** and help users 460 | solve them. 461 | 462 | #### Digitisation and Storage Services 463 | 464 | Apps can also offer specific services like digitisation or storage in direct 465 | link with the **Data Graph** and the **4D Map** 466 | 467 | ### Examples of Operators from the Code Library 468 | 469 | #### Segmenters 470 | 471 | **Segmenters** can be used for 472 | 473 | 1. Objects and Persons in images 474 | 2. Parcels in Cadastral Maps 475 | 3. Document Layout analysis 476 | 4. 3D Object segmentation. Using the **homologous point network** inside the 477 | **Data Graph**, some 2D to 3D segmenter uses 2D segmentation to segment 3D 478 | objects 479 | 480 | #### Transcribers 481 | 482 | Transcribers perform state of the art HTR transcription in document. 483 | 484 | # Examples of Scenarios and Services 485 | 486 | ## Museum creating a Project 487 | 488 | One objective of Time Machine is to localize cultural objects in Space and Time. 489 | For instance, an object in a museum can be associated with several 490 | spatio-temporal references: its place of production, the various places it was 491 | stored before entering the Museum, the spatio-temporal entity it represents. One 492 | consequence is that a museum in Paris may contribute to many LTMs in the world, 493 | having for instance paintings representing Venice, Madrid or Budapest. 494 | Inversely, in many cases, the evidence of reconstructing the past of a city or a 495 | site is scattered in collections all over the world. 496 | 497 | To enter and curate data in the **Data Graph**, a museum will create a 498 | **Project**, possibly jointly with other institutions, with a particular 499 | spatio-temporal anchoring objectives. For simplicity of the explanation, let’s 500 | assume the collection to be ingested is already digitised. The steps are the 501 | following: 502 | 503 | 1. In the **Project Environment**, the Museum defines the approximate **Zone of 504 | Coverage** of the collection. This will define the **Municipalities** (and 505 | therefore the **Local Time Machines**) for which the data will be relevant. 506 | It can be updated later. 507 | 2. The Museum enters the repository where the **Source** collection is, 508 | typically as a IIIF repository. If the Museum does not have an IIIF solution, 509 | a physical or virtual **Time Machine Box** can be used. This is an example of 510 | **App** adapted to the **Data Graph**. The data will remain in the chosen 511 | repository unless the Museum wants to benefit from a long-term preservation 512 | service. 513 | 3. Using dedicated **Apps**, like **Annotators**, the project partners 514 | reposition the objects of the chosen collection in space and time (for 515 | instance annotating content of paintings or documenting the steps in the 516 | trajectory of the objects) 517 | 4. A **Conflict Detector** tool (another specific **App**) is capable of 518 | informing of any conflict in the metadata inserted linked to other operations 519 | of the Time Machine (for instance due to an inference or a non-compatible 520 | entree). On this basis, the Museum may or may not update its metadata or 521 | launch specific research initiatives to investigate further the conflicting 522 | data elements. 523 | 524 | Being part of the Data Graph, the new inserted collection will benefit from all 525 | the others innovations done in the Time Machine environment. 526 | 527 | This case is a simple one. More complex curation may occur. 528 | 529 | ## Digitisation Hubs 530 | 531 | The **Digitisation Hubs** are an example of services that will be offered to 532 | Local Time Machines for digitisation (e.g. scanning of documents, streets, 3D 533 | scanning). 534 | 535 | The **Digitisation Hubs** will enable to seamlessly aggregated new document and 536 | metadata into a **Data Graph**, with the appropriate standards in terms of 537 | resolution, file formats, and metadata during acquisition. Contractual aspects 538 | will be dealt with the Time Machine Standard Contracts. 539 | 540 | The Structure and detailed functioning of the Digitisation Hubs are planned to 541 | be developed first as a RFC specifying their structure then implemented as a 542 | Service operated by several operators. As planned in the **RFC Tree**, the **RFC 543 | on Digitisation Hubs** is planned in 2021. It will be established directly with 544 | actors that may become Service operators. 545 | 546 | What is anticipated are the following steps : 547 | 548 | 1. Creation of a **Project** with of the digitisation Services on timemachine.eu 549 | 2. Specification of its **Zone of Coverage**. The **Zone of Coverage** will 550 | determine the Local Time Machines in which the services will be publicised. 551 | 3. Precise definition of digitisation offers using only **Standard Metrics** in 552 | order to be able to determine the exact price of the operations. 553 | 4. Once the service are ready, creation of an **App** for offering the service. 554 | 555 | This way of functioning should enable to create a well-functioning single 556 | European market for digitisation services connecting operators and customers 557 | using agreed standards. 558 | 559 | ## Long-term Preservation 560 | 561 | Likewise, some partners may offer services for the long-term preservation of 562 | particular datasets (e.g. IIIF repository). This can for instance include DNA 563 | storage. 564 | 565 | # Subsequent Development Phases 566 | 567 | The subsequent development phases are not detailed in this RFC but will be in 568 | future ones. 569 | 570 | ## Phase III : Development of the Franchise Model 571 | 572 | In Phase III, the process for consolidating Local Time Machine activities in the 573 | **Municipality** itself is developed. This phase is described in the 574 | corresponding RFCs : 575 | 576 | - **RFC on Franchise System** (planned 2023) 577 | 578 | ## Phase IV : Development of the Mirror World Environment 579 | 580 | This phase will be developed in the corresponding RFCs : 581 | 582 | - **RFC on Mirror World Prototyping** (planned 2025) 583 | - **RFC on Mirror World Extension Strategy** (planned 2026) 584 | - **RFC on Mirror World Technical Standards** (planned 2026) 585 | - **RFC on Virtual/Augmented Reality and Discovery** (planned 2026) 586 | - **RFC on 4D Mirror World** (planned 2026) 587 | - **RFC on Large Scale Mirror World** (planned 2027) 588 | 589 | # Coordination, Training and Local Dynamics 590 | 591 | ## Time Machine Academies 592 | 593 | The goal of the **Time Machine Academies** is to help to global coordination in 594 | the development of **Apps** and the training of their use. 595 | 596 | Examples of Communities : 597 | 598 | - Developers (Academic and SMEs) 599 | - GLAM professionals 600 | - Scholars 601 | - Stakeholders of specific Exploitation Avenues (e.g. Tourism, Creative 602 | Industries) 603 | 604 | The details of the Time Machine Academy Process is developed in a separate RFC. 605 | 606 | ## Local Time Machine Events 607 | 608 | Processes for organising local time machine event will also be discussed in a 609 | separated RFC 610 | 611 | # Questions and Answers 612 | 613 | ## Can I create a Local Time Machine ? 614 | 615 | Not directly. But by creating a project that works on a particular 616 | **GeoEntity**, I can start the development of the corresponding **Local Time 617 | Machine**. 618 | 619 | ## Can I edit a Local Time Machine ? 620 | 621 | Not directly. But the **Local Time Machine** webspace is updated as information 622 | about projects are updated. 623 | 624 | ## If my project studies a large object like Hadrian's Wall in which Local Time Machine will it be included? 625 | 626 | It will be included on all the Local Time Machine focused on **Municipalities** 627 | that include a part of of the Hadrian's Wall. 628 | 629 | ## I am part of an important institution of a City, how can my institution take part in the City Local Time Machine ? 630 | 631 | By starting or redocumenting a project focusing on a **GeoEntity** that is part 632 | of the **Municipality**. 633 | 634 | ## Can my project name be called (Name of City) Time Machine ? 635 | 636 | A priori, no. Only Local Time Machines are called Time Machines. 637 | 638 | ## My institution would like to participate to Local Time Machine but we are not located in the city. What can we do ? 639 | 640 | This is not a problem. The institution must participate to a project focusing on 641 | a **GeoEntity** that is part of the **Municipality** 642 | 643 | # Linked RFCs 644 | 645 | - **RFC on 4D Map** (to be planned) 646 | - **RFC on Apps** (to be planned) 647 | - **RFC on Operators** (to be planned) 648 | - **RFC on Time Machine Academy** and **RFC on Local Time Machine Events** 649 | (Maybe redundant with **RFC on Training**, planned 2020) 650 | -------------------------------------------------------------------------------- /files/releases/RFC-0014/RFC-0014.md: -------------------------------------------------------------------------------- 1 | --- 2 | # Don't change this header section 3 | title: "RFC on Digitisation Priorities and Data Selection" 4 | subtitle: "Time Machine RFC-0014" 5 | author: 6 | - Juha Henriksson 7 | header-includes: 8 | - \usepackage{fancyhdr} 9 | - \pagestyle{fancy} 10 | - \fancyhead[R]{} 11 | - \fancyfoot[L]{-release-version-} 12 | output: pdf_document 13 | --- 14 | 15 | # Motivation 16 | 17 | Guidelines for building a digital collection and selecting material for 18 | digitisation will help Time Machine partners to focus on priority aspects and to 19 | take decisions accordingly. For reference, the National Information Standards 20 | Organisation (NISO) has already proposed a framework for guidance on Building 21 | Good Digital Collections[^niso]. 22 | 23 | # Digitisation plan 24 | 25 | Digitisation should be based on an overall strategy approved by the 26 | organisation's management, in order to ensure, for example, adequate resources 27 | and the long-term management of the digital objects. Digital collection builders 28 | should be able to refer to the mission statement of their organization and 29 | articulate how the proposed digital collection furthers or supports that mission 30 | [^niso]. 31 | 32 | The digitisation plan guides, among other things, the selection of material to 33 | be digitised, the order of digitisation, and working methods. The plan should 34 | also include a scheme how digitised instances will be made available. The 35 | organisation should be able to identify the target audience(s) for the digital 36 | collection, but also think about unexpected uses and users [^niso]. 37 | 38 | The digitisation plan should be made for a longer period of time. However, there 39 | are also cases where a selection policy may not be required, such as 40 | digitisation on demand, when an organization is creating digital content based 41 | on end-user requests, or mass digitisation projects, which are often 42 | indiscriminate [^niso]. 43 | 44 | The use of open standards promotes, among other things, the interoperability of 45 | systems and data, the large-scale use of data, and the long-term preservation. 46 | It is therefore recommended that digitisation projects shall follow the European 47 | Interoperability Framework [^joinup]. 48 | 49 | The quality and cost-effectiveness of digitisation can be improved by 50 | collaborating with other organizations. In order to avoid duplication of work 51 | and to facilitate collaboration, information on digitisation projects should be 52 | published openly for transparency [^digisam]. 53 | 54 | # Conditions for digitisation 55 | 56 | The digitisation plan should include an analysis of the availability of 57 | sufficient preconditions and resources to carry out the plan and to ensure that 58 | the digitized material can be preserved and made available also in the future. 59 | In addition to financial, human and technical resources, the digitisation plan 60 | and the order of digitisation are also affected by, for instance, issues related 61 | to the physical condition of the material, the quality of the descriptive 62 | metadata and the legal status of the material, such as: 63 | 64 | - Are there enough human and financial resources are available to digitize a 65 | sufficient amount of material? To make a digitisation project worthwhile 66 | requires a certain minimum volume of information. Otherwise, the research 67 | value will be too low to attract enough planned or potential users. [^lucidea] 68 | - Are there any copyright restrictions on the material that either prevent the 69 | digitisation of the material or the use of it? Clarifying rights is often 70 | laborious, which takes up human resources from the actual digitization work. 71 | The digital preservation strategy will require the occasional re-mastering of 72 | the digital images (possibly onto new storage media) and this will also 73 | require permission from the copyright holder. [^tasicp] 74 | - Are there GDPR restrictions? The General Data Protection Regulation [^eur-lex] 75 | regulates the processing of personal data that may be contained in the 76 | material itself or in the descriptive or technical metadata. GDPR regulations 77 | contain safeguards and derogations relating to processing for archiving 78 | purposes in the public interest, scientific or historical research purposes or 79 | statistical purposes, but nevertheless contain restrictions on the processing 80 | of personal data of living people. 81 | - How much work is needed to improve the descriptive and technical metadata to 82 | the level required for a digital collection? Digital materials should be 83 | described so that a user can discover characteristics of the collection, 84 | including scope, format, restrictions on access, ownership, and any 85 | information significant for determining the collection’s authenticity, 86 | integrity, and interpretation [^niso]. 87 | - Is the material in good enough condition for digitisation or does it need 88 | conservation? Or is the original material so fragile that the process may 89 | damage it further? 90 | - Does the organisation have the necessary technical expertise and knowledge of 91 | the content of the material in order to digitise a particular type of 92 | material, or are external resources required? 93 | 94 | # The selection criteria 95 | 96 | Digitisation usually has different goals, which can also be at least partially 97 | contradictory. For instance, a sapient balance must be found between digitising 98 | popular materials and providing a richer representation of the institution’s 99 | holdings. [^lucidea] Therefore, making a digitisation plan requires careful 100 | consideration and comparison of different aspects. When making a digitisation 101 | plan, the following, for example, can be taken into account, when considering 102 | what material to select for digitization. 103 | 104 | - **Usage:** Is there an active, current audience for the materials? Or is 105 | current access to the original materials inadequate (e.g., owing to heavy use 106 | of popular items or to restricted access to fragile or costly items)? Will 107 | digitization attract enough new users to justify the cost? [^nedcc] 108 | - **Protection:** Analogue material is fragile, so digitisation saves the 109 | original material from damage. 110 | - **Added value:** Digitisation opens up new possibilities. Automatic text or 111 | pattern recognition improves search capabilities. Linking entities increase 112 | research opportunities. New technologies such as 3D, 4D and virtual reality 113 | improve the attractiveness and usability of the material. 114 | - **Preservation:** The nature of analogue material is such that digitisation is 115 | the only way to ensure its long-term preservation and usability (e.g., audio 116 | and video stored on magnetic tapes). 117 | - **Uniqueness:** Are the objects rare or unique? Many unique institutional 118 | resources such as original photographs, archival materials, or grey literature 119 | such as university technical reports and conference proceedings, have not yet 120 | been digitised. 121 | - **Provenance:** Provenance means that the full history of the material and its 122 | ownership, from its discovery or production to the present day, is known. A 123 | limited and and/or fragmented sample of material often have no wider cultural 124 | or research value. It is recommended to systematically digitize certain entity 125 | that has emerged as a result of a certain activity, and thus forms a unified 126 | provenance. 127 | - **Internal significance:** How does digitisation of materials contribute to 128 | organization’s own activities, both immediate and long-term, such as teaching 129 | and research? 130 | - **Exposure:** How much does digitisation of materials increase the visibility 131 | and significance of the organisation? How does it improve possibilities to get 132 | new funding? 133 | 134 | 135 | 136 | [^digisam]: 137 | https://digisam.se/wp-content/uploads/2014/08/Guiding%20principles%20for%20working%20with%20digital%20cultural%20heritage.pdf 138 | 139 | [^eur-lex]: https://eur-lex.europa.eu/eli/reg/2016/679/oj 140 | [^joinup]: 141 | https://joinup.ec.europa.eu/collection/nifo-national-interoperability-framework-observatory/european-interoperability-framework-detail 142 | 143 | [^lucidea]: https://lucidea.com/blog/selection-for-digitization/ 144 | [^nedcc]: 145 | https://www.nedcc.org/free-resources/preservation-leaflets/6.-reformatting/6.6-preservation-and-selection-for-digitization 146 | 147 | [^niso]: https://www.niso.org/sites/default/files/2017-08/framework3.pdf 148 | [^tasicp]: 149 | https://web.archive.org/web/20060212114719/http://www.tasi.ac.uk/advice/managing/copyrights.html 150 | -------------------------------------------------------------------------------- /files/releases/RFC-0033/images/RFC-0033-pipeline.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/time-machine-project/requests-for-comments/46f660f7b259c2c4a3ed4e79d9ccfc06f150f0f8/files/releases/RFC-0033/images/RFC-0033-pipeline.png -------------------------------------------------------------------------------- /files/releases/RFC-0033/images/pipelines.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/time-machine-project/requests-for-comments/46f660f7b259c2c4a3ed4e79d9ccfc06f150f0f8/files/releases/RFC-0033/images/pipelines.png -------------------------------------------------------------------------------- /files/releases/RFC-0034/RFC-0034.md: -------------------------------------------------------------------------------- 1 | --- 2 | # Don't change this header section 3 | title: "RFC on Audio Processing Pipeline" 4 | subtitle: "Time Machine RFC-0034" 5 | author: 6 | - Juha Henriksson 7 | - 8 | header-includes: 9 | - \usepackage{fancyhdr} 10 | - \pagestyle{fancy} 11 | - \fancyhead[R]{} 12 | - \fancyfoot[L]{-release-version-} 13 | output: pdf_document 14 | --- 15 | 16 | # Motivation 17 | 18 | This RFC defines the general architecture for audio. The document deals with how to produce high-quality audio files that are suitable for research purposes and that can also be preserved for future uses. 19 | 20 | Digitising and preserving audio recordings is often challenging, because there is a great variety of different audio medium types and recording formats. In addition, the lifespan of analogue and digital audio carriers is limited by their physical and chemical stability and the availability of playback technology. 21 | 22 | Digitising audio recordings usually requires a lot of resources, as not all work steps can be automated, especially in smaller cultural heritage organizations. The preservation strategy should therefore be able to balance the current and future needs of the users as well as the organisation's conditions and resources. 23 | 24 | Signal retrieval from the original audio carriers is usually the most significant work step in terms of quality [^iasa1]. Preserving digitised and born-digital audio files requires regular transfers to a new storage medium and migrations to new file formats. These should be taken into account when the audio material is transferred from the original storage medium for the first time. 25 | 26 | A somewhat simpler audio digitisation workflow aimed at small and medium-sized cultural heritage organizations can be found in Europeana Digitization Handbook [^eur1]. 27 | 28 | # Selecting materials for digitisation 29 | 30 | Digitising recordings is expensive and slow, and it takes a lot of human resources. If the audio collection to be digitized is extensive, choices must be made regarding what to digitise and in what order. In the selection and prioritisation of the material to be digitised, there are several different perspectives that should be taken into account. 31 | 32 | Various general factors related to the selection of material to be digitised are discussed in more detail in the document RFC-0008. Regarding audio recordings, special attention should be paid to the risk of destruction of the original audio carriers and the availability of playback devices. Matters related to the selection of audio material to be digitised are discussed in more detail in the IASA document "Task Force to Establish Selection Criteria" [^iasa2]. 33 | 34 | The risk of destruction of audio carriers is one of the most important factors when planning the digitisation process. Analogue and digital recordings stored on magnetic media will inevitably deteriorate over time. The life cycle of digital recordings stored on optical media is also limited and can vary between 5 and 100 years [^iasa3]. However, the destruction of audio carriers can be slowed down if the recordings are stored under the recommended conditions [^iasa4]. 35 | 36 | The availability of new playback devices for audio tapes is also very limited and the price level is high. On the other hand, used devices are still available, but they wear out over time. Thus, equipment and spare parts should be stocked if the digitisation process takes a long time or if new material is accumulated in the future. In addition, playback equipment must be serviced regularly. 37 | 38 | In the era of analogue sound recording, many different media types and recording formats were used. Because of that, a great variety of different playback devices is usually needed. Various analogue audio media types are described, for example, on the website of the Museum of Obsolete Media [^obsolete1]. There are also various formats of digital sound recorded on magnetic tape, all of which require different playback devices. 39 | 40 | # Deterioration of audio tapes 41 | 42 | Old magnetic audio tapes may have deteriorated, especially if they were not stored in the proper conditions. Deteriorated tapes may require special treatment before they can be played [^iasa5]. In practice, deciding the order of digitisation based on the risk of destruction can be difficult, as, for example, there may be large differences in the shelf life of different manufacturing batches of a certain magnetic tape label. 43 | 44 | The plastic compounds used as a binder for polyester tapes may have reacted with the moisture in the air (hydrolysis), causing the tapes to become sticky. In this case, particles may release from the tapes into the tape recorder, causing the tape to squeak and even completely stop the operation of the tape recorder. In the worst case, the entire tape will fall apart. Sticky tapes should never be played without special treatment. This requires expertise and special equipment, as unprofessional treatment will ruin the tape irrevocably. 45 | 46 | Fragile acetate tapes should be handled carefully so that they do not break. Optimum playback of the magnetic tape would require a sufficiently high tape tension, but this easily leads to breakage when the tape is fragile. Tus, playing back brittle acetate tapes requires both skill and professional-grade, easily adjustable tape recorders with no extra friction in the rotation mechanism. 47 | 48 | # Signal extraction from original carriers 49 | 50 | Signal extraction from original carriers is most often the work step of the recording digitisation process that affects the quality of the end result the most. The work phase requires professionalism and precision. Matters related to the playback of sound recordings in different formats are described in more detail in IASA's recommendations [^iasa6]. Regarding magnetic tapes, the workflow published in the TAPE project [^musa1] may also be used as a help. 51 | 52 | The effect of analogue reproduction equipment on the quality of digitisation is usually much greater than that of digital equipment, so it is worth using high-quality equipment. Professional tape devices have versatile adjustment options and are more resistant to long-term use. In addition, the mechanism of professional-level equipment spins the tape more gently than consumer-level devices, which is an advantage when playing old fragile tapes. 53 | 54 | Adjusting the angle of the audio heads for each tape is important for sound quality. Adjusting the audio heads is especially important if the original recording was made with a different device than the one used to reproduce the tape. An error in the final result caused by the wrong alingnment of the audio head cannot be corrected later [^iasa7]. 55 | 56 | Print-through is the unintentional transfer of magnetic fields from one layer of analogue tape to another layer on the tape reel. The effect of print-through on the quality of digitisation can be significantly reduced if the tape to be played is rewinded back and forth at least three times before it is digitised [^iasa8]. When winding the tape, a low speed and reduced tape tension should be used, if possible, so as not to stress the tape unnecessarily. 57 | 58 | # Analogue audio tape formats 59 | 60 | The audio head formats of open-reel tape can vary even within the same tape. For example, mono, mono half-track, stereo half-track or stereo signal could have been recorded on the same open-reel tape. Recording speeds, recording direction and even equalisation may also vary. If the necessary technical metadata of the original recording is not available, optimal playback can be a slow and tedious process. If, for example, the tape is played back with a sound head of a different width than it was recorded, the sound quality will deteriorate significantly and the amount of noise will increase. 61 | 62 | When playing an audio tape, the same equalization standard should be chosen with which the tape was recorded. However, over the years there have been numerous equalisation standards for various tape speeds [^iasa9]. Choosing the right equalisation standard is made even more difficult by the fact that at a certain time both the old and the new standard may have been in use. In addition, the equalisation time constants used at different tape speeds may vary. C-cassettes are somewhat easier than open-reel tapes in this regard, as there is only one equalisation standard per tape type (I, II or IV). 63 | 64 | When the audio signal was recorded onto a tape, a noise reduction system may have been used. The most common noise reduction systems are [^iasa10]. 65 | - Dolby A and Dolby SR (professional) 66 | - Dolby B and Dolby C (domestic) 67 | - dbx I (professional) and dbx II (domestic) 68 | 69 | The alignment of the replay characteristics of the tape machine is important for the correct functioning of the noise reduction. Noise reduction can also be done afterwards, but it is recommended that it be done at the time of digitisation. 70 | 71 | # The A/D conversion 72 | 73 | In practice, the influence of the analogue pathway of the digitization process on the final result is much greater than the digital pathway, because nowadays A/D converters are usually of high quality. The A/D converter must not colour the sound or add extra interference or noise to it. IASA has given recommendations on what kind of specifications the equipment used for digitising archival recordings should meet [^iasa11]. 74 | 75 | The sampling rate determines how wide a frequency range of analogue audio can be digitally recorded. The standard 44.1 kHz of a CD audio disc is not sufficient for high-quality archiving. With a higher sampling rate, sound frequencies are recorded that exceed the hearing capacity of the human ear, but a higher sampling rate may still improve the quality of the sound, and, above all, it facilitates possible restoration. The more accurately, for example, disturbances and noise can be recorded, the easier it is to remove them if necessary. Although no corrections should be made to the archival copy itself, correction and processing of the user copies may be necessary if the original recordings are of very low quality, so that researchers can use the recordings in question. 76 | 77 | IASA recommends a sampling frequency of at least 48 kHz [^iasa11]. In practice, especially when digitising recordings of poor quality, it would be advisable to use a higher sampling frequency. In practice, the sampling frequency of 96 kHz can be considered as a minimum standard, if the aim is to achieve a high-quality result. 78 | 79 | When digitising recordings, a sufficiently high sound resolution must be used so that the entire dynamic scale of the analogue recording can be recorded. IASA recommends a resolution of at least 24 bits for digitising analogue archival recordings [^iasa11]. High resolution is particularly useful in the restoration of recordings in poor condition. 80 | 81 | In digital audio recording, the recording level must never exceed the zero level, otherwise the sound will be cut and distorted. If a sufficiently high resolution is used, the recording level can be adjusted somewhat below the zero level without fear of losing some of the dynamics of the original analogue recording. In practice, it makes sense to leave some headroom, for example 3–6 dB. 82 | 83 | # Target file formats 84 | 85 | The digitisation result should be stored in a file format that is as widely used as possible. In this case, it is more likely that the format in question will remain in use for a long time, and a possible future migration to an up-to-date format would be as simple as possible. 86 | 87 | It is not recommended to use any compression on archival copies. You must also not make any corrections to the archival copy, as they will irreversibly change the audio file. All possible corrections and improvements should only be made to user copies. 88 | 89 | In archives, digital sound is most commonly stored in the WAV format (Microsoft Wave). The WAV format supports all sampling rates and resolutions for both mono and stereo audio. WAV files are of the RIFF (Resource Interchange File Format) type, meaning that the specifications are saved as part of the file. Uncompressed PCM-encoded (Pulse Code Modulation) WAV files are preferred for storing digital archival recordings [^iasa11]. 90 | 91 | In addition to archival copies, it often makes sense to store user copies with a lower sampling frequency and resolution. Various lossy compression algorithms can be used to significantly reduce the size of the audio file. However, lossy compression, as its name suggests, destroys audio information once and for all. Researchers often need uncompressed files. On the other hand, in the case of user copies that can be listened to on the Internet, compression is often acceptable. 92 | 93 | Common file formats for lossy compression are, for example, AAC and MP3. If the user copies are compressed, a sufficiently high sampling frequency and bit stream should be used (for example, at least 44.1 kHz or 48 kHz, and 128 Kbit/s or 192 Kbit/s). It is important to keep in mind that the MP3 standard does not define a codec. Thus, there are many different MP3 codecs and their compression quality varies. 94 | 95 | # Digital audio formats 96 | 97 | In addition to analogue audio recordings, digital recordings should also be transferred without delay to a storage system suitable for long-term preservation. Digital recordings in optical and magnetic formats have a limited lifespan, and playback often requires equipment that is no longer manufactured. Also, audio files stored on memory sticks or hard drives should be transferred to a system that enables their long-term storage. 98 | There might be several copies of a digital recording. In choosing the best source copy, consideration must be given both to audio standards and other specifications including any embedded metadata. Also, data quality of stored copies may have degraded over time. As a general rule, a source copy should be chosen which results in successful replay without errors, or with the least errors possible [^iasa12]. 99 | 100 | Identification of the format of the source material is essential to ensure optimum playback, but it is complicated by the variety of formats with similar physical appearance but different recording standards. It is recommended that digital recordings be saved using the same encoding they were created with. However, in the case of rare formats, it is worth making another recording for one of the commonly used encodings. 101 | 102 | The R-DAT tapes (commonly referred to as DAT) have been widely used both in recording and archiving. However, the shelf life of DAT tapes is limited. Furthermore, the availability of good condition DAT recorders is a problem. Especially newer DAT tapes may have been recorded using extensions of the original standard such as high resolution recording at 96 kHz and 24 bits, Timecode (SMPTE) recording, or Super Bit Mapping, which bring more challenges in terms of playback [^iasa13]. 103 | 104 | Besides the R-DAT system, there are also many other digital tape formats. These include open reel digital systems, systems using standard VCR to record digital audio encoded on a standard video signal, and systems using videotape as the storage medium for digital audio signal formats [^iasa14][^iasa15]. All of these need their own devices for playback, and availability of these devices can be a big problem. 105 | 106 | Also optical discs such as CDs and DVDs have a limited lifespan. This applies especially to self-recorded discs. Thus, it is important to transfer them without unnecessary delays to a better storage platform for long-term storage. The Audio CD family includes a great variety of different disc types [^iasa16]. Besides the Audio CD, here are also other optical disc audio formats such as DVD-A and SACD [^iasa17] [^iasa18]. Furthermore, audio files can also be saved as files on CD-ROMs and DVD-ROMs, for example in .wav or mp3 format. 107 | 108 | Minidisc recordings employ a data reduction algorithm called Adaptive Transform Acoustic Coding (ATRAC). It should be noted that the artefacts that ATRAC create, cannot be recalculated or compensated later. ATRAC is a proprietary format, with many versions and variations [^iasa19]. Thus, it is advisable to re-encode the resultant files as .wav files. 109 | 110 | # Techinical metadata 111 | 112 | It is recommended to collect enough technical metadata about the original recording and the equipment used, as well as the parameters related to digital recording. This helps, for example, to automate future migration as far as possible. Likewise, systematic errors in digitisation can be corrected. For example, if it is later discovered that a certain playback equipment has worked incorrectly, all recordings digitised with that equipment can be digitised again. 113 | 114 | The technical metadata should preferably contain, for example, the following information: 115 | 116 | - Type of the recording 117 | - The playback equipment and its audio head formats 118 | - Playback parameters such as equalization standard, noise reduction standard, and playback speed 119 | - The A/D converter used 120 | - Recording software and its version 121 | - Responsible persons and dates 122 | - Digital recording format such as file format, sampling rate and resolution 123 | - Possible anomalies that occurred in the digitisation process 124 | 125 | # Linked RFCs 126 | 127 | - The **selection of material to be digitised** is discussed in more detail in **RFC-0008**. 128 | 129 | 130 | 131 | [^eur1]: 132 | [^iasa1]: 133 | [^iasa2]: 134 | [^iasa3]: 135 | [^iasa4]: 136 | [^iasa5]: 137 | [^iasa6]: 138 | [^iasa7]: 139 | [^iasa8]: 140 | [^iasa9]: 141 | [^iasa10]: 142 | [^iasa11]: 143 | [^iasa12]: 144 | [^iasa13]: 145 | [^iasa14]: 146 | [^iasa15]: 147 | [^iasa16]: 148 | [^iasa17]: 149 | [^iasa18]: 150 | [^iasa19]: 151 | [^obsolete1]: 152 | [^musa1]: 153 | -------------------------------------------------------------------------------- /files/releases/RFC-0035/RFC-0035.md: -------------------------------------------------------------------------------- 1 | --- 2 | # Don't change this header section 3 | title: "RFC on Video Processing Pipeline" 4 | subtitle: "Time Machine RFC-0035" 5 | author: 6 | - Juha Henriksson 7 | - 8 | header-includes: 9 | - \usepackage{fancyhdr} 10 | - \pagestyle{fancy} 11 | - \fancyhead[R]{} 12 | - \fancyfoot[L]{-release-version-} 13 | output: pdf_document 14 | --- 15 | 16 | # Motivation 17 | 18 | This RFC defines the general architecture for video. The document deals with how to produce high-quality video files that are suitable for research purposes and that can also be preserved for future uses. 19 | 20 | Digitising and preserving video recordings is often challenging, because there is a great variety of different video formats. In addition, the lifespan of analogue and digital video carriers is limited by their physical and chemical stability and the availability of playback technology. 21 | 22 | Digitising video recordings often requires a significant amount of resources, as not all work steps can be automated, especially in smaller cultural heritage organizations. The preservation strategy should therefore be able to balance the current and future needs of the users as well as the organisation’s conditions and resources. 23 | 24 | Signal retrieval from the original video carriers is often the most significant work step in terms of quality. Furthermore, preserving digitised and born-digital video files requires regular transfers to a new storage medium and migrations to new file formats. These should be considered when the video material is transferred from the original storage medium for the first time. 25 | 26 | A somewhat simpler video digitisation workflow aimed at small and medium-sized cultural heritage organizations can be found in Europeana Digitization Handbook [^eur1]. 27 | 28 | # Selecting materials for digitisation 29 | 30 | Digitising video recordings is expensive and slow, and it takes a lot of human resources. If the video collection to be digitised is extensive, choices must be made regarding what to digitise and in what order. In the selection and prioritisation of the material, there are several different perspectives that should be taken into account. Various general factors related to the selection of material to be digitised are discussed in more detail in the document RFC-0008. Regarding video recordings, special attention should be paid to the risk of destruction. Often technical factors such as the condition, age and format of the original video carriers determine the urgency of digitisation, as especially the oldest cassettes are in danger of deteriorating to the point of being unusable. 31 | 32 | The selection of videos to be digitised and the order of digitisation is also significantly influenced by the fact that, because of the large number of magnetic and optical video formats, a lot of different equipment is needed, the manufacture of many of which has already been discontinued. Servicing tape recorders requires expertise, which is becoming less and less available, and the availability of spare parts is decreasing all the time. The situation is made somewhat easier by the fact that recorders are often backwards compatible. For example, Digital8 recorders can play also Video8 and Hi8 tapes. 33 | 34 | Museum of Obsolete Media has published a Video Media Timeline [^obs22] and information about different video tape formats, video discs, and other video medias [^obs21], which can be used as an aid in detecting the necessary equipment. California Audiovisual Preservation Project as published a guide to identification of video tape formats [^cal1]. Furthermore, Museum of Obsolete Media has published Media Stability Ratings [^obs14] and Obsolescence Ratings [^obs15] which can be used as a help when planning the order of video digitisation. 35 | 36 | # Video systems 37 | 38 | There are three different video systems, the oldest of which is NTSC (National Television System Committee) that was developed for the needs of American television. PAL (Phase Alternating Line) has since been developed based on NTSC, as well as the SECAM system (Séquentiel couleur à mémoire), which closely resembles it. It is possible to convert a video from one system to another, but its quality drops with each conversion, when the image size and number of frames per second changes. 39 | 40 | **NTSC** [^wiki7] was developed in the in the early 1940s. The video signal is assigned to 525 horizontal lines (480 visible lines) and the transmission has 30 frames (60 half frames interlaced) per second. The video image of the NTSC system is weaker in terms of vertical sharpness than the video image according to the PAL system, because the maximum signal frequency of the luminance signal (Y-signal, luminance, luma) is lower than in the PAL system. 41 | 42 | The **PAL** [^wiki8] system prevails in most of Europe. PAL was developed on the basis of the NTSC system in the mid-1960s. Improvements were made especially to the colour signal of the video image. In addition, the vertical resolution of the video image was improved by increasing the frequency range of the luminance signal over the chrominance signal (C-signal). In the PAL system, the video signal is assigned to 625 horizontal lines (576 visible) and the transmission has 25 (50) frames per second. 43 | 44 | **SECAM** [^wiki10] resembles PAL, and the video signal is also assigned to 625 horizontal lines (576 visible) and 25 (50) frames per second. However, in the SECAM system the colour signal uses frequency modulation, resulting in only one signal for each line. Thus, SECAM does not have colour saturation disturbances like PAL. But, for the same reason, SECAM is not linear and combining two synchronized SECAM signals may not produce a valid SECAM signal. 45 | 46 | # Analogue video formats 47 | 48 | An analogue video signal contains colour (chrominance) and lightness (luminance) signals, either combined (composite video) or separately (S-Video, component video). Unlike digital video, analogue video does not have a time code, unless it is added separately with digital **TBC** [^wiki11] (Time base correction) technology. 49 | 50 | When digitising videos, the highest quality video signal should be used that the video format supports. Of lowest quality is **composite video** [^wiki4], where all the data of the video signal travels along the same cable, causing interference and unevenness. Of the analogue video formats such as VHS/VHS-C and Video8 are based on composite video signal. The second best analogue signal is **S-Video** [^wiki9] (Separated video, also known as Y/C), where the Y and C signals are separated. For instance, S-VHS, Hi8, U-matic and Betamax support S-video signal. The best option is **component video** [^wiki3], where the video signal is split over three components Y, Pʙ and Pʀ. Among other, Betacam and Betacam SP video players have component video output. 51 | 52 | **U-matic** [^obs18] was introduced in 1971. U-matic cassettes are large, with a tape width of 3/4 inch. U-matic was aimed at consumers, but it did not become common in domestic use. However, the format found its way into TV production in the mid-1970s. Other U-matic versions include the smaller U-matic S, U-matic High Band (BVU, Broadcast Video U-Matic), and U-matic SP (Superior Performance) versions. 53 | 54 | **VHS** [^obs19] (Video Home System) was introduced in 1976. It is the best known and most common of the consumer analogue video systems. Disadvantages of VHS include small image size (240×576 PAL / 240×486 NTSC), poor image quality, and poor carrier life. **S-VHS** [^obs17] (Super VHS) is significantly better than VHS in terms of image size (resolution 400 lines). In S-Video technology, the chrominance and luminance signals are separated and do not interfere with each other. S-VHS recorders can play standard VHS tapes, but VHS recorders cannot play S-VHS tapes. **VHS-C** (Compact VHS) is a smaller version of the VHS cassette designed for home video use. There are adapters for VHS-C cassettes that allow one to play them with a VHS (or S-VHS) recorder, but the rarer **S-VHS-C** cassette needs its own camera and adapter. 55 | 56 | When it comes to image quality, **Betamax** [^obs3] (Beta) is close to VHS, with the resolution of 250 lines. Whereas Betamax was developed for the consumer market, **Betacam** [^obs2], based on Betamax, was aimed for professional use. Betacam and Betamax cassettes are almost identical in appearance, but they have an indication of which model the cartridge represents. Betacam was the first analogue video recorder system in which the video signal was recorded on tape in component form, the chrominance and luminance signals separately on their own video tracks. Therefore, the high-frequency chrominance signal of the video signal cannot soften the sharpness of the image when dubbing the tapes. Time code can also be recorded on Betacam tapes with a built-in TBC. 57 | 58 | With **Betacam SP** [^obs1] (Superior Performance) tapes, the recording capacity was increased to 90 minutes with L-sized tapes, which are considerably larger than conventional Beta tapes. Betacam SP recorders can play both cassette sizes without a separate adapter. The resolution of Betacam is 300 lines and of Betacam SP 340 lines. 59 | 60 | **Video8** [^obs23] was a home video format, from which the Hi8 and Digital8 formats were later developed. Video8 corresponds in quality to VHS video (resolution 240, composite output). The **Hi8** [^obs12] video has a better image quality than its predecessor (resolution 400, S-video output), but the format is still analogue, even though digital audio can be recorded on the cassettes with more advanced cameras. Video8, Hi8 and Digital8 cassettes are the same size and backwards compatible. 61 | 62 | # Digital video tapes 63 | 64 | A digital video signal contains significantly more data than an analogue signal. In addition to time code, digital video contains – depending on the type of video – various types of metadata. Although digital videos can theoretically be copied without any loss in quality, even cassettes and discs designed for professional use do not last indefinitely. Therefore, digital video cassettes and discs should be transferred as files to a digital preservation system. 65 | 66 | In the PAL system, a digital video image can be recorded at 25 frames per second as a **progressive** image or 50 half frames per second as an **interlaced** image. Since the technology that records 25 frames per second was considered too jerky for television, the interlaced image was introduced in TV production. In the interlaced video, the image is built from half fields consists of horizontal lines, every other one of which is recorded in the first field, and every other one in the next one. This creates the illusion of smoother movement at the expense of image integrity. When watching an interlaced video image, the fields change every 1/50 of a second. The interlaced image does not become a problem as long as it is viewed on the devices intended for it, for example a standard television. However, computer screens use a progressive image, whereby a fast-moving interlaced image appears jagged. An interlaced image can be changed to a progressive format using the deinterlace function of an editing software. 67 | 68 | **DV** (Digital Video) is both a codec and a physical cassette format. There are two sizes of cassettes, the smaller and more common of which is called **MiniDV** [^obs16]. MiniDV was primarily aimed at consumers. The resolution of DV video is 720×576 pixels and the bit rate is 25 Mbps. 69 | 70 | **DVCAM** [^obs8], developed on the basis of DV technology, was intended for professional use. It differs from standard DV in its durability and more precise synchronization of sound and image. DVCAM tapes also have fewer dropout errors than standard DV tapes. DVCAM recorders can play DV tapes, and some newer DVCAM recorders can also play DVCPRO tapes. The image resolution and bitrate are the same in all three formats. 71 | 72 | **Digital8** [^obs7] uses the same DV codec as DV and DVCAM, and in all its features resembles these formats more than its analogue predecessors Video8 and Hi8. In terms of technical characteristics, Digital8 tapes are almost identical to MiniDV tapes. 73 | 74 | The **DVCPRO** [^obs9] format is available in three different quality standards. DVCPRO (also called DVCPRO25) closely matches DV technology in terms of features, but it is more common in professional use due to slightly better image quality. **DVCPRO50** [^obs10] is about twice as high quality. It corresponds to Digital Betacam in terms of image quality. There is also a version of DVCPRO for high-definition video, DVCPRO HD (DVCPRO100). The DVCPRO100, DVCPRO50, and DVCPRO cassettes are backwards compatible. 75 | 76 | **Digital Betacam** [^obs6] (Digibeta) is comparable in features to the DVCPRO50 level, but it uses the rarer DCT codec. The data recorded by Digibeta is of a high quality: the bit rate of the video is 90 Mbps and the sound is recorded uncompressed on four audio tracks, PCM encoded, 48 kHz / 20 bit. 77 | 78 | # Video discs 79 | 80 | In addition to magnetic tapes, videos have been stored on optical media for decades. It is noteworthy that not only video tapes deteriorate, but also optical discs have a limited lifespan. This applies especially to self-recorded discs. Thus, it is important to transfer them without unnecessary delays to a better storage platform for long-term preservation. 81 | 82 | **LaserDisc** [^obs13] was the first optical video format. LaserDisc discs are double-sided, and the disc sizes are 12-inch and 8-inch. LaserDisc comes with a horizontal resolution of 440 lines (PAL), and the analogue output is S-VHS-quality. Based on LaserDisc and CD technologies, the **CD Video** [^obs5] (CDV) format was developed. There are three sizes of plates: 5, 8 and 12 inches. 83 | 84 | **Video CD** [^obs20] (Compact Disc Digital Video, VCD) was an optical format based on CD technology. VCDs are playable in dedicated VCD players, and they are also widely playable in most DVD players. In PAL system the resolution is 352 x 288, 25 frames / second, using MPEG-1 codec with 1150 kbps. The audio is 44.1 kHz, 224 kbps. 85 | 86 | **DVD-Video** [^obs11] uses MPEG-2 Part 2 compression at up to 9.8 Mbps. A single-level DVD-Video disk can hold 4.7 GB of data. Data compressed in MPEG-2 format is quite lossy, and when combined this with the limited shelf life of self-burned DVDs, DVD-Video format cannot be recommended for permanent storage of video recordings. 87 | 88 | **Blue-Ray** [^obs4] was designed to supersede the DVD format, capable of storing several hours of high-definition video. Blu-Ray discs are identical in size to DVD discs, but information is stored at a much higher density due to the use of blue lasers. Thus, Blu-Ray discs they can store 25 GB of data on single-layer discs and 50 GB on double-layer layers. As of November 2022, there are no less than five versions of Blu-ray Disc Recordable Erasable (BD-RE) and four versions of Blu-ray Disc Recordable (BD-R) [^wiki1]. 89 | 90 | # Replay of analogue video tapes 91 | 92 | The effect of analogue reproduction equipment on the quality of video digitisation is usually much greater than that of A/D converters and other digital equipment. Because of the vast amount of different videotape specifications, some governed by standards and some not, digitising analogue video tapes is demanding, and this broad topic cannot be properly addressed within the scope of this document. 93 | 94 | Instructions can be found, for example, in IASA Guidelines for the Preservation of Video Recordings, where there is comprehensive advice on how to replay obsolete videotapes [^iasa1]. Each format-based chapter provides advice specific to that particular carrier and the video tape recorders needed to play those carriers back. There are also general advice on the assessment, preparation, cleaning, and heat treatment of videotapes. Additional carrier-specific advice on these topics, where relevant, will be found in the sections devoted to specific carriers. 95 | 96 | # File formats and codecs 97 | 98 | For videos in digital format, it makes sense to preserve the original file format, codec, resolution and bitrate, because the quality will in most cases decrease if the file is converted to another format. 99 | 100 | A **codec** (coder-decoder) is a device or program that converts (encodes) a video or audio file into a storage and presentation format. The conversion can take place to a protected (encrypted) format and from there back to the presented format. The signal can also be compressed **lossy** (lossy codec) or **lossless** (lossless codec) to save space. Lossless compressed data takes up more space than lossy compressed data, but it can be unpacked in original quality. 101 | 102 | In lossy codecs, it is important to pay attention, in addition to the codec properties, to the data transfer speed (bit rate), which determines how much data the video contains in relation to its duration. The bit rate is reported in kilobits per second (kbps, kb/s, kilobits per second) or megabits per second (Mbps, Mb/s, megabits per second). For example, the bit stream of DVD-video is 7–10 Mb/s, whereas the bit rate of DV- video is 25 Mb/s. 103 | 104 | The encoded video is stored in a **container format** [^wiki5], also called a **wrapper**. A container allows multiple data streams to be embedded into a single file, that is, audio, video, subtitles, tracks, and metadata (tags) — along with the synchronization information needed to play different data streams together. Containers may identify how data is encoded, but they do not provide instructions about how to decode that data. Thus, a software that can open a container must also use an appropriate codec to decode its contents. 105 | 106 | There are many different possibilities for wrapping a video [^wiki2]. Commonly used video wrappers include, among others, the freely licenced **Matroska** [^loc8] (.mkv), **MPEG-4** File Format [^loc6] (Version 2, Part 14,.mp4), **Quick Time** File Format [^loc3] (.mov), **Audio Video Interleave** [^loc4] (.avi), and **Material Exchange Format** [^loc1] (.mxf). 107 | 108 | Due to numerous different video wrappers and codecs and their different combinations, choosing a video storage format for preservation purposes is not an easy task. Library of Congress recommends [^loc12] that videos are stored with the original production resolution, frame rate, and file-based format that was delivered to the content distributor. The following video formats are recommended, in order of preference: 109 | - **Interoperable Master Format** [^wiki6] (IMF) consisting of essence files as MXF [^loc2] tracks including video, audio, data and dynamic metadata essences, composition playlist, and packaging data 110 | - **ProRes** (QuickTime .mov container with 4444 (XQ)/4444 [^loc10], or 422 HQ [^loc9] codecs) 111 | - **MPEG-2** [^loc7] 112 | - **XDCAM** [^wiki12] (MXF container with HD422, SHD422, or HD codecs) 113 | 114 | IASA's guidelines for video formats are more detailed and they are based on six different categories depending on the format of the original video [^iasa2]. IASA has also published a thorough Target Format Comparison Table [^iasa3]. 115 | The video formats and codecs for preservation purposes require often so much storage space that their distribution over the network is slow. Thus, it often makes sense to make a user copy(s) for viewing purposes and for other use via the network. User copies may be stored, for example, with the following codecs: 116 | - **H.264** [^loc5] (Advanced Video Coding AVC, MPEG-4 part 10) 117 | - **H.265** [^loc11] (High Efficiency Video Coding HEVC, MPEG-H Part 2) 118 | 119 | The H.265 is newer and more advanced than H.264, and it compresses information more efficiently. H.265 files are almost half in size compared to H.264, with comparable video quality. 120 | 121 | # Technical metadata 122 | 123 | It is recommended to collect enough technical metadata about the original video and the equipment used, as well as the parameters related to digital video files. This helps, for example, to automate future migration. Likewise, systematic errors in digitisation can be corrected. If it is later discovered that a certain playback equipment has worked incorrectly, all videos digitised with that equipment can be digitised again. 124 | The technical metadata should contain, for example, the following information: 125 | - Type of the recording 126 | - The playback equipment and playback parameters, especially if they differ from those specific to the media 127 | - The A/D converter used 128 | - Recording software and its version 129 | - Responsible persons and dates 130 | - The format of the digital recording, including the video codec and bit stream 131 | - The characteristics of audio tracks such as format, number of tracks, sampling frequency and audio resolution 132 | - Possible anomalies that occurred in the digitisation process 133 | 134 | # Linked RFCs 135 | 136 | - The **selection of material to be digitised** is discussed in more detail in **RFC-0008**. 137 | 138 | 139 | 140 | [^cal1]: 141 | [^eur1]: 142 | [^wiki1]: 143 | [^wiki2]: 144 | [^wiki3]: 145 | [^wiki4]: 146 | [^wiki5]: 147 | [^wiki6]: 148 | [^wiki7]: 149 | [^wiki8]: 150 | [^wiki9]: 151 | [^wiki10]: 152 | [^wiki11]: 153 | [^wiki12]: 154 | [^obs1]: 155 | [^obs2]: 156 | [^obs3]: 157 | [^obs4]: 158 | [^obs5]: 159 | [^obs6]: 160 | [^obs7]: 161 | [^obs8]: 162 | [^obs9]: 163 | [^obs10]: 164 | [^obs11]: 165 | [^obs12]: 166 | [^obs13]: 167 | [^obs14]: 168 | [^obs15]: 169 | [^obs16]: 170 | [^obs17]: 171 | [^obs18]: 172 | [^obs19]: 173 | [^obs20]: 174 | [^obs21]: 175 | [^obs22]: 176 | [^obs23]: 177 | [^iasa1]: 178 | [^iasa2]: 179 | [^iasa3]: 180 | [^loc1]: 181 | [^loc2]: 182 | [^loc3]: 183 | [^loc4]: 184 | [^loc5]: 185 | [^loc6]: 186 | [^loc7]: 187 | [^loc8]: 188 | [^loc9]: 189 | [^loc10]: 190 | [^loc11]: 191 | [^loc12]: 192 | -------------------------------------------------------------------------------- /files/releases/RFC-0036/RFC-0036.md: -------------------------------------------------------------------------------- 1 | --- 2 | # Don't change this header section 3 | title: "RFC on Music Score Pipeline" 4 | subtitle: "Time Machine RFC-0036" 5 | author: 6 | - Juha Henriksson 7 | - 8 | header-includes: 9 | - \usepackage{fancyhdr} 10 | - \pagestyle{fancy} 11 | - \fancyhead[R]{} 12 | - \fancyfoot[L]{-release-version-} 13 | output: pdf_document 14 | --- 15 | 16 | # Motivation 17 | 18 | This RFC defines the general architecture for music scores. The document deals with how to store music notation that is in digital format. The recommended file formats not only promote long-term preservation and access of digital notated music, but also ensure compatibility between different software as well as offer opportunities for versatile use, for example for research purposes. 19 | 20 | # Digital music scores 21 | 22 | Sheet music in digital form can be created with scorewriting programs, optical music recognition (OMR) software [^wiki], or music sequencer software. Many of these softwares have their own storage format, while others use more commonly used storage formats. 23 | 24 | Digital notated music is recommended to be stored in an XML-based markup music notational format. Library of Congress recommends [^loc1][^loc2] MusicXML [^mxml1] and the Music Encoding Initiative (MEI) [^mei1], in that order. Both these formats make it possible to preserve and access digital notation also in the coming years. 25 | 26 | For preservation purposes, it might be reasonable to save the notated music as a PDF/A file as well [^loc3]. In addition, if the original sheet music was written with a notation software such as Sibelius, Finale, Dorico, or MuseScore, it is recommended to preserve the original files of that program as well, just to be safe. 27 | 28 | Files must not contain any digital rights management technologies, encryption, or other measures that control access to or prevent use of the digital score. 29 | 30 | # MusicXML 31 | 32 | MusicXML is an XML-based file format for representing Western musical notation. MusicXML was designed from the ground up for sharing sheet music files between applications, and for archiving sheet music files for use in the future. 33 | 34 | MusicXML is very widely used, which guarantees compatibility between many different software. Over 260 different software features at least some MusicXML interchange capability [^mxml2]. These include most scorewriting programs such as Sibelius, Finale, and MuseScore, most optical music recognition programs, and most music sequencer programs. 35 | 36 | Many of the above-mentioned programs can both read and write MusicXML format. There are also plugins for Sibelius and Finale available [mxml1]. The MusicXML document type definitions (DTD) and XML Schema Definitions (XSD) are each freely redistributable, and the files are available from the W3C MusicXML GitHub repository [^mxml3]. W3C Comminity Group has published a tutorial [^w3] to software developers who are interesting in reading or writing MusicXML files. However, the advantage of MusicXML is that users need no knowledge of coding or XML to save or open MusicXML files. If the software has MusicXML read/write capabilities, it can open and/or create files in this format [^loc4]. 37 | 38 | # Music Encoding Iniative (MEI) 39 | 40 | The Music Encoding Initiative (MEI) [^mei2] is a public standard controlled by the scholarly community. Even though MusicXML may be considered the preferred form of permanent preservation of digital sheet music over MEI, it may be advisable to convert the music also to the MEI schema, because it opens music to new forms of study gaining prevalence in the digital humanities, in which researchers use automation to explore and interact with collection materials and descriptions as data [^loc5]. 41 | 42 | MEI defines a system for encoding musical documents in a machine-readable structure. It is based on open standards and is platform-independent. MEI is not limited to modern standard notation. Neumes, tablature, and mensural notation can be encoded as well [^loc5]. 43 | 44 | MEI contains the same functionality as MusicXML in terms of notation and page layout, but it also can encode information about the notation and its intellectual content in a structured and systematic way. The MEI schema [^mei3] is a core set of rules for recording physical and intellectual characteristics of music notation documents expressed as an XML schema. 45 | 46 | The MEI schema is complemented by the MEI Guidelines [^mei4], which provide detailed explanations of the components of the MEI model and best practices suggestions. The MEI community also provides a wide range of tools [^mei5] for working with MEI data. They can serve a whole range of purposes, from data creation or conversion to rendering or analysis. 47 | 48 | The Music Encoding Initiative's online tool Verovio [^vero] provides instant rendering from MEI to notated music and conversion from MusicXML to MEI. In Verovio, the MEI file can also be converted to a PDF. So far, only Sibelius notation software can directly export files in MEI format. 49 | 50 | # Metadata 51 | 52 | The stored files should be equipped with a sufficient metadata [^loc1], which supports their future use and research. The recommended metadata includes (if available): title, creator, creation date or start date/end date, place of publication, publisher/producer/distributor, ISMN and other relevant identifiers, instrumentation, language of work, edition, and subject descriptors. Furthermore, also events and abstracts are recommended to be included, if available. 53 | 54 | # Optical Music Recognition 55 | 56 | **Optical Music Recognition (OMR)** is a field of research that investigates how to computationally read music notation in documents [^dl1]. OMR is a challenging process that differs in difficulty from OCR and HTR because of the properties of music notation as a contextual writing system. First, the visual expression of music is very diverse. For instance, the Standard Music Font Layout [^smufl1] currently lists over 2440 recommended characters, plus several hundred optional glyphs. Second, it is only in their configuration – how they are placed and arranged on the staves, and with respect to each other – that specifies what notes should be played. 57 | 58 | The two main goals of OMR are: 59 | - **Recovering music notation** and information from the engraving process, i.e., what elements were selected to express the given piece of music and how they were laid out. The output format must be capable of storing music notation, e.g., MusicXML or MEI. 60 | - **Recovering musical semantics** (i.e., the notes, represented by their pitches, velocities, onsets, and durations). MIDI would be an appropriate output representation for this goal. 61 | 62 | # Automatic Music Trascription 63 | 64 | **Automatic Music Transcription (AMT)** is the process of automatically converting audio recordings of music into symbolic representations, such as sheet music (e.g., MusicXML or MEI) or MIDI files. AMT is a very useful tool for music analysis. AMT comprises several subtasks, including (multi-)pitch estimation, onset and offset detection, instrument recognition, beat and rhythm tracking, interpretation of expressive timing and dynamics, and score typesetting. Due to the very nature of music signals, which often contain several sound sources that produce one or more concurrent sound events that are meant to be highly correlated over both time and frequency, AMT is still considered a challenging and open problem. [^ieee1] 65 | 66 | 67 | 68 | 69 | [^dl1]: 70 | [^loc1]: 71 | [^loc2]: 72 | [^loc3]: 73 | [^w3]: 74 | [^loc4]: 75 | [^loc5]: 76 | [^ieee1]: 77 | [^mei1]: 78 | [^mei2]: 79 | [^mei3]: 80 | [^mei4]: 81 | [^mei5]: 82 | [^mxml1]: 83 | [^mxml2]: 84 | [^mxml3]: 85 | [^smufl1]: 86 | [^vero]: 87 | [^wiki]: 88 | -------------------------------------------------------------------------------- /files/releases/RFC-0069/RFC-0069.md: -------------------------------------------------------------------------------- 1 | --- 2 | # Don't change this header section 3 | title: "RFC on Time Machine Organisation (TMO)" 4 | subtitle: "Time Machine RFC-0069" 5 | author: 6 | - Juha Henriksson 7 | - 8 | header-includes: 9 | - \usepackage{fancyhdr} 10 | - \pagestyle{fancy} 11 | - \fancyhead[R]{} 12 | - \fancyfoot[L]{-release-version-} 13 | output: pdf_document 14 | --- 15 | 16 | # Motivation 17 | 18 | Over the centuries, national, regional and local identities have evolved in relation to one another, through large swathes of transnational mobility and through dense commercial and cultural exchanges that have shaped languages, traditions, arts and many other aspects of human activity. We have a vital need to restore and intensify our engagement with our past as a means of building a common path for existing and future generations, as well as facilitating a dialogue between diverse historical memories, their values and mutual interdependencies. 19 | 20 | Time Machine Organisation (TMO) responds to this need by creating an institutional network running large-scale distributed digitisation and computing infrastructures that will connect history and culture across the world, opening the way for scientific and technological progress to become a powerful ally to safeguarding the diversity of each local identity. 21 | 22 | # Time Machine Organisation 23 | 24 | “Time Machine Organisation (TMO) – Organisation for international cooperation in technology, science and cultural heritage!” is an internationally oriented non-profit association under Austrian law. Its main office is located in Vienna and oversees a worldwide scope of activities. 25 | 26 | TMO ensures the sustainability and economic independence of the Time Machine project. TMO’s purpose, goals, structures, and functions are defined on the organisation´s constitution [^tmo1]. The association is open to any type of legal entity that deals with science, technology and cultural heritage. Furthermore, it is possible for individuals to join the Time Machine network by becoming a Time Machine Supporter [^tmo2]. 27 | 28 | # Goals 29 | 30 | TMO's main goal is to implement the entity defined in the Time Machine RCF documents, in cooperation with other organizations. These goals include: 31 | 32 | - Provide a platform for carrying out projects of different kinds in different funding programmes with different consortia (consulting in terms of funding instruments, finding appropriate partners, project management etc.) 33 | - Develop technologies in order to further advance the digital use and reuse of cultural heritage 34 | - Build an infrastructure that implements the goals and activities of Time Machine (servers, databases, platforms, etc.) as well as strengthen the practical capabilities of the TMO and its members 35 | - Create an environment for continuous exchange of knowledge, best practice and expertise in order to boost current and future developments (online knowledge base, Time Machine events, workshops, national stakeholder meetings, special networking events etc.) 36 | - Provide open source tools and technologies 37 | - Offer support in different fields (use of technologies and infrastructure, project building, etc.) 38 | 39 | Time Machine Organisation’s visions, missions and values are defined in more detail in document RFC-0007. Time Machine's infrastructure is based on the RFC on Technical Charter (RFC-0006). The TMO is also responsible for the management of the Time Machine RFC process in accordance with RFC-0004. 40 | 41 | # Membership 42 | 43 | Time Machine Organisation’s membership is based on the organisation´s constitution [^tmo1] and the respective membership fee regulation [^tmo3]. The association is open to any type of legal entity that deals with science, technology and cultural heritage. The three main member categories are: 44 | 45 | - Founding members, who contribute to a solid financial fundament of the Association by paying higher membership fees and fully participate in the Association with special rights and obligations 46 | - Regular members, who fully participate in the Association without any special rights and obligations 47 | - Associated members do not fully take part in the work of the Association, but they take interest in the Association’s benefits and exchange of knowledge and experience or benefit from special services provided by TMO 48 | 49 | # General Assembly 50 | 51 | TMO’s General Assembly takes place annually. All members have the right to attend the General Assembly. Only founding and regular members have voting rights, but all members have the right to speak. The functions of the General Assembly are defined in the constitution [^tmo1]. These include: 52 | 53 | - Acceptance and approval of the reports from the Executive Board about the activities and financial policy of the Association 54 | - Acceptance and approval of the collected annual financial statements from the Executive Board and the controller’s audit report. 55 | - Appointment of the members of the Executive Board and the controlling institutions. 56 | - Decision on membership categories, respective duties, benefits and fees 57 | 58 | # Executive Board 59 | 60 | The Association’s administration is incumbent upon the Executive Board that is appointed by the General Assemby. The Executive Board is composed of the president, at least one vice presidents, the treasurer and his/her deputy, the secretary and his/her deputy, and co-opted members. Only representatives of founding members are entitled to be candidates for membership in the Executive Board, unless the Executive Board decides to appoint a regular member to become a co- opted member. The term of the Executive Board is four years, and members can be elected for a maximum of two consecutive terms. 61 | 62 | The duties of the Executive Board, as well as obligations of individual Board members, is defined in the constitution [^tmo1]. The following matters in particular fall into the Executive Board’s responsibility: 63 | - Informing the General Assembly about the Association’s activities and financial situation 64 | - Preparing the Association’s annual account and assets, and providing these, as well all necessary information, to the controller 65 | - Convocation of the General Assembly 66 | - Managing the Association, which includes decisions in all service- and salary-related business 67 | - Actively supporting the intentions and objective targets of the Association 68 | 69 | # Linked RFCs 70 | 71 | - TMO’s **Visions, missions and values** are defined in **RFC-0007**. 72 | - The **Technical Charter** is defined in the **RFC-0006**. 73 | - The **RFC Editor** and the **RFC Editorial Committee** are defined in 74 | **RFC-0004**. 75 | 76 | 77 | 78 | [^tmo1]: 79 | [^tmo2]: 80 | [^tmo3]: 81 | -------------------------------------------------------------------------------- /files/template/RFC-template.md: -------------------------------------------------------------------------------- 1 | --- 2 | # Don't change this header section 3 | title: "[RFC Title]" 4 | subtitle: "Time Machine [RFC-id]" 5 | author: 6 | - Author 1 7 | header-includes: 8 | - \usepackage{fancyhdr} 9 | - \pagestyle{fancy} 10 | - \fancyhead[R]{} 11 | - \fancyfoot[L]{-release-version-} 12 | output: pdf_document 13 | --- 14 | 15 | # Motivation 16 | 17 | This file is the template to be used for new RFCs. It is intended to be both a 18 | starting point for new RFCs and an example of what can be achieved within the 19 | limits of a markdown file. 20 | 21 | # File structure 22 | 23 | ## YAML-Header 24 | 25 | To aid the generation of the final release-PDF-files, this markdown file 26 | contains a header in the `YAML`-format[^yaml]. Apart from other things it states 27 | the RFC-title and subtitle as well as information about the authors of the RFC. 28 | 29 | Please keep the header exactly as-is, its contents will be modified by the 30 | RFC-Editorial Team. 31 | 32 | ## Sections 33 | 34 | An RFC document should always contain the YAML header, a _Motivation_ section 35 | directly below the header as the first section in the document, as many 36 | author-defined sections as necessary as the main content, a _questions and 37 | answers_-section (_Q&A_) and the footnotes at the bottom of the document. 38 | Writers can delete the pre-existing section structure (with the exception of the 39 | motivation and q&a sections) in this file and add new sections as they see fit. 40 | 41 | The _Motivation_ section is intended to show the general reason for the writing 42 | of the RFC. It should be concise. 43 | 44 | The _Q&A_ section is intended to provide a view on the RFC from a different 45 | angle than the one of a traditional paper on a subject. It gives RFC writers the 46 | possibility to test their main structures, methods and drawbacks from the point 47 | of view of outside readers of the document. It should follow the general form 48 | outlined below in the q&a section of this template file. 49 | 50 | # TM Glossary 51 | 52 | Terms that are of special significance to the Time Machine must be written in 53 | **bold** on their first usage in an RFC document. Definitions and important 54 | terms are listed in _RFC-0001 on RFC Glossary_. 55 | 56 | # Markdown 57 | 58 | It is allowed to use the whole range of markdown features as well as everything 59 | supported by Pandoc out of the box. A good overview and introduction can be 60 | found in the markdown specification itself[^daring_markdown] and the Pandoc user 61 | documentation[^pandoc_markdown]. 62 | 63 | ## Hyperlinks 64 | 65 | RFCs are released as PDF documents. While it is possible to set hyperlinks in 66 | markdown that will also work in PDF documents it is advised to add the actual 67 | links in footnotes. This way they can be easily read. Footnotes (similar to the 68 | one in the previous paragraph can be created by adding `[^footnote_name]` where 69 | the footnote is to be placed and `[^footnote_name]: Content of the footnote` at 70 | the end of this file. Only alphanumeric characters and underscores are allowed. 71 | Hyperlinks in footnotes should be added in angled brackets: 72 | ``. 73 | 74 | ## Tables 75 | 76 | It is possible to use the different ways to create table using Pandoc 77 | markdown[^pandoc_tables]. The following example uses the simple syntax: 78 | 79 | | Column 1 | Column 2 | Column 3 | 80 | | -------- | -------- | -------- | 81 | | Foo | Bar | Baz | 82 | | Alpha | Beta | Gamma | 83 | 84 | Table: Demonstration of simple table syntax. 85 | 86 | ## Images 87 | 88 | It is possible to include images. They should be added in an `images` folder 89 | directly next to the markdown document. In the text they are referenced like 90 | this: `![Image caption](./images/image_name_including_file_ending.png)`. The 91 | path is relative to the location of the markdown file. 92 | 93 | # Q&A 94 | 95 | ## Question: Am I allowed to modify the YAML header on top of the file? 96 | 97 | No, the header is aimed at the creation of the release PDF files and should only 98 | be changed by the RFC-Editorial Team. 99 | 100 | ## Question: Can I omit the Motivation or Q&A sections? 101 | 102 | No, both sections are important for reviewers and implementers to understand the 103 | direction of the RFC, it's motivation and possibly problematic points / 104 | implications for other parts of the Time Machine. 105 | 106 | ## Question: Why doesn't my file look the same in my editor, the GitHub repository and the PDF files? 107 | 108 | The PDF files are created by an automated process using _Pandoc_[^pandoc], a 109 | tool to convert between different text formats. It provides more extensive 110 | capabilities for text structuring and formatting (for instance footnotes). This 111 | additional parts are not understood by the GitHub markdown parser and might be 112 | previewed differently by various markdown editors. 113 | 114 | ## Question: Where can I preview how my RFC document will look at the end? 115 | 116 | If you have started your document by forking the official GitHub RFC 117 | repository[^rfc_repo] you can see the current version of the RFC drafts in the 118 | _Action_ section of your own GitHub RFC repository[^github_manage_action] after 119 | you pushed a change to it. 120 | 121 | 122 | 123 | [^daring_markdown]: 124 | [^github_manage_action]: 125 | 126 | 127 | [^pandoc]: 128 | [^pandoc_markdown]: 129 | [^pandoc_tables]: 130 | [^rfc_repo]: 131 | [^yaml]: 132 | -------------------------------------------------------------------------------- /tm_logo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/time-machine-project/requests-for-comments/46f660f7b259c2c4a3ed4e79d9ccfc06f150f0f8/tm_logo.png --------------------------------------------------------------------------------