Title: Data Stewardship
Tags: Citation Preservation maDMP RDMServices/Certification FAIR Repositories/Visibility DMP OAIS Repositories/VRE Legal CMP

Q: FAIR / Findable (4)
A: F1. (Meta)data are assigned a globally unique and persistent identifier
F2. Data are described with rich metadata.
F3. Metadata clearly and explicitly include the identifier of the data they describe.
F4. (Meta)data are registered or indexed in a searchable resource.

Q: FAIR / Accessible (4)
A: A1. (Meta)data are retrievable by their identifier using a standardised communications protocol.
A1.1 The protocol is open, free and universally implementable.
A1.2 The protocol allows for an authentication and authorisation procedure, where necessary.
A2. Metadata are accessible, even when the data is no longer available.

Q: FAIR / A1.1 The protocol is open, free, and universally implementable
A: “Anyone with a computer and an internet connection can access at least the metadata”
- open: specification is known to anyone
- free: free of charge
- use APIs, not only "click to download"

Q: FAIR / A1.2 The Protocol allows for authentication and authorisation
A: Access can be
- open (everyone)
- shared/restricted (a selected group)
- closed (only the owner)
FAIR data does not need to be open.

Q: FAIR / Interoperable (3)
A: I1. (Meta)data use a formal, accessible, shared and broadly applicable language for knowledge representation.
I2. (Meta)data use vocabularies that follow FAIR principles.
I3. (Meta)data include qualified references to other (Meta)data.

Q: FAIR / I1. (Meta)data use a formal, accessible, shared, and broadly applicable
language for knowledge representation (3)
A: “Data that should be readable for machines without the need for specialised or ad hoc algorithms,
translators, or mappings”
Use
- common formats (RDF, JSON, CSV + README)
- well defined and described data models
- known representations

Q: FAIR / I3. (Meta)data include qualified references to other (meta)data. (3, examples)
A: - "is derived from", "was produced using"...
- Standard relations in DataCite
- use PIDs

Q: FAIR / Reusable (4)
A: R1 (Meta)data are richly described with a plurality of accurate and relevant attributes.
R1.1 (Meta)data are released with a clear and accessible data usage license.
R1.2 (Meta)data are associated with detailed provenance.
R1.3 (Meta)data meet domain-relevant community standards.

Q: FAIR / R1.2 (Meta)data are associated with detailed provenance.
A: - Describes origin of data: Who?, What?, When?, How?
- e.g. PROV-O, the PROV Ontology: Agent - Entity - Activity

Q: FAIR / Machine Actionability (Definition)
A: The capacity of computational systems to find, access, interoperate, and reuse data with none or minimal human intervention.

Q: Preservation / What are the three levels of digital preservation?
A: 1. Physical (bit-stream): bit rot, keep the bits
2. Logical (accessibility): open files, run programs
3. Semantic (information object): ensure we can understand and interpret the data correctly

Q: Preservation / Logical preservation / Examples of threats
A: - changes in environment to access  the digital object: program to open a file, OS (version) for a program, HW for OS
- embedded objects are no longer accessible

Q: Preservation / Semantic layer preservation / possible threats
A: How to interpret data / information in the objects.
- terminology changes
- concept changes
- transformations (currencies...)
- provenance, actions applied to objects
- context of the object

Q: Preservation / Purpose of digital preservation
A: The goal of Digital Preservation is to maintain digital objects accessible and usable in an authentic manner for a long term into the future.

Q: Preservation / Means of physical preservation (7)
A: - redundant storage: Lockss (lots of copies keep stuff safe), cloud storage, distribution
- transfer to current storage systems
- different technologies / platforms / production batches
- controlled storage conditions
- regular maintenance (media, storage devices, access devices)
- access and security
- error detection and recovery, disaster planning

Q: Preservation / Main considerations in bit-level preservation /5)
A: - cost (acquisition, energy, maintenance)
- logistic challenges
- durability of the technology
- distribution and trust
- for redundance / cloud storage: copyright, copy protection, how to reference distributed objects

Q: Preservation / Strategies for logical preservation (11 items)
A: - Technology Museum
- Migration
- Emulation
- Standardization
- Data / Information Extraction
- Encapsulation
- Universal Computing Platform
- Backwards Compatibility / Version Migration
- Viewer
- Non-digital (paper, microfilm...)
- Data Recovery, Data Archeology

Q: Preservation / Logical preservation / Technology Museum (4 pro / 3 con)
A: + maintains full functionality
+ time buffer to develop better strategies
+ needs detailed documentation, which is good
+ only suitable for certain types of objects
- economical infeasibility (spare parts)
- museum needs to be huge
- know-how for all platforms and software required

Q: Preservation / Logical preservation / Migration ( 3 pro / 2 con)
A: Transformation into a different format (on-demand = Viewer)
+ widely used
+ possible comparison at migration time
+ resulting objects are always accessible
- undesired changes during migration
- needs to be repeated

Q: Preservation /  Logical preservation / Emulation (4 pro / 6 con)
A: Emulation of HW or SW
+ widely used
+ many emulators available
+ can preserve complete functionality
+ doesn't change the digital object
- does not change the digital object
- complex technology, research needed
- requires detailed documentation
- requires experience how to interact with the system
- emulators must be migrated
- potentially error prone

Q: Preservation / Compare emulation and migration
A: - conceptually identical
- change is in the viewpath
- same advantages / disadvantages and characteristics
- both dont guarantee identical rendering / performance of digital objects
- many variants (viewer, virtualization)
- need to be evaluated in the same way

Q: Preservation / Logical preservation / Standardization (3 pro / 3 con)
A: Use open or de-facto standards
+ simpliefies preservation process
+ many tools available
+ easier to build tools
- standardization effort
- loss at conversion time
- not all object types can be standardized

