| title | subtitle | author | header-includes | colorlinks | output | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
RFC on RFC Tree |
Time Machine RFC-0002 |
|
|
true |
pdf_document |
The process for writing RFCs requires long-term planning instruments which will enable writers to not only access constantly updated versions of current RFCs but also to have a view on future planned RFCs. The RFC Tree as described in this RFC will provide an up-to-date description of all planned RFCs, including a short textual motivation for each and listing their dependencies with other RFCs.
RFC Tree is the metaphorical description and the hierarchical representation of the Time Machine Request for Comments development plan that will be used as a baseline scenario to help monitor the progress and achievements towards completion of the Time Machine Horizon over the coming 10 years.
While the RFC Tree itself results from the progressive completion of RFCs over time, it also acts as a blueprint for defining the incremental steps used to build the Time Machine Infrastructure.
RFC Tree behaves as a body of law for Time Machine, containing all RFC documentation and documenting the production process, as well as a progress indicator showing the progress of upgrades to Time Machine components in real time.
RFC Tree is a macro-architecture plan that shapes dependencies between RFCs. It could be divided into micro thematic or productive arcs, as each RFC belongs to a specific sequence and is classified in one of the following categories: Framework, Infrastructure, Data, Local Time Machines.
Singular RFCs are the basic units of the RFC Tree. The 70+ initial RFCs are listed at the end of this document. This initial set is an indicative path to completion of the Time Machine Horizon and may be expanded/modified/edited as needed. The tree-like structure and subsequent dependency chains which connect singular RFC guarantee that the Time Machine Horizon will be realised, as each RFC edit/removal/addition will cause dynamic adjustments and reorganisation.
This RFC provides the most up-to-date version of the RFC Tree.
\newpage
\newpage
Reaching consensus on the technology options to pursue in a programme as large as Time Machine is a complex issue. To ensure open development and evaluation of work, a process inspired by the Request for Comments (RFC) that was used for the development of the Internet protocol is being adapted to the needs of Time Machine. Time Machine Requests for Comments are freely accessible publications, identified with a unique ID, that constitute the main process for establishing rules, recommendations and core architectural choices for Time Machine components.
- Release
- 2020
\newpage
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.
- Release
- 2020
\newpage
The process for writing RFCs requires long-term planning instruments which will enable writers to not only access constantly updated versions of current RFCs but also to have a view on future planned RFCs. The RFC Tree as described in this RFC will provide an up-to-date description of all planned RFCs, including a short textual motivation for each and listing their dependencies with other RFCs.
- Release
- 2020
\newpage
This Request for Comments (RFC) describes the inner workings and technical details of the RFC platform itself. It aims to provide the technical framework for authorship, review, community contribution and publication of all future Time Machine RFCs.
- Release
- 2020
\newpage
This RFC outlines the basic policies and procedures related to the RFC Editor and the RFC Editorial Committee, many of which have been inspired by the IEEE Signal Processing Society. The main items that this document defines are: the appointment and responsibilities of the RFC Editor, the organisation of the RFC Editorial Committee, how members are appointed, procedure for applications, length of term and main duties.
- Release
- 2020
\newpage
In order to build a planetary-scale Time Machine, it is necessary to define an organic incremental strategy. To succeed, the Time Machine must be able to progressively anchor itself in local territories, bringing added value to local activities directly, spurring the creation of new projects to mine information of the past contained in surviving objects and documents. Local Time Machines (LTM) can be defined as zones of higher density of activities towards reconstruction of the past. This RFC defines the dynamics that will: enable bootstrapping of Local Time Machines, facilitate the onboarding of new projects, valorise the data extracted, facilitate the involvement of the local population, develop use cases for exploitation avenues, and eventually enable the development of sustainable structures where Big Data of the Past are fruitfully exploited thus leading to a constant increase of such activities.
- Release
- 2020
\newpage
The goal of the Technical Charter is to guarantee a first level of standardisation for data and processes, in order to remain light and usable by most, and the charter also encourages the use of universal and open interfaces and references that do not require central coordination
- Draft
- 2023
\newpage
In order to protect Time Machine's overarching purpose, fundamental values and ethical principles, a common charter will be created. Its duty will be to protect the core of TM and sustain its future. Becoming a TM network member implies ratification of the Vision, Mission and Values Charter
- Draft
- 2023
\newpage
Defining licenses to preserve intellectual property rights (regulating data acquisition, sharing and publishing) and to sustain the interoperability and accessibility of the TM. The proposed solutions could be based on the Creative Commons copyright licenses and should be further developed with the help of cultural-heritage networks (e.g. Europeana) who are experienced with these issues and are already proposing solutions. Means of monitoring the openness process of data should also be taken into consideration.
- Draft
- 2020
\newpage
Complying with TM Rules and Recommendations, legal settings, using TM components and understanding TM infrastructures will require specific training. A proper set of documentation, tutorials, videos and online courses will be offered to partners. This RFC will set the general rules for development of training materials, and these principles will subsequently be used by other more specific training RFCs.
- Proposal
- 2020
\newpage
The proposed LTM Value Scale (Key concepts and global overview – Local Time Machines), based on density criteria, will be outlined and its relevance and organisation further developed. Value scales concerning Projects will be created based on previously defined bricks and other criteria required in order to foster the development of Projects (e.g. collaboration, cooperation metrics). As some of the measures will relate to qualitative processes, a dedicated RFC on collaboration indicators will focus on creating a suitable system of metrics. The labelling system may require a third-party certification to assess its efficiency and accuracy.
- Proposal
- 2020
\newpage
Specific RFC rooted in the general principles established by RFC on Training but adapted to the framework developed in the RFC on LTM.
- Proposal
- 2020
\newpage
A typology of digitisation interventions will be established grouping:
- Collections that can be moved and processed in digital hubs (large, non-fragile collections), collections or objects that need local intervention (e.g. very fragile document, statues, buildings)
- Processes that can be performed by volunteers using mobile technology (e.g. scanning campaign across cities, on-the-fly digitisation in reading rooms), processes that can be performed using robots and drones, etc.
- Proposal
- 2020
\newpage
Definition of the terms and contracts enabling digitisation partners to become part of the Time Machine network.
- Proposal
- 2020
\newpage
A data selection model based on the identification of performance criteria will help partners to focus on priority aspects and to take decisions accordingly. For reference, the National Information Standards Organisation (NISO) has already proposed a framework for guidance on Building Good Digital Collections. Examples of performance criteria include: Significance of Content to Internal Stakeholders (degree to which a collection, once digitised supports the both immediate and long-term research and the teaching needs of the institution), Significance of Content to External Stakeholders (a highly successful digital collection is of interest to researchers and users outside of the university), Uniqueness (many unique institutional resources such as original photographs, archival materials, grey literature such as university technical reports and conference proceedings have not yet been digitised), Exposure (degree to which a digital collection garners positive recognition and press for an institution and assessing the potential for digital availability of the collection to result in grants and other funding). This digitisation recommendation will also be in line with the LTM coordinated strategy for digitisation.
- Release
- 2020
\newpage
Definition of the open hardware strategy for Time Machine including licensing terms and catalogues.
- Proposal
- 2020
\newpage
The data lifecycle within the TM begins with the concept of documents and data selection. The goal is to assist partners in selecting proper documents or collections to be processed by the TM pipelines and then subsequently which data within the documents. The data selection is closely related to the LTM or project perimeters (see LTM/Framework) and should be stated prior to any project launch. Criteria such as intellectual property rights, obtaining copyright permissions, digitisation, OCR processing or metadata creation costs must also be taken into account. Extending the results of the RFC of Digitisation Priorities and Data selection, the RFC will also detail data acquisition, data sharing and data publishing.
- Proposal
- 2021
\newpage
Definition of the format of the operation graph describing the operations currently pursued in the TM partners, as monitored by the Time Machine Organisation. It includes both automatic processes and human interventions.
- Proposal
- 2021
\newpage
The Time Machine Data Graph contains all information modelled in the Time Machine. The graph is constructed both manually and automatically through the processing of the Digital Content Processor. The Data Graph is intrinsically composed of two sub-parts: (1) The bright graph, which is composed of information that has been manually mapped and integrated with other large databases or used in a publication. This information is integrated with the current sum of digital human knowledge. It can be considered actual. (2) The dark graph, which is composed of information extracted automatically from (massive) documentation which has to this point been used in a stand alone fashion as individual historic items. It can be considered virtual.
- Proposal
- 2021
\newpage
Algorithms and software integrated into the Time Machine must be able to communicate with each other, thus a definition of joint APIs is required. It is likely that TM Services will be built on top of REST interfaces. In order to meet TM's needs, these will have to be adapted towards use in large-scale machine learning. A probable addition is the option to provide the gradient information of a specific module that is integrated using the API, for example. This way remote services can also be integrated into large-scale training processes.
- Proposal
- 2021
\newpage
Definition of Time Machine's multilingual strategy. This RFC impacts the exploitation platforms, as the TM will handle documents in multiple European languages and dialects. Some of these languages might be more complicated to address than others due to pre-existing tools for modern variants or availability of materials. A working plan for natural language processing (NLP) tool development should be conceived by taking into consideration the materials, the locations of the LTMs and the Digitisation Hubs, and the features of the languages.
- Proposal
- 2021
\newpage
Definition of the annotation protocols used for the documenting of TM Data Graph. This RFC will be used by exploitation platforms.
- Proposal
- 2021
\newpage
Digital Content Processors (DCP) are automatic processes for extracting information from documents (images, video, sound, etc.) As such, the following pipeline may be envisioned: (1) Development of a DCP in a dedicated “Sandbox” (a place where trial and error tests can be undertaken without compromising the entire functioning of the Time Machine architecture). Training will be done on existing labelled documents. (2) Submission of the DCP to the Time Machine Organisation's dedicated service. (3) After some benchmark and assessments of performance, resulting in acceptance or rejection, the suitable DCP becomes an Official TM Component.
- Proposal
- 2021
\newpage
DCP are automatic processes for extracting information from documents (images, video, sound, etc.) DCP of Level 1 only label mentions of entities. Each processing is fully traceable and reversible, and the results of the processing make up the core dataset of the Big Data of the Past and are integrated into the TM Data Graph. The document should define:
- The technical conditions for implementing DCP that can be inserted in the Time Machine Operation Graph.
- The requirements for hosting DCP in the TM Super Computing Infrastructure. The process by which DCP are developed, tested, labelled, published and put in operation.
- Proposal
- 2021
\newpage
DCP are automatic processes for extracting information from documents (images, video, sound, etc.) DCP of Level 2 label relations between entities. Each processing is fully traceable and reversible, and the results of the processing make up the core dataset of the Big Data of the Past and are integrated into the TM Data Graph. The document should define:
- The technical conditions for implementing DCP that can be inserted in the Time Machine Operation Graph.
- The requirements for hosting DCP in the TM Super Computing Infrastructure. The process by which DCP are developed, tested, labelled, published and put in operation.
- Proposal
- 2021
\newpage
DCP are automatic processes for extracting information from documents (images, video, sound, etc.) DCP of Level 3 label rules. Each processing is fully traceable and reversible, and the results of the processing constitute the core dataset of the Big Data of the Past and are integrated in the TM Data Graph. The document should define:
- The technical conditions for implementing DCP that can be inserted in the Time Machine Operation Graph.
- The requirements for hosting DCP in the TM Super Computing Infrastructure. The process by which DCP are developed, tested, labelled, published and put in operation.
- Proposal
- 2021
\newpage
The TM digitisation network will build upon existing EU Research Infrastructures (DARIAH, CLARIN) and infrastructure providing access to Cultural Heritage (Europeana, Archive Portal Europe, etc.) TM will introduce new processing pipelines for transforming and integrating Cultural Heritage data into such infrastructures.
- Proposal
- 2021
\newpage
This document will define the general rules that the TM Network partners must follow to integrate their computing resources into the TM Super Computing Architecture and the routing processes managing the data pipelines. In particular, this document will define:
- The hardware and software standards that the computing resources will follow across the entire distributed Super Computing Architecture.
- The routing protocols of the TM Operation Graphs.
- The processes for naming and renewing the administrators of the administrators
- The role of the TMO for managing of infrastructure.
- Proposal
- 2021
\newpage
Also meant to cover storage needs for data, the TM Box should help partners involved in a data acquisition, sharing or publishing process to conform to the metadata specifications and delivery – harvesting protocols as stated by the data model. One of its goals is to smoothen the process of and contribute to the automatization of the digitisation process (offering for instance a way of monitoring the digitisation tasks). This hardware is part of the Time Machine Official Components. The RFC will define how the production of the Time Machine Box should be managed in the long-term.
- Proposal
- 2021
\newpage
Defining the functioning and business model for the Digitisation Hubs. In order for the Digitisation Hubs to be implemented, standards in terms of resolution, file formats and metadata during acquisition need to be defined beforehand (RFC on Technical Charts). These standards must be consensual and simple in order to ensure easy implementation and fit into existing practices. The RFC must also evaluate relevant technologies and recommend affordable technologies that do not damage the objects, while also providing the best possible results at the same time. Time Machine aims to distribute affordable technology on a large scale using, for example, open design hardware. More costly and dedicated scanning solutions ,such as scan robots and tomographic methods, should be made available in specialised centres spread across the European Union such that their services are available to a maximum number of users. The objective of achieving affordable and wide-spread digitisation should be a priority in this RFC.
- Proposal
- 2021
\newpage
This RFC defines named entity recognition for older European languages and variants. The results of the tagging of entities will feed the Dark Data Graph with new information.
- Proposal
- 2022
\newpage
This RFC defines the general architecture for this particular kind of media. It must be aligned with the LTM central services.
- Proposal
- 2022
\newpage
This RFC defines the general architecture for this particular kind of media. It must be aligned with the LTM central services.
- Proposal
- 2022
\newpage
This RFC defines the general architecture for this particular kind of media. It must be aligned with the LTM central services.
- Release
- 2022
\newpage
This RFC defines the general architecture for this particular kind of media. It must be aligned with the LTM central services.
- Release
- 2022
\newpage
This RFC defines the general architecture for this particular kind of media. It must be aligned with the LTM central services.
- Release
- 2022
\newpage
This RFC defines the general architecture for this particular kind of media. It must be aligned with the LTM central services.
- Release
- 2022
\newpage
This RFC defines the general architecture for this particular kind of media. It must be aligned with the LTM central services.
- Proposal
- 2022
\newpage
This RFC defines the general architecture for this particular kind of media. It must be aligned with the LTM central services.
- Proposal
- 2022
\newpage
Investigating how to support partnerships across Time Machine member networks (e.g. Europeana, Icarus) or external cultural-heritage networks. The reflection should focus on a number of different aspects: how to enhance collaboration internally and externally, both at the level of the LTM and the TMO (e.g. with other LTM or partner networks); how to enhance exchange of best practices; how to share content and enhance collaboration between already existing cultural heritage networks and associations.
- Proposal
- 2023
\newpage
A franchise model clarifying the financial relationship between LTMs and the TMO’s services will be put in place, in accordance with the financial needs and costs of Time Machine's technical and coordination infrastructures. The franchise system must be scalable and adaptable, as the network will grow along with its reputation in the public eye and the financial benefit generated for LTMs. The franchise system is meant to be complementary to that which is established for the TMO partners. To enter a LTM, an institution should at minimum be required to become a member of the TMO. One of the subtasks of this RFC is to also assess and to further design the role of the TMO as a “Financial, Economic, Intelligence and Watch services office.
- Proposal
- 2023
\newpage
How to select, align and finance the “redocumentation” project, for potential projects compatible with TM goals but placed in a stand-by stage for a period of time, will be the main task of this RFC. What would it take (training, formation) to ensure the project scalability?
- Proposal
- 2023
\newpage
Defining what local and national measures might contribute to the creation of LTMs.
- Proposal
- 2023
\newpage
The TM distributed storage system will target offering an alternative solution to current HTTP-based storage. While in a first phase, most documents and data will be stored on specific servers accessible through standard protocols (e.g. images on IIIF servers), the aim of the project is to develop a storage solution that would have the following objectives: (1) Giving access to high volume of data with high efficiency, (2) Optimising storage to store more data, (3) Implementing long-term preservation of data, preventing accidental or deliberate deletion and keeping a fully versioned history of the data stored, (4) Guaranteeing authenticity of the data stored and preventing the inclusion of fake sources.
- Proposal
- 2023
\newpage
This document will define the infrastructure principles for a decentralized solution of public datasets based on Creative Commons licences like CC-0, CC-BY, CC-BY-NC and the Europeana rights declarations. Storage will be maintained for the resources shared by the partners of the TM Infrastructure Alliance. A distributed system like IPFS (InterPlanetary File System) and the work done by the IPFS Consortium for persistence of IPFS objects may be a good starting point, as such types of file systems do not identify a resource by its location but by a unique identification number. Routing algorithms optimised through P2P algorithms are the most efficient ways to bring the data to the visualisation or computing processes. This also speeds up the process when the host is a region with low connectivity. It is critical that redundancy and long-term resilience can be guaranteed, which means that the system must be designed to make any public data content that it stores un-deletable in practice. In turn, this will make it difficult to censor content, and for this reason it is especially well adapted for public data associated with creative common licenses. Systems like IPFS also provide the possibility for each node of the network to choose the categories of data they accept to replicate. This provides some flexibility in the negotiation of a common strategy by the Time Machine Infrastructure Alliance. To ensure the authenticity of the data stored, a blockchain type solution could be the solution. The interaction between the distributed file system and the authentication solution will be defined by the RFC.
- Proposal
- 2023
\newpage
Private datasets could be stored in either: (1) A specific layer of the distributed storage system, provided reliable cryptographic and authentication systems are in place, (2) A “fenced” location offered by partners of the Time Machine Network as storage solution. In both cases, the RFC should define how such closed datasets could use Time Machine infrastructure services and under which conditions.
- Proposal
- 2023
\newpage
This RFC defines the process for on-demand digitisation, enabling any user to request the digitisation of a specific document. An alignment with the archival description system will be necessary.
- Proposal
- 2023
\newpage
Definition of the strategy for optimising the digitisation processes. The objective of this RFC is, among others, to avoid digitisation of redundant printed material via a synchronization of all digitisation initiatives.
- Proposal
- 2023
\newpage
This RFC defines the orthographic normalisation of older European language variants. The results will improve the search functionality of the databases.
- Proposal
- 2023
\newpage
Content filtering may be necessary to control the exposure of users of Time Machine services to unsolicited content. Finding the right technologies which allow such controls without enabling the possibly of abusive censorship operations will be the challenge of this RFC.
- Proposal
- 2023
\newpage
Investigating how to support achievements and knowledge transfer inside the TM network, ensuring a global research collaboration at a European scale. There are only rare examples of large-scale research data management models, dealing with similar complexity levels as the TM; however, some guidelines can be found such as: “Guidance Document Presenting a Framework for Discipline-specific Research Data Management” (Science Europe, January 2018), “Practical Guide to the International Alignment of Research Data Management” (Science Europe, November 2018).
- Proposal
- 2024
\newpage
Defining the rules to be followed by the future smart clusters (for instance compliance with LTM rules and recommendations), ensuring means for the creation of such a space for creativity, supporting inter-disciplinary exchanges, political involvement and job creation, defining what types of relations could be built between the participants of the smart clusters and the partners of the LTM, and how to monitor, evaluate and revise or update the process.
- Proposal
- 2024
\newpage
This RFC defines key performance indicators to evaluate the level of collaboration among TM partners, both at a local and global level. It will also develop "affinity maps" to suggest potential future collaborations.
- Proposal
- 2024
\newpage
The Large-Scale Inference Engine is capable of inferring the consequences of chaining any information in the database. This enables Time Machine to induce new logical consequences of existing data. The Large-Scale Inference Engine is used to shape and to assess the coherence of the 4D simulations based on human-understandable concepts and constraints. Its origin derives from more traditional logic-based AI technology, slightly overlooked since the recent success of the deep learning architecture, that can, nevertheless, play a key role in an initiative like TM. This document will specify the various types of rules that the Large-Scale Inference Engine can process including: rules extracted from documents by DCP, implicit rules made explicit, and rules (statistical or not) induced from the data. The document should define: the process by which rules are submitted, tested and integrated in the engine, and the processes for managing conflicting rules or results from various rules. The document will also motivate implementation of solutions in relation with existing deployed systems like Wolfram Alpha or IBM Watson and standards like OWL, SKOS.
- Proposal
- 2024
\newpage
Through a hierarchical division of space (3D) and time, the system organises a multi-resolution 4D grid which serves as a general spatiotemporal index. Each “cube” in the grid indexes all the information relevant for these particular spatiotemporal elements. It offers an efficient perspective for organising large datasets and performing collective curation through manual and automatic processes. Each element of the grid will also potentially be labelled according to other various multidimensional criteria, some of them being AI-based descriptors (e.g. descriptors for architectural style detection in images).
- Proposal
- 2024
\newpage
The 4D grid is sparse, as there are many places/times in the world that are not directly associated with existing archival data. A central research challenge is to develop AI systems capable of extending the information of the data grid in space and time through continuous extrapolation and interpolation, and developing new ways of visualising which parts of the content are anchored in sourced data, simulated or unknown. Extensions of current deep-learning generative methods, originally developed for 2D imaging, can be envisioned to deal with the richness of the 4D datasets. Many 4D simulations can be associated with the same 4D grid, and one central challenge is to manage this multiplicity of worlds and their specific resolution levels for various services of the Time Machine (e.g. entertainment, policy planning).
- Proposal
- 2024
\newpage
To engage researchers in social sciences and humanities is to productively use the Big Data of the Past, and the TM can offer researchers a series of tools that facilitate analyses. These tools will be enhanced by the Digital Content Processor and the Simulation Engines, which will enable scholars to work with historical data in an unprecedented way.
- Proposal
- 2024
\newpage
Cutting-edge technologies, such as automatic scanning machines with low human supervision, scanning robots and solutions for scanning films and books without the need to unroll/open them, should be considered and fostered by the TM. A specific scheme to incentivise these technologies will be created. The goal is to reach an appropriate mix of dedicated specialized scanning centres and aid the development of mobile special use hardware, e.g. mobile CT scanners that are mounted on trucks.
- Proposal
- 2024
\newpage
The 4D Simulator manages a continuous spatiotemporal simulation of all possible pasts and futures that are compatible with the data. The 4D Simulator includes a multi-scale hierarchical architecture for dividing space and time into discrete volumes with a unique identifier: a simulation engine for producing new datasets based on the information stored. Each possible spatiotemporal multi-scale simulation corresponds to a multidimensional representation in the 4D computing infrastructure. When sufficient spatiotemporal density of data is reached, it can produce a 3D representation of the place at a chosen moment in European history. In navigating the representation space, one can also navigate in alternative past and future simulations. Uncertainty and incoherence are managed at each stage of the process and directly associated with the corresponding reconstructions of the past and the future. The document should specify the interaction of the 4D simulator with the rest of the architecture, answering questions like: How can an entity of the TM Data Graph be associated with a particular element of the 4D Grid?, How can 4D simulations be run and cached for future use?, How can the system be used directly in exploitation platforms?
- Proposal
- 2025
\newpage
The Universal Representation Engine manages a multidimensional representation of a space resulting from the integration of a pattern of extremely diverse types of digital cultural artefacts (text, images, videos, 3D and time) and permitting new types of data generation based on trans-modal pattern understanding. In such a space, the surface structure of any complex cultural artefact, landscape or situation is seen as a point in a multidimensional vector space. On this basis, it could generate a statue or a building or produce a piece of music or a painting, based only on its description, geographical origins and age. The document will specify the integration of the URE in the global architecture, outlining for example how a given node in the TM Data Graph can be associated with a parametric representation space.
- Proposal
- 2025
\newpage
Definition of the architecture for multilingual diachronic machine translation. Existing algorithms for machine translation will be adapted to older language variants of European languages. This will densify the Data Graph and provide more input to the Large-Scale Inference Engine.
- Proposal
- 2025
\newpage
Definition of the implementation strategy for the first working prototype of Mirror World using TM engines. This first prototype is likely to be developed on the most advanced LTM. This RFC will define how to safely experiment with this technology.
- Proposal
- 2025
\newpage
Mirror Worlds are linked with specific legal issues which will need to be addressed. This particularly concerns privacy and confidentiality.
- Proposal
- 2026
\newpage
The Mirror World extension strategy takes into account all the technical and legal choices defined by the RFC on Scaling in order to address the extension of the Mirror World to cover a larger, mostly European, scale.
- Proposal
- 2026
\newpage
This RFC defines the specific technical standards needed for the Mirror World extension, based on the experience provided by the Mirror World prototype.
- Proposal
- 2026
\newpage
Definition the standards that should be adopted in order to enable the development of Virtual/Augmented Reality services and the discovery module on top of the TM Data Graph.
- Proposal
- 2026
\newpage
This RFC defines how the Mirror World can be continuously synchronized with the TM DataGraph, enabling direct access and manipulation of 4D data.
- Proposal
- 2026
\newpage
Researchers will be able to use the TM simulation engines to perform simulation studies without having to rely on external models and tools. The simulation engines have the capacity to improve the performance and the reach of computational simulations for historical research.
- Proposal
- 2026
\newpage
This RFC consolidates the vision, strategy and framework conditions for the development of a World-Wide Mirror World.
- Proposal
- 2027
\newpage
This RFC describes the governance of Time Machine and the framework for the organisation of its development and community.
- Release
- 2023
\newpage
This RFC describes the Project Scouting Service that 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.
- Draft
- 2023
\newpage
This RCF defines the Time Machine Academies, provided by the Time Machine Organisation (TMO), that 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.
- Draft
- 2023
\newpage