TODO list, further developments

Ideas for further PET developments

In this section we collect a list of issues and feature ideas for further PET developments, guided by close discussion with stakeholders. Although it will likely be impossible to implement all of these in the course of PERICLES, we hope to come back to the list in later project and to inspire the open source community for contributions.

TODO: enter these todos into the issue system and add further explanations, so that external developers understand them!

• Address the creation context of Digital Objects by adding newly created Digital Objects based on environment events detected by the Environment Monitoring Daemons. We already tested the concept with the Directory Monitoring Daemon by adding the newly created files of an observed directory after getting a file creation event.
• Explore the possibility to support extraction using the PREMIS 3 vocabulary and LRM dependency definitions.
• Implementation of the investigated weighted graphs and integration into PET. The FreeMind open source tool (MIT license) could be used to visualize the weighted graph.
• Automated inference of dependencies from the monitored environment events.
• Extraction Module configuration Templates could be developed similar to the Profile Templates to export and ship single configured modules.
• Further development of the “General Native Command Module” that allows the execution of customized terminal commands as Extraction Module. A support for the extraction of parameters from the command output would be useful.
• The Information Tree is the main GUI display for extraction results. There are two other display methods available, which both allow the filtering of information by the Extraction Module that was used to extract it. It would be useful to enable such filtering also for the Information Tree. The same “Combo Box” for selecting the Extraction Module can be used for all three displays.
• Some operating system files could be naturally excluded from extraction and monitoring, for example using DF databases, such as the National Software Reference Library (NSRL) Hashsets and Diskprints. This would be helpful for handling of large amounts of files.
• Currently a “Part” is the data structure that represents an important file to be investigated during the extraction process. This concept could be extended to also support directories as “Parts”. It would allow to include all future files created in a directory to the investigation.
• The configuration of Extraction Modules could be supported by the CLI. At the moment the user has to modify the JSON configuration file directly to avoid the use of the GUI.
• At the moment there could be conflicts if two Extraction Modules get the same name. An UUID for Extraction Modules would be useful to avoid this.
• Think about if there is any good method to show the extracted information at the CLI. The problem is hard to solve, because of the great amount of extracted information.
• The Extraction Modules could be extended by a variable that indicates their current state. A state could indicate problems as “Further configuration needed”.
• Currently all existing Extraction Modules are loaded to the default profile at the first tool start. This is good for presentations, but less good for real usages. Better would be to load no module and to display a text to the user that Extraction Modules should be added to the profile.

Develop further Extraction Modules:

• Exif information extraction
• Maven / Ant dependency extraction
• Extraction of installed and used drivers
• Extraction of information about installed programming languages (already existing for Java)
• Extraction of provenance and comments from version control systems
• IDE (software development environment) information extraction
• IDE project information extraction
• Dependency extraction form IDE
• Include the TIMBUS Extractors as modules to enable the extraction of business activity context information