Q: Preservation / Logical preservation / Open vs proprietary file formats
A: Problems with proprietary formats:
- lack of documentation
- licenses (which may change), patent rules
- restrictions for use and modifications
Sometimes proprietary may be better: can be richer / more specialized, lossy conversion to open format, it's easier to edit in the future

Q: Preservation / Logical preservation / Limiting accepted formats (1 pro / 4 con)
A: Similar to standardization.
+ reduces the challenge
- does not solve the problem
- limits types of objects
- conversion loss
- requires control of formats (could be circumvented)

Q: Preservation / Data / Information Extraction (3 pro / 3 con)
A: Creates an abstract representation (e.g. XML)
+ independent of infrastructure
+ many tools
+ easier to develop in the future
- high development effort for abstraction tools
- limited functionality of tools that interpret the information, many aspects not preservable
- can't apply to all types of objects

Q: Preservation / Logical preservation / Encapsulation (2 pro / 2 con)
A: Onion: add representation information (metadata, software,...) to the object
+ simplifies search for preservation solution
+ compatible with most other strategies
- does not solve the problem
- may in the end still not work

Q: Preservation / Logical preservation / Universal Computing Platform (3 pro / 4 con)
A: Abstract virtual machine, to be implemented on other platforms, e.g. IBM UVC
+ works for documents and software
+ platform standardization, reduces development effort
+ solution can be tested while being developed
- very complex
- high effort for preservation
- requires cooperation of the producers of information
- high risk of loosing aspects of information

Q: Preservation / Logical preservation / Backwards Compatibility and Version Migration (3 pro / 3 con)
A: Current software reads old versions and migrates them.
+ usually available
+ creates time buffer for more permanent solutions
+ sometimes equal or better functionality
- will it work for a long time?
- unwanted changes (errors)
- no guarantee from producer of the software

Q: Preservation / Logical preservation / Viewer (3 pro / 4 con)
A: Interpretation by viewer software = migration on demand
+ original data stream unchanged
+ no continuous migration
+ no cumulative errors
- limited functionality of viewer
- time delay for viewer development
- hard to maintain the viewer for the long term
- hard to evaluate whether viewer is correct

Q: Preservation / Logical preservation / Non-digital strategies (4 pro / 4 con)
A: Paper, microfilm...
+ readable form
+ high stability
+ coding of digital data is possible
+ lots of experience in handling analog data carriers
- loosing functionality and advantage of digital technology
- not applicable for all objects
- possibly high costs for preservation the data carrier material, low storage density
- can also be buggy (e.g. XEROX bug)

Q: Preservation / Logical preservation / Data recovery and Archeology (1 pro / 3 con)
A: Bit-stream analysis to interpret the data, digital forensics
+ can recover "lost" information
- no guarantee of success, hard to predict if it will work
- can be close to "guessing"
- extremely high costs

Q: Preservation / Steps in logical preservation planning
A: - identify objects at risk
- identify what properties to preserve
- decide on (mix of) methods (standardization, emulation, migration, museum,...)
- identify tools
- document, verify, monitor

Q: Preservation /  Semantic preservation / Threats (4)
A: - meaning of terms
- measurement scales, sensor sensitivites,...
- intpretation of facts (e.g. drunk driving)
- context of objects (purpose, limitations, cultural context, related objects,...)

Q: Preservation / Semantic preservation / Approaches (6)
A: - semantic enrichment
- metadata
- migration at semantic level
- documentation of context
- tracing of metadata
- documentation of intended meaning / interpretation

Q: Preservation / File formats / Characeristics and problems
A: - file extensions: may be tampered with, not unique, insufficient granularity
- internal: magic number, signature
- formats vs format profiles: many different versions of PDF, TIFF,...

Q: Preservation / Problems with MIME types in preservation (2)
A: - insufficient depth of detail
- insufficient granularity

Q: Preservation / File Format Registries (what is it, examples)
A: Knowledge base of file format representation.
- properties, how to read them, semantics
- supporting software
- unification of vocabulary
- access point to information of formats through a common API
- Content: descriptive info, identifiers, relationships between formats, technical environment, references, risk factors
- e.g. PRONOM, FileExt

Q: Preservation / Use Cases for File Format Registries (6)
A: - Identification
- Validation
- Transformation
- Characterization (properties)
- Risk assessment (obsolescence)
- Delivery (rendering the file)

Q: Preservation / File Format Identification Tools (3)
A: - DROID: uses PRONOM
- JHove
- FITS (File Information Toolset): comprises the above

Q: Preservation / Validation / Validity and Well-Formedness
A: Well-formed: the digital object meets the syntactic requirements of it's format
Valid: the digital object is well-formed and meets additional semantic-level requirements

Q: Preservation / Content Profiling
A: - Used for decision support.
- Characterize, aggregate, analyse, report important content features (e.g. statistics of file formats and their versions, sizes...).
- Watch developments to get notified about risks and opportunities.

Q: Preservation / Challenges of scale in preservation
A: Data amount vs depth of analysis

Q: Preservation / C3PO - Clever, Crafty, Content Profiling of Objects
A: Tool developed at TU Wien
- Reads and analyzes information from FITS
- Supports large scale database solutions
- rulebased conflict resolution for characterization metadata (from different tools)

Q: DMP / Why do we need Data Management Plans (3)
A: - Reproducibility of research.
- They are an awareness tool.
- Required by funders and institutions.

Q: DMP / What is a DMP?
A: Formal document which outlines what you do with your data during and after you complete your research.
It is an awareness tool.
It makes you think of
- what data you will use and where you get it from
- what infrastructure, software, licenses are needed
- what will be the output of your research
- how you will share your research outputs
DMP is a living document

Q: DMP / Parts of DMP (as in FWF template)
A: I. General information
II. Data characteristics
III. Documentation and Data Quality
IV. Data Storage, Sharing and Long-Term Preservation
V. Legal and Ethical Aspects

Q: DMP / I. General Information
A: 1. Administrative information
- Name, e-mail ORCID of principal investigator
- project name, project number
- grant information
- version of DMP
2. RDM responsibilities and resources
- Assign roles and RDM-tasks.
- Estimate resources for RDM and how costs will be covered

Q: DMP / II. Data Characteristics (5)
A: - Type of data (text, software, models, audio...)
- Source of data (human observation, field instruments,... collected or reused)
- Volume of data
- Data and file formats: non-proprietary, used within the community
- Describe reused (source, license) and produced data

Q: DMP / III. Documentation and Data Quality (3)
A: Metadata
- helps understand and interpret data
- provides details about experiment setup
- helps discover new data
Use discipline specific metadata standards. Find standards in FAIRsharing or re3data.
Data organisation
- clear folder structure
- naming convention
- YYYYMMDD
- version control
Documentation
- README text file
- provide together with published data
- methodologies, names, algorithms, lab journal, lab notebook

Q: DMP / III. Documentation and Data Quality / Means of quality control (6)
A: - repeat samples / measurements
- calibration
- standardised data capture
- entry validation
- peer review
- controlled vocabularies
- ...

Q: DMP / IV. Data storage, sharing and long-term preservation / Main considerations (7)
A: Preservation and managing can be done on one system (newer approach).
- What has to be shared / kept?
- What can't be recreated?
- What must be destroyed?
- Where will the data be deposited?
- Embargo periods?
- Cost? Who will pay?
- Which license to use?

Q: DMP / IV. Finding a repository (hierarchy)
A: 1. Domain specific
2. Institutional
3. Search a registry to find one (e.g. re3data.org)
4. Catch-all repository (e.g. zenodo)

Q: DMP / IV. Data storage and backup during the research process (3)
A: - Where to store?
- Data security considerations
- Sensitive data (personal, political, trade secrets...) and additional security measures

Q: DMP / IV. Data sharing and long-term preservation (4)
A: - At least 10 years
- Choose a repository
- Provide persistent identifiers
- Choose a license

Q: DMP / V. Legal and Ethical Aspects - Creative Commons Licenses
A: - CC-0: public domain
- CC-BY: Attribution
- CC-BY-SA: derived work must carry the same license
- CC-BY-ND: no changes
- CC-BY-NC: no commercial use

Q: DMP / V. Legal and Ethical Aspects - Software Licenses
A: Apache, MIT, GNU, BSD
https://choosealicense.com

Q: maDMP / downsides of manual DMPs
A: - manually created text documents
- often vague
- depend on human factor (scrupulousness, awareness)
- considered as bureaucracy

Q: maDMP / Elements of Automated Data Management Workflow (7)
A: picture on slide 7
- start DMP
- specify size and type
- get cost
- get storage
- get license
- review
- submit to funder

Q: maDMP / Requirements (3)
A: - common data model
- well-defined workflows
- data management infrastructure (systems and services implementing the workflows)

Q: maDMP / Scoping maDMPs in DMP Common Standards WG - 5 steps
A: - 1st consultation - define scope
- 2nd consultation - identify models
- Proof of concept tools
- BPMN processes
- Model development

Q: maDMP / Scoping - 1st consultation
A: - identify stakeholders at each lifecycle stage, which information they provide and expect

Q: maDMP / Scoping - 2nd consultation
A: - How are specific requirements modeled?
- Which fields do we need?
- Which models exist?

Q: maDMP / Scoping - Proof of concept tools
A: - Provide minimum input
- Import as much as possible from existing systems

Q: maDMP / Planning phase
A: Get estimations and recommendations

Q: maDMP / Project and post-project phases
A: update DMP with real information by re-using (linking) information provided elsewhere

Q: maDMP / What can we automate
A: - Fetch data from external services like administrative info, find a repository, get metadata about things in the repository, preservation details
- help estimate costs / resources
- data sharing, access and security details
- software and data preservation details
Not automatable: Roles & responsibilites, licenses & policies for reuse, ethical and privacy questions.

Q: maDMP / Processes (BPMN)
A: identify
- tasks to be performed by the stakeholders
- systems needed
- concepts to be developed or agreed upon

Q: maDMP / Standards / DublinCore
A: Core set of elements describing digital and physical resources.
- video, image, web page, book...
- e.g. Contributor, Creator, Date, Description, Format...

Q: maDMP / Standards / DCAT
A: DCAT is an RDF vocabulary for interoperability between data catalogues on the web.
- potential use case: federated search
- no serialization enforced
- resues other vocabularies

Q: maDMP / What's defined in the Application Profile for maDMPs
A: - adds further constraints to the model (cardinalities, sub-classes, further vocabularies)
- reuses classes from DCAT and Dublin Core
- adds further terms

Q: maDMP / Benefits of RDM infrastructure at TU Wien
A: - tool to quickly create DMPs
- once-only: ask a question only once
- reuse information from DMPs internally

Q: maDMP / Ten principles for maDMP - Who are the stakeholders? (9)
A: 1. Funders
2. Ethics review
3. Legal experts
4. Researchers
5. Publishers
6. Repository operators
7. Infrastructure providers
8. Research support staff
9. Instiutional administrators

Q: maDMP / Ten principles for maDMP
A: 1. Integrate DMPs with the workflows of all stakeholders in the research data ecosystem.
2. Allow automated systems to act on behalf of stakeholders.
3. Make policies (also) for machines, not just for people.
4. Describe - for both machines and humans - the components of the data management ecosystem.
5. Use PIDs and controlled vocabularies.
6. Follow a common data model for maDMPs.
7. Make DMPs available for human and machine consumption.
8. Support data management evaluation and monitoring.
9. Make DMPs updatable, living, versioned documents.
10. Make DMPs publicly available.

Q: maDMP / Ten principles / 1. Integrate DMPs with the workflows of all stakeholders
A: - Authoring should be collaborative.
- Multiple stakeholders consume information from DMPs and act upon it.
- Take organizational and technical measures (e.g. notification system) to make data management tasks routine and not ad hoc.

Q: maDMP / Ten principles / 2. Allow automated systems to act on behalf of
stakeholders
A: Reduce human interaction, integrate systems to fetch information from appropriate sources, automate tasks.
- Collate administrative data
- Cost estimation
- License selection
- Storage booking
- Data deposit
- Validation and compliance
Notify when human intervention is needed.

Q: maDMP / Ten principles / 3. Make policies (also) for machines, not just for people.
A: Policies relate to all kinds of norms (guidelines, laws, contracts, policies...).
Make them (partially) machine-actionable by composing them of or including machine-actionable elements.

Q: maDMP / Ten principles / 4. Describe - for both machines and humans - the
components of the data management ecosystem
A: Make it easy to find an appropriate repository.
If information on the repository is provided in a common and machine-actionable way (APIs), services that can suggest a repository based on the DMP are possible.
Repository providers could benefit from standardized information in the DMP for ingest and maintenance of the data.

Q: maDMP / Ten principles / 5. Use PIDs and controlled vocabularies
A: Traditional DMPs use free-form text fields.
Use PIDs and controlled vocabularies whenever possible.

Q: maDMP / Ten principles / 6. Follow a common data model for DMPs
A: - Allows information exchange between stakeholders and interoperability of tools.
- Should be modular with a core and extensions, reuse standards and controlled vocabularies.
- Relates just to the external interface of the systems involved.
- RDA DMP Common Standards WG

Q: maDMP / Ten principles / 7. Make DMPs available for human and machine consumption
A: - Differences between versions should be assessable by humans and machines
- Allow for notification systems
- Allow for aggregation on different levels of granularity
- (parts of the) DMP should be open

Q: maDMP / Ten principles / 8. Support data management evaluation and monitoring
A: - support funders and policy makers in compliance monitoring
- automation possible where policies are machine-actionable
- do not constrain researchers in their methodology!

Q: maDMP / Ten principles / 9. Make DMPs updatable, living, versioned documents
A: - Changes should trigger notifications at configurable levels of granularity.
- Updates can also happen automatically (e.g. enter timestamp + PID upon data deposit in the repo)

Q: maDMP / Ten principles / 10. Make DMPs publicly available
A: - Allows for streamlining interactions, aggregation, information mining.
- Sharing can also be delayed, within limited contexts or in part where necessary. The reasons for limitations should be stated in a machine-actionable manner.

Q: Reasons to cite data
A: -- prevent scientific misconduct (extrinsic)
- give credit (altruistic)
+ show solid basis (egoistic)
++ enable reproducibility, re-use (extrinsic, altruistic and egoistic)
+++ because it's the proper way, speeds up scientific discovery and efficiency

Q: Why does reproducibility need identification of data?
A: Reproducibility needs transparency, which needs documentation, which provides context, which requires citation, which requires identification.

Q: Citation / Joint Declaration of Data Citation Principles (8)
A: 1. Importance: same as publications
2. Credit and Attribution: to all contributors, including legal attribution
3. Evidence: wherever a claim relies upon data
4. Unique Identification: persistent, globally unique, machine-actionable identifier
5. Access: to data, metadata, documentation and code for humans and machines; sufficient to make informed use of the data
6. Persistence: identifiers and metadata should persist beyond the lifespan of the data they describe
7. Specificity and Verifiability: specificity on the exact time slice, version, granular portion of the data; information on provenance and fixity (hash) for verification
8. Interoperability and Flexibility: flexible enough to accomodate the different domains and communities; standardized enough to be interoperable across communities

Q: Standard Elements of a Data Citation
A: - classical: author, date, edition, publisher version
- specific: feature names, resource types, hash, PID, location

Q: Definition of an identifier
A: Symbol that uniquely identifies an object.
- references the location
- provides metadata
- can be resolved

Q: Citation / Identifiers for Digital Objects (examples)
A: URI (encompasses URL and URN): not necessarily resolvable
Delegating methods:
- Handle system (basis for others)
- DOI
- PURL
- ARK

Q: PURL
A: - Persistent URL
- HTTP forwarding
- no metadata
- free
- can be self-hosted

Q: URI´
A: Uniform Resource Identifier (can include location)
Cool URIs don't change!

Q: URN
A: - Naming scheme for URNs: <NID>:<NSS>, e.g. urn:isbn:0451450523
- Global scope
- Global uniqueness
- Persistence
- Scalabilit
- Legacy Support
- Extensibility
- Independecne
- Resolution via handle system

Q: Citation / Handle
A: - Distributed persistent naming scheme
- Conforms to URN framework
- Used by most identifier systems
- <Handle Naming Authority> / <Handle Local Name>, e.g. 10.1145/january2013-burns
- Resolution via https://hdl.handle.net

Q: Citation / Handle Resolution
A: Global Handle Registry > Local Handle Service > Resource Server

Q: DOI
A: - International DOI Foundation (IDF)
- Relies on handle
- Actionable, interoperable, persistent link
- ISO 26324
- <Resolver Service>/<Prefix>/<Suffix>, e.g. http://dx.doi.org/10.1016/S0921-4526(00)00753-5
- Resource can be anything physical, digital, abstract)
- Resolver services lead to landing page
- Suffix unique within the prefix
- Suffix is case insensitive
- UTF-8
- Don't use semantics!
- DOI Kernel Metadata
- DOI Data Dictionary
- Can deliver formatted citations
- not free

Q: Citation / How to get a DOI
A: - Request an account at a DOI registration agency (DataCite, CrossRef...)
- Pay the fee
- Get your prefix and start minting suffixes

Q: DataCite
A: - Registration Agency for DOIs
- Non-profit membership organization
- Aims: easier access to research and data, support data archiving

Q: Compare DOI and Handle
A: DOI uses handle and adds:
- metadata (even after data deletion)
- consistency of citations
- semantic interoperability
- identifiaction of intellectual property entities

Q: Archival Resource Key (ARK)
A: - URL with long-term support
- Maintained by California Digital Library
- Identifies objects of any type (even people)
- <Name Mapping Authority>/<Label>/<NAAN>/<Name>/<Qualifier>, e.g. http://example.org/ark:/13030/654xz321/s3/f8.05v.tiff
- Can be self-hosted
- free

Q: Compare ARK and DOI
A: ARK
- subset facilities
- deletable
- free
- good at early stages of project life cycle
DOI
- metadata not deletable
- higher reputation
- commercial

Q: ORCID
A: - for people
- resolves name ambiguity
- links research activies and output

Q: Persistent Identifiers for Organizations
A: - GRID: Global Research Identifier Database
- ROR: Research Organization Registry
- Ringgold

Q: Requirements in Data Citation
A: - data is dynamic (additions, deletions, error corrections...)
- citing subsets (how to exactly define the subset)
- stability across technology changes (migration to new database)
- machine-actionable, not just machine-readable
- scalable to very large and highly dynamic datasets

Q: RDA WG Data Citation - Recommendations (14, 4 groups)
A: Preparing data & query store
R1: Data Versioning
R2: Timestamping
R3: Query Store
When data should be persisted
R4: Query Uniqueness
R5: Stable Sorting
R6: Result Set Verification
R7: Query Timestamping
R8: Query PID
R9: Store Query
R10: Citation Text
When resolving a PID
R11: Landing Page
R12: Machine Actionability
Upon Modifications to the data infrastructure
R13: Technology Migration
R14: Migration Verification

Q: WG DC / R1: Data Versioning
A: - no in-place updates or deletes
- no need to keep versions that were never read

Q: WG DC / R2: Data Timestamping
A: - Granularity depends on change frequency and tracking requirements and system

Q: WG DC / R1, 2: Timestamping vs Semantic Versioning
A: - SemVer is only an assertion ont he state of data at certain points in time, may not be stable, unexpected side-effects
- What is a "minor" change?
- SemVer only in addition to timestamp!

Q: WG DC / R1, 2: Implementations
A: - history table (stable API, high storage requirements)
- integrated (API changes, minimal storage footprint)
- hybrid (history table only for deleted records)
- git-based: store script parameters in metadata file and assign a PID

Q: WG DC / R3: Query Store
A: Stores queries + metadata for re-execution
- queries original and re-written (R4 - uniqueness, R5 - stable sorting), potentially migrated (R13)
- query parameters + system settings
- execution metadata
- hash keys (R4, R6
- PIDs (R8)
- citation text (R10)

Q: WG DC / R4: Query Uniqueness
A: - re-write to normalized form + checksum to identify identical queries
- best-effort solution
- query builder workbench can help
re-writing includes
- standardization / normalization (incl case, spelling)
- include versioning / timestamps
- unique sorting

Q: WG DC / R5: Stable Sorting
A: - sorting should be unambiguous and reproducible
- e.g. use id

Q: WG DC / R6: Result Set Verification
A: - Compute fixity information (hash / checksum)

Q: WG DC / R7: Query Timestamping
A: - based on last update to the database (most simple) or the selection of data affected by the query or the query execution time (privacy concerns?)

Q: WG DC / R8: Query PID
A: - assign a new PID if query is new or result set for identical query is different due to changes in the data
- otherwise: return existing PID

Q: WG DC / R9: Store the Query
A: - store query + metadata
- not necessary all queries, if there is a staging area

Q: WG DC / R10: Create Citation Texts
A: - in the format prevalent in the designated community
- include the PID
- 2 PIDs: the database and it's holder + the subset based on the query
- can deliver human-readable and machine-readable citations
- citation models can be learned

Q: WG DC / R11: Landing Page
A: - resolve PIDs to a human readable landing page providing the subset and metadata incl a link to the superset and citation text

Q: WG DC / R12: Machine-Actionability
A: - Provide an API / machine-actionable landing page to access metadata and re-execute queries.
- There can still be authentication etc.
- Allows meta-studies, monitoring

Q: WG DC / R13: Technology Migration
A: When data is migrated also migrate the queries and fixity information.
Also applies upon schema modification.

Q: WG DC / R14: Migration Verification
A: - Verify successful data and query migration.
- If verification via hash not possible any more: pairwise comparison of subset elements.

Q: WG DC Recommendations: Summarize benefits
A: - identification, retrieval and citation of precise subset with minimal storage overhead
- can retrieve data as it existed or the current view
- can cite an empty set
- provides provenance data
- collects information on data usage
- metadata support verification of correctness and authenticity
- works for all types of data

Q: WG DC Recommendations - May data be deleted?
A: Yes, if the policies allow.
Queries then possibly not re-executable against the original timestamp.

Q: What is Long Tail Research Data
A: The fewer big data sets are usually better organized, more often used and cited.
The many smaller data sets are less well organized and often not standardised and not in dedicated infrastructure (the "long tail").

Q: What is OAIS?
A: Open Archival Information System is a reference model
- a framework to understand the relationship between significant entities in an environment
- a framework for the development of consistent standards or specifications to support this environment
- a reference model based on a small number of unified concepts
- an abstraction of the core concepts, their relationships and interfaces within as well as external to the framework
- ISO 14721:2012
- Open: freely available, developed in a public process
- Information: any knowledge that can be exchanged, independent of form, data are a representation
- Archival Information System: HW, SW and people responsible for the acquisition, preservation and dissemination of information

Q: Purpose, Scope and Applicability of OAIS
A: - long-term digital information preservation (i.e. long enough to be concerned about changing technologies)
- set of minimial responsibilites to distinguish an OAIS from other archives
- basis for development of standards
- applicable to all long-term archives and organizations / individuals concerned with long-term preservation
- does not specify an implementation

Q: OAIS / Model view (3 main actors)
A: Producer: provides information to be preserved
Management: set OAIS policy
Consumer: find and acquire preserved information from the OAIS

Q: OAIS Information Definition
A: "Data Object" is interpreted using its "Representation Information" to yield the "Information Object

Q: OAIS Information Package Definition
A: Conceptual container:
- Content Information
- Preservation Description Information (PDI)
- + descriptive information (Packaging Information)

Q: Variants of Information Packages in OAIS (3)
A: - SIP: Submission Information Package - negotiated between producer and OAIS, sent to OAIS by producer
- AIP: Archival Information Package - used for preservation (includes complete set of PDI)
- DIP: Dissemination Information Package - includes part or all of one or more AIP, sent to consumer by OAIS

Q: OAIS / Functional Entities of an OAIS (6)
A: - Ingest: accept SIPs and prepare contents for storage and management within the archive
- Archival Storage: store, maintain and retrieve AIPs
- Data Management: populate, maintain and access descriptive information which identifies and documents archive holdings and internal archive administrative data
- Administration: manage the overall operation of the archive system
- Preservation Planning: monitor the environment of the OAIS and provide recommendations to keep information accessible to the designated user community over the long term
- Access: support consumers in determining existence, description, location and availability of information in the OAIS; allow consumers to request and receive information products

Q: OAIS / Ingest Data Functions (5)
A: - Receive Submissions: staging area, confirm acceptance
- Quality Assurance: validate submission (identity, logs, checksums, format, virus check > different options what to do)
- Generate AIP: SIP > AIP (transformation, migration, transcoding), forward to audit (Administration)
- Generate Descriptive Information: collect / extract descriptive information on AIP
- Coordinate Updates: Transfer AIPs to Archival Storage, upon confirmation Descriptive Information goes to Data Management
- Important here: who is liable for what (Consumer / OAIS)?

Q: OAIS / Archival Storage Functions (6)
A: - Receive Data: accept AIP,  decide on location, confirm
- Manage Storage Hierarchy: according to policies, monitor operations
- Replace Media
- Error Checking
- Disaster Recovery
- Provide Data: copies of AIPs for Access

Q: OAIS / Data Management Functions (4)
A: - Administer Database: Integrity of DB for Descriptive Information and system information
- Perform Queries: process queries from Access
- Generate Reports: for Ingest, Access, Administration
- Receive DB Updates: for Management DB;  Ingest: new AIPs; Administration: updates

Q: OAIS / Preservation Planning Functions
A: - Monitor Designated Community: Producer, Consumer
- Monitor Technology: HW, SW, Formats
- Develop Preservation Strategies and Standards
- Develop Packaging Designs and Migration Plans: migration paths and tools; create PDI

Q: OAIS / Define Digital Migration
A: Transfer of digital information within the OAIS, while intending to preserve it.
- Focus on preservation of the full information content
- New information implementation replaces the old
- OAIS has full control and responsibility over all aspects of the transfer

Q: OAIS / Motivators for Migration (4)
A: - media decay
- increased cost effectiveness
- new user/consumer service requirements
- proprietary software evolution

Q: Challenges in making databases available in a repository
A: 1. Separation of concerns: data stewards receive databases without semantic understanding of the data
2. Project phases
3. FAIR is a challenge in preserving databases
4. Reproducibility: re-execution of a query is often neglected
5. Versioning

Q: What is Data Visiting
A: - Data stays under the control of the owner
- Allow consumers (analysts, algorithms) to come to the date. Allow maximum usage of data, but ensure proper usage of date.
- Monitoring of processes and interaction during the visits.
- Prevent accidental leakage and intentional data breach.

Q: What is a Virtual Research Environment?
A: - web-based, accessible
- stores and manages data
- computation on the data
- collaboration tools

Q: Measures to safeguard a VRE (3)
A: - Technical: Safeguard data against technical threats and design flaws, provide a highly controlled VRE.
- Organizational: Identify researchers, research questions, guide all involved people through well defined processes on need-to-know basis
- Legal: Build trust with data providers, provide legal framework to discourage information sharing, provide foundation for legal steps after leaks.

Q: VRE / Technical Measures / Homomorphic Encryption
A: - not working sufficiently for many settings.
- slow

Q: VRE / Technical Measures / Secure Enclave
A: Provide hardware isolation and memory encryption, isolating application code and data from untrusted hardware. Many manufacturers of CPUs offer secure enclave support for consumer electronics.

Q: VRE / Technical Measures / Air-Gap Isolation (five safe dimensions)
A: 1. Safe projects: auditability and review processes
2. Safe people: identify individuals, require them to sign legal binding terms of use
3. Safe data: ensure de-identification and access capabilites with respect to the research questions formulated
4. Safe settings: address the necessity of security and transparency to achieve trust with the public and data owners
5. Safe outputs: ensure only approved, aggregated research results can be exported.

Q: VRE / OSSDIP / Main Architecture
A: Analyst and Owner have VPN access to Analyst-VM / Owner-VM
These are Air-Gapped from the Data Node.
Ingress / Egress via Data-Owner-VM, then brief connection to Data Node by administrator.
Requests from Analyst:
- identification
- extract the requested subset via query
- potentially fingerprint the subset
- provision the Analyst-VM with the subset and a Remote Desktop-VM
- provide pre-approved tools

Q: VRE / Legal Measures
A: Trusted computing infrastructure for Data Owners
Conditions of use for Analysts
- prohibit download
- prohibit de-anonymization
- NDA
- agree to extensive monitoring
Information in cause of leaks
- personal information
- evidence of misuse
- evidence of relationship between leaked dataset and provided dataset

Q: Compare Traditional Repositories with Database Repositories
A: Representation: file storage / database engine
Storage: file system / database
Versioning: snapshots / temporal tables
Identification: record / query or subset
Concerns: researcher / database expert
Use-case: deposit / continuous work

Q: Main two DOI Registration Bodies
A: DataCite: supported by public sector, national desk at TU Wien
Crossref: supported by private sector (e.g. Elsevier)

Q: DOI - Most important metadata
A: Mandatory
- Identifier, Creator, Title, Publisher, PublicationYear, ResourceType
Optional
Many including Rights, which is mandatory to be FAIR.

Q: What is a good DOI
A: - no semantics
- short
- no optically ambiguous or problematic characters (URL)
- easy to generate
- easy to read and write also by humans

Q: Repositories / Interoperability Protocols (2)
A: OAI-PMH: Open Archive Initiative Protocol for Metadata Harvesting
- ~25 years old
- XML based
- query this to discover repository contents
- only for metadata
- not for depositing
- provide an endpoint for this!
SWORD: Simple Web-service Offering Repository Deposit
- deposit to multiple repos at once
- deposit by third party systems

Q: OAI-PMH / main characteristics
A: - data remains within a repository
- harvester aggregates the metadata
- useful to aggregate data
- default metadata standard: Dublin Core, others possible

Q: OpenAIRE
A: Open Access Infrastructure for Research in Europe
- promotes Open Access to become independent of the publishers
- network of experts
- has technical infrastructure: harvests research output, data, publications, links them, monitors, developed Zenodo
- for compliance repos must have an OAI-PMH endpoint and provide metadata in DataCite format
- it can be used instead of DataCite or together with DataCite

Q: Repositories / Scholix
A: Framework for Scholarly Link Exchange
- Developed at RDA
- exchanges information about links between publications and data
- connects journals, data centers, repositories and others
- has a link metadata schema
- organisation-to-organisation exchange framework
- connects the different hubs such as Crossref, DataCite, OpenAIRE
- to contribute feed your link to a Scholix hub

Q: Repositories / Structure of a Scholix Link
A: Source Object (PID, Object Type, Object Subtype, Title, Author,...)
Target Object
Publication Date
Link publisher
Relationship Type
Inverse Relationship Type

Q: Repositories / DCAT
A: W3C Data Catalog Vocabulary
- RDF vocabulary for interoperability between data catalogues
- enables decentralized publishing
- facilitates federated dataset search
- most fields are optional
- no deployment method specified (e.g. RDF/SPARQL, HTML, RDF/XML, Turtle...)
- Mostly used in open governmental data repositories

Q: Repositories / DCAT Application Profile
A: A specification that adds additional constraints for open data in Europe.

Q: Repositories / Schema.org
A: Started by Google, Microsoft, Yahoo, Yandex to help indexing web pages.
Schema.org metadata can be embedded using microdata, RDFa or JSON-LD

Q: Repositories / Google Dataset Search
A: uses schema.org:Dataset
Google has an application profile

Q: Repositories / Repository registries (4)
A: - DOAR: Directory of Open Access Repositories (based on registration)
- ROAR: Registry of Open Access Repositories (autmatically harvested list)
- re3data.org (manual registration)
- FAIRsharing.org

Q: Legal / legal concepts with respect to data
A: - copyright law (authorship), creator (if not protected by copyright law)
- patent law (inventor)
- data protection law
- data security law
- competition law
- contract law
- labour law
- legal successorship

Q: Legal / Patent law
A: - protects inventor, idea, technology
- exclusive right, registration, fees
- 20 years protection

Q: Legal / Copyright law
A: - protects the author, work, intellectual creation (literature, science, art, databases, computer programmes)
- no regestration, no fees
- 70 years protection

Q: Legal / Protection for creators
A: Use licenses.
Especially for creators of datasets which might not be protected otherwise.

Q: Legal / rights in research data, protection of certain artifacts
A: - data protection, esp. GDPR for personal data
- licenses (software, dataagreements...)
Protection of certain artifacts:
- data: copyright and neighbouring rights, data protection law
- software: copyright
- datbases: right in the database
- data medium: ownership

Q: Legal / copyright in research data (where, where not?)
A: Data in the literal sense are hardly subject to copyright.
copyright possible:
- essays, articles, papers, monographs
- graphics, maps, tables with individual graphic design
- databases
- research software
- photographs, video recordings
usually no copyright:
- measurement data
- metadata
- results of a software simulation

Q: Legal / right holders in research data
A: Researchers, students usually transfer their rights to the university via contracts, funding agreements or exploitation rights.
Third parties may come in (data protection, exploitation rights, joint copyright).

Q: RDM / Steps to design an RDM solution for an institution
A: - consider size and governance structure of the institution
- establish a long term governance group
- be aware of existing infrastructure
- understand processes (Research Data Lifecycle Models)

Q: RDM / Research Data Lifecycle Models, their role
A: - describe roles of stakeholders
- help in tailoring services, identifying responsibilites, defining infrastructure
- not to be used by researchers
- e.g. UK Data Archive, Digital Curation Centre, University of Central Florida

Q: RDM /Components of a Research Data Management infrastructure
A: - RDM policy and strategy
- business plans and sustainability
- guidance, training, support
- data management planning
- managing active data
- data selection and handover
- data repositories
- data catalogues

Q: RDM Policy & Strategy - Components
A: Taboos > Principles > Policies > Rules (Regulations, Guidelines...)
- Taboo: something forbidden, negative assertion, should be only a few
- Principle: fundamental truth, positive assertion
- Policy: a course of action or principles, should be a single entity, stable, needs time for acceptance, frame for rule generation
- Rule: prescribe conduct / actions, can be lots, sometimes unclear, usually accepted, often imposed, subject to change

Q: RDM / Example Sections of a Policy
A: - Preamble
- Jurisdiction
- Intellectual Property Rights
- Handling Research Data
- Responsibilities, Rights, Duties
- Validity

Q: RDM Policy & Strategy - How to create
A: Strategy
- understand your current position and where you want to be
- map out a programme of activity to deliver infrastructure and services
Policy
- Draft a policy based on external drivers and local context to establish your core RDM principles
- Ratify the policy then undertake advocacy work and pilot studies to aid implementation
- Consult broadly to gain consensus and secure support

Q: RDM / Business Plans & Sustainability
A: Who pays for what?
- Identify the cost structure.
- Can use the Business Model Canvas, it is much shorter.
- Based on your strategy, develop a phased business plan covering projections for 3, 5 and 10 years
- Identify predicted costs and planned expenditures, together with an indication of the financial year in which expenditure will occur
- Consider whether any costs can be recouped, for example by charging for services
- Undertake a cost/benefits analysis to help make the case for investment
- Address sustainability issues and the associated long-term costs

Q: RDM / Guidance, training and support
A: Single Point of Information
- Website: Collate details of existing institutional support to provide a single, joined-up RDM guidance website
- Helpdesk: Coordinate the provision of support, either through a central helpdesk or well-signposted contacts
Trainings and Consultations
- Provide RDM training to support researchers and reskill support staff
- Offer more in-depth consultancy services
Best person for this: the data steward!

Q: RDM / What do data stewards do?
A: - Analyse data management needs
- Provide advice to researchers
- Train and inspire
- Help comply with funders’ and journals’ policies
- Develop faculty research data policies: roles and responsibilities of the different stakeholders
- Trusted point of contact for data management questions

Q: RDM / Data management planning - What does the DMP describe (6)
A: - how the data will be created
- how it will be documented
- who will be able to access it
- where it will be stored
- who will back it up
- whether (and how) it will be shared & preserved

Q: RDM / Data Mangement Planning / What if I need my own DMP Template (best if not)
A: Identify who and why will need this information.
Browse existing checklists for help.
Provide a template.
- questions
- guidance
- possible answers
Identify overlaps of your template (e.g. with Horizon 2020)
Test it and incorporate feedback.

Q: RDM / Data Management Planning besides DMPs
A: Design the whole data management process
- do you need different DMP phases?
- who receives the DMPs?
- who reviews them?
- who provides assistance?
Provide a reviewers’ guide: clear judgment criteria
Offer default data location: if you require people to deposit data and describe in a DMP, provide a place for doing that
Establish a policy
- make a use of DMPs obligatory
- consider incentives and penalties
Provide support
- tools
- examples
- trained staff for assistance in DMP creation
- related problem: Where do you find people with expertise?
Awareness and understanding
- offer training material
- organise workshops
- related problem: How to teach correct data management practices at schools…

Q: RDM / Managing Active Data
A: - Host your own or outsource (jurisdiction? sensitive data?
- Review data holdings and RDM practices to see if the current infrastructure and systems are sufficient
- Where appropriate, make a case for investment to provide additional research data storage
- Develop procedures for the allocation and management of research data storage
- Provide flexible RDM systems to support the creation, management and sharing of data that meet a diverse range of research contexts and needs

Q: RDM / Data selection and handover
A: What needs to be kept?
- Do you encourage/require specific data to be deposited?
- Into your own repository?
Data Management Infrastructure
- Integrate existing systems
- Seamless data flow
If establishing a repository, develop deposit agreements and high-level guidance.
Develop or use existing deposit tools to ease the process of handover.
Advocate the benefits of data deposit to encourage uptake.
Support research groups to develop guidance and offer input to decisions.

Q: RDM / Data Repositories - Selection of a Repository
A: - Automate repository recommendation: Set relevant filters automatically
- Reduce effort: Narrow down selection to relevant repositories
- Lower the expertise needed: Why should researchers deal with licenses if the funder/institutional policy regulates this anyway?

Q: RDM / Certification / Why certify?
A: - Will the repository exist in the future?
- How is data stored?
- Is a preservation plan in place?
- ...
Create trust.
- Build stakeholder confidence.
- Improve communication within the repository.
- Ensure transparency to the public.
- Enable comparison of repositories.
- Attract funding.

Q: RDM / Certification Standards (3)
A: - Core Trust Seal
- nestor (DIN 31644)
- ISO 16363

Q: RDM / Core Trust Seal - procedure
A: - Self assessment based on a checklist
- For guidance use online tools, documents and webinars.
- Review of the self assessment by two reviewers.
- Assessments are publically available.
- Renewal every three years

Q: RDM / Core Trust Seal - types of requirements (3)
A: - Organisational Infrastructure
- Digital Object Management
- Technology

Q: RDM / Core Trust Seal - Organisational Infrastructure requirements
A: R1. The repository has an explicit mission to provide access to and preserve data in its domain.
R3. The repository has a continuity plan to ensure ongoing access to and preservation of its holdings.
R5. The repository has adequate funding and sufficient numbers of qualified staff managed through a clear system of governance to effectively carry out the mission.

Q: RDM / Core Trust Seal - Digital Object Management requirements
A: R7. The repository guarantees the integrity and authenticity of the data.
R10. The repository assumes responsibility for long-term preservation and manages this function in a planned and documented way.
R12. Archiving takes place according to defined workflows from ingest to dissemination.
R13. The repository enables users to discover the data and refer to them in a persistent way through proper citation.

Q: RDM / Core Trust Seal - Technical requirements
A: R15. The repository functions on well-supported operating system and other core infrastructure software is using hardware and software technologies appropriate to service it provides to its Designated Community.
R16. The technical infrastructure of the repository provides for protection of the facility and its data, products, services, and users.

Q: RDM / nestor / overview
A: - 34 criteria (12 obligatory)
- auxiliary questions
- self-assessment
- 2 external reviewers

Q: RDM / ISO 16363 - overview
A: - uses OAIS terminology
- based on TRAC
- > 100 metrics
- full external auditing: first audit, improvement plan, surveillance audit
- re-certification

Q: FAIR / Tombstone pages
A: Metadata entry for deleted data. Relates to A2. Metadata are accessible, even when the data is no longer available.

Q: FAIR / I2. (Meta)data use vocabularies that follow the FAIR principles
A: - use controlled vocabularies (e.g. IATA) for each metadata entry
- reduces effort on data cleaning, spelling mistakes...

Q: FAIR / R1.3 (Meta)data meet domain relevant community standards
A: Which community?
Which standard?
If no standard exists: documentation + README