# 2.1. Objective and Approach to Data management

Innochain aims to promote and expand models for inter-
sector collaboration and feedback. The activities are 
positioned between research in academia and practice. 
Innochain aims furthermore to improve communication across 
disciplines by developing new interdisciplinary methods that 
integrate design led simulation. This position in the 
crossing between disciplines and sectors in the building
profession places Innochain and the 15 ESR projects 
in an interesting position, where not only the results, 
but as well the datasets, which are at the base of 
these, are of interest for a potentially large group 
of scientists and professionals. This group will naturally
 be widespread in terms of discipline, profession, 
location and cultural background. Hence the approach 
towards the publication of datasets has to be open, 
easy and sustainable. The access to datasets is as 
well of interest for reasons internal to Innochain, as
the publication of datasets will as well allow for 
synergies and pick up between the Innochain projects.

Innochain follows the internationally established FAIR
principles 1 s - findable, accessible, interoperable and 
reusable. Within the following chapters we are analysing
 the datasets, which are produced in Innochain and 
describe how the FAIR principles are implemented in the
project.

Innochain is taking place in a network of many
industrial and academic partners and the data used is in
 parts property of partners or beneficiaries, or could
disclose their business secrets to third parties. This 
data can hence not be shared with the public. The
same applies to data, which is of commercial interest 
or could lead to new intellectual property. Researchers
 need to be able to evaluate the results and base 
their own research on the knowledge and data generated 
in Innochain.

User generated analytics, if collected, will not be 
shared unless it is strictly necessary, and then only in
 a reduced and anonymised variant with all personal 
details and other sensitive information stripped.

Innochain places the final decision on which datasets to
publish into the hand of the researcher in charge. 
The Data Management Plan and the implementation of the
 related infrastructure within the projects provide 
guidelines and tools to decide, which and how datasets 
should be published.

# 2.2. Datasets in Innochain

The Innochain project, by its nature, covers a diverse
 range of projects with a diverse range of data 
requirements and data outputs. To put this into
context, some projects actively use photography as a 
documentation and analysis technique, while others rely 
exclusively on written software. All the expected data 
types are enumerated in the table below.

To note, specific data formats have specific archival 
needs and require different approaches to storage and 
retrieval. Nevertheless, an index of all data sets 
will be centralised and made available on the project’s 
webpage ( see S ection 3.1).

Given the diverse nature of archived material, it is 
difficult to estimate the final size of the complete 
dataset. For example, images and video recordings will
cover much more space than code repositories. We 
cautiously estimate to fit within a 100 GB - 1 TB
bracket.

The data is mostly generated by the ESRs themselves, 
and perhaps in some specific cases, is collected through
 questionnaires and other polling mechanisms from various 
case studies. The actual future usability of this data 
depends on the datasets themselves, but one can expect 
future experiments and research basing itself on the 
provided datasets, as well as offering the possibility 
of reproducing and verifying research results by other 
parties.

The following table classifies the main types of data 
that the researchers have either already produced or 
expect to produce as part of their individual 
projects. The three columns provide a summary of the 
actual data, the specific format file the data comes 
into and, most importantly its utility.

The utility of data is a classifier that we have 
defined by weighing several aspects, namely:

 * Does this data set help in reproducing research outputs? 

 

 * Can different experiments be built up on this data set? 

 

 * Does this data set contain sensitive information, and if yes, how easy is to anonymise it? 

 

 * Does this data set require proprietary software/hardware (not open source) to be used, and if yes, how easy is it to transform it into a format that would allow free and open source software to be used? 

 

The utility column provides a summary of the above, 
which has been defined in collaboration with a 
representative cross section of the researchers involved 
in the Innochain project.

We will prioritise the archival and the indexing of
datasets marked with the “high” qualifier. Other datasets 
with will be made available as well, even if they
 are under proprietary formats or of “medium” or “low” 
utility, if deemed necessary by the researcher.

Sensitive data will not be released, unless properly 
anonymised or an agreement is reached with the parties 
involved ( see S ection 3.2 for a more in depth 
explanation of the management of sensitive data and IP). 
 
<table> 
<tr> 
<th>

**Data** **Description**

</th> 
<th>

**Data** **Format**

</th> 
<th>

**Utility**

</th> </tr> 
<tr> 
<td>

3d scan data

</td> 
<td>

.fls, .xyz, .xyb, .e57, .las, .ptx,

.fws

</td> 
<td>

**High** , for other

experiments/replicability

</td> </tr> 
<tr> 
<td>

3d models ( mesh)

</td> 
<td>

.obj, .stl, .fbx, .vrml

</td> 
<td>

**Medium** , for other experiments/replicability

</td> </tr> 
<tr> 
<td>

3d models ( NURBS)

</td> 
<td>

.iges, .step

</td> 
<td>

**Medium** , for other experiments/replicability

</td> </tr> 
<tr> 
<td>

3d models ( proprietary)

</td> 
<td>

.3dm, .blend

</td> 
<td>

**Low** , for other

experiments/replicability

</td> </tr> 
<tr> 
<td>

G-code

</td> 
<td>

.nc, .mod

</td> 
<td>

**Low** , highly Machine specific. Can not be used for 
reproduction of results

</td> </tr> 
<tr> 
<td>

Scripts

</td> 
<td>

.py, .sh, .bat, .gh

</td> 
<td>

**Medium** , may be useful for reproduction of results, but
 can be also environment specific.

</td> </tr> 
<tr> 
<td>

Software Code

</td> 
<td>

code repositories ( .git)

</td> 
<td>

**High** , useful for both other enterprises, future

experiments and replicability

</td> </tr> 
<tr> 
<td>

Database files

</td> 
<td>

.xml, .json, .csv, .vtk

</td> 
<td>

**High** , may contain highly

confidential and personal information

</td> </tr> 
<tr> 
<td>

Notes, and Temporal files

</td> 
<td>

.txt, .xml, .json

</td> 
<td>

**Low** , useful only for following procedural steps

</td> </tr> 
<tr> 
<td>

Simulation Datasets and Config Files

</td> 
<td>

.csv, .vtk

</td> 
<td>

**High** , useful for

reproducing experimental

steps and for using different analysis techniques in other
experiments

</td> </tr> 
<tr> 
<td>

Survey Data

</td> 
<td>

.csv

</td> 
<td>

**High** , may contain personal information. Useful for 
reproducing results and informing future research.

</td> </tr> </table>

# FAIR data

## Making data findable, including provisions for metadata

Innochain’s aim, under the scope of the Horizon 2020
open research data guidelines, is to maximise the 
reusability, impact and reach of the open data. An 
important aspect here is the discoverability. The use of
 Zenodo as the main repository of data ensures 
adhesion to well established standards of data 
identification and discovery. Zenodo assigns unique Digital
2 Object Identifiers ( DOI) and rich metadata ( compliant
to DataCite’s Metadata Schema ) to every record published 
on the platform and indexes this metadata both at 
Zenodo and DataCite servers to make it searchable.

Further to Zenodo’s provisions for discoverability, 
Innochain will also maintain a central index of all 
published datasets at the Innochain website to make 
the data more easily discoverable by researchers that 
relate to the projects. This central index will link
to the Zenodo repository and cite the DOI of each 
dataset. The metadata that is produced by Zenodo3 is
also harvestable, using the Open Archives Initiative’s 
Protocol for Metadata Harvesting ( OAI-PMH) making it
retrievable by search and discovery services outside of
Zenodo, DataCite and Innochain’s website.

2 3 https://schema.datacite.org/

 https://www.openarchives.org/OAI/openarchivesprotocol.html

Search keywords that also increase the discoverability of
the datasets will also be used, in close relation to 
search keywords used on the Innochain website. Further 
to keywords, Zenodo allows datasets to be associated to 
specific grants, and thus all published datasets will
be linked to the Innochain EC Grant (642877) to 
promote the dissemination of all the Innochain projects.

The datasets produced by Innochain may in cases 
contain more complex data, such as, for example, the 
case of software code or scripts. In these cases, 
file-level metadata will be generated whenever possible to 
make internal data structures more easily identifiable 
and discoverable. Naming conventions are also inherent to
management of such complex data structures and each 
project will employ project-specific naming conventions on 
the published datasets to promote the discoverability of 
that data. Wherever standard naming conventions exist, such
 as in programming languages, they will be followed.

Software code that will be openly published through 
Innochain will be done so through GitHub repositories. 
GitHub and Zenodo offer a seamless integration ( see 
_s ection 3.2_ ) which facilitates the version control and
 maintenance of software code along with the
discoverability and accessibility of an open data 
repository. Thus, each dataset of software code will
be residing as a repository at GitHub but will be 
given a unique DOI and rich metadata through the 
Zenodo platform to be made discoverable and searchable as
 a dataset.

## Making data openly accessible

As a general rule, Innochain strives to provide open 
and easy access to datasets where possible. Most data 
that is published (i.e. which supports or is cited 
in publications from the research) will be made openly 
available as default. Certain datasets will not be able
 to be shared because of partner NDAs or because they
 come from proprietary / industry sources. In these 
cases, datasets will either be abstracted, anonymized, 
or withheld, depending on the nature of the data and
 the wishes of the owner of the data. These will
be handled on a case-by-case basis but the research 
will strive to publish the involved data openly or
use datasets which are not restricted.

To this end, data will be collected and uploaded to
two main online, publicly-accessible resources. Github will 
be used as the primary means of sharing source code
 from the Innochain projects and Zenodo will be used 
to host larger datasets such as models, point clouds, 
simulation datasets, etc. These will be described and 
linked to from the main Innochain project website (
innochain.net). Data organization, description, and supporting
documentation will reside on the Innochain website, with
 direct links to the datasets on either of the two 
storage platforms. Datasets will be uploaded to the
Zenodo open-access research data repository. This will 
ensure open and fair access, and longevity of the 
datasets beyond the Innochain timeframe.Innochain already 
possesses a Github account which is being actively used 
by the research projects.

The reasons for using Github and Zenodo are integration
 and openness. The integration of GitHub with Zenodo 
allows code and software to be citable and easily 
found. Both are well-established online repositories with 
built-in redundancy and high usage, and can be expected
 to remain operational for the 5 year period that 
these datasets will be made available. Their high visibility
 and familiarity to the general public and community 
members means that easy access to the data is 
guaranteed. In the case of Github, this also allows
derivative projects and code forking to happen within 
the same platform. Both storage solutions are also 
accessed primarily through web browsers and popular 
version control protocols such as Git. Datasets and 
other uploads are enriched with descriptions, keywords,
author information, and other metadata, enabling them to
 be found easily.

The relevant formats and their archival solution are
listed in the table below: 
 
<table> 
<tr> 
<th>

**Data** **Description**

</th> 
<th>

**Data** **Format**

</th> 
<th>

**Archival** **Solution**

</th> </tr> 
<tr> 
<td>

3d scan data

</td> 
<td>

.fls, .xyz, .xyb, .e57, .las, .ptx,

.fws

</td> 
<td>

Zenodo

</td> </tr> 
<tr> 
<td>

3d models ( mesh)

</td> 
<td>

.obj, .stl, .fbx, .vrml

</td> 
<td>

Zenodo

</td> </tr> 
<tr> 
<td>

3d models ( NURBS)

</td> 
<td>

.iges, .step

</td> 
<td>

Zenodo

</td> </tr> 
<tr> 
<td>

3d models ( proprietary)

</td> 
<td>

.3dm, .blend

</td> 
<td>

Zenodo

</td> </tr> 
<tr> 
<td>

G-code

</td> 
<td>

.nc, .mod

</td> 
<td>

Zenodo

</td> </tr> 
<tr> 
<td>

Scripts

</td> 
<td>

.py, .sh, .bat, .gh

</td> 
<td>

github.com

</td> </tr> 
<tr> 
<td>

Software Code

</td> 
<td>

code repositories ( .git)

</td> 
<td>

github.com

</td> </tr> 
<tr> 
<td>

Database files

</td> 
<td>

.xml, .json,

</td> 
<td>

Zenodo

</td> </tr> 
<tr> 
<td>

Notes, and Temporal files

</td> 
<td>

.txt, .xml, .json

</td> 
<td>

Zenodo

</td> </tr> 
<tr> 
<td>

Simulation Datasets

</td> 
<td>

.csv, .vtk

</td> 
<td>

Zenodo

</td> </tr> </table>

In the same way, datasets will be converted to open
 formats as much as possible, except where it may 
result in a degradation or limitation of the dataset’s
use. Examples include proprietary formats for specific, 
specialist programs. It is therefore inevitable that some
specialist knowledge will be needed to access and use
the included data, since most projects deal with very 
specific knowledge domains and accompanying specialist 
software. However, links or descriptions of the required 
software and knowledge could be provided with the dataset
 to provide a starting point. Software itself will
be included in the data repository as fas as the 
licensing rule allow for it. In cases, where this is
 not possible we will instead provide descriptions of the
 software, data-formats, software versions and links to 
the software vendor. However, as described in chapter _ 2
 Data Summary_ __ the dataformats used in Innochain are
in most cases industry standard. A global use, wide 
support in other softwares and hence longevity of the 
formats can hence be expected.

In terms of licensing, the data will be released
under the Creative Commons license (
_https://wiki.creativecommons.org/wiki/CC0_ ) __ , in line with 
the aim of providing publicly accessible open data. A 
data access committee will therefore not be needed. 
Securing the right to openly publish data that may
come from industrial partners or other proprietary 
sources in an open way will be the responsibility of 
each researcher, otherwise data that is proprietary or
belonging to a third party will not be published.

These conditions for access and licensing will be
outlined on the Innochain website. Each dataset will 
also have with it the relevant conditions and terms
of access, if applicable. In general, however, Zenodo and 
GitHub both allow unrestricted access ( without need for
authentication and authentication procedure) to the 
datasets that they hosts.

Means of identifying the accessor of the data have 
not been discussed. Since the Plan aims at democratic 
and open access, this is not considered a high 
priority.

## Making data interoperable

The assessment of the data produced within Innochain, 
shows that two general classes of data exist, with 
individual challenges and approaches towards interoperability:

### Data in standard formats of the building industry

The data produced in Innochain follows established 
standards and formats. These are either open source and 
hence well documented or are widespread in communities
 of researchers and professionals in architecture, that an
 understanding and interoperability of the data is certain.
 This implies current as future practice. Metadata to
identify the filetype and the origin of the data is 
implemented in the file headers. The data is 
generated by well established software, such as Rhino3D or
 Sofistik, which implements the metadata automatically in 
the file header.

Some of the formats are created in programs, which
make use of dependencies. In some cases, such as the 
popular McNeel Rhino / Grasshopper software environment, 
this accounts to an extensive set of plugins and 
libraries. This constellation is problematic, as plugins 
and libraries change quickly and it is after a short 
while not possible anymore to recreate the original setup
 anymore. In Innochain dependencies are hence packaged
 and the according zip with all dependencies and the
original files are placed alongside the original file.

### Code and data in novel formats

Interoperability in relation to code and data which is
in novel formats, such as the formats generated with 
the Speckle 4 , the open source project, which emerged 
in ESR 5, is following well established practices 5 of 
software engineering in terms of metadata. It is 
documented using the OpenApi Standard . It is both 
machine as well as ‘human’ readable.

## Increase data reuse ( through clarifying licences)

Wherever possible, data will be made open and freely
available to promote dissemination and reuse. If 
confidentiality or privacy issues exist, the data may 
be protected with licenses of minimum possible restriction, 
such as non-commercial or non-derivative creative commons.

Data will be made available as it is created to 
promote reuse internally and externally both within and 
after the course of the project. If a project is
seeking patent or a publication is pending, the data 
will be made available as soon as the patent 
application is filed or the publication is published.

In general, our intent is to maximise the dissemination
reach and reusability of the projects, therefore we aim 
to implement the minimum restrictions to the data that
 is produced. Therefore the least restrictive licenses, 
such as creative commons attribution ( CC-BY 4.0) will be
 used, where possible.

Innochain will make provisions for data storage and 
maintenance on its website for at least 5 years from 
the end of the project, with a possibility to 
extend that period if the data is found to

be useful to the public. All datasets that are 
published through Zenodo will follow the repository’s 
retention period which is at least 20 years from now.

_4_ 5 _ https://speckleworks.github.io/SpeckleOpenApi/#schemas_ 
_https://www.openapis.org/_

It is in the interest of every researcher to 
publish high quality data sets, so we expect each
dataset to be quality assured by the project that
generates the data. We are initially not planning to 
centrally assure the quality of the disseminated data
sets, but we will evaluate the quality assurance provisions
 in the next revision of the data plan.

# Allocation of resources

The Innochain project has set aside sufficient funds 
for covering all the aspects regarding data storage and 
ensuring its long term accessibility. The following costs
 are estimated and presented only as guidelines, 
nevertheless they provide a sufficient insight into what
 is to be expected:

 * Github.com: code repository. **Cost** : Free 

 

 * Zenodo ( will also mirror Github repositories): data repository. **Cost** : Free 

 

 * Innochain website hosting. **Cost** : €6.60/month, **Total:** € **400** ( for five years) 

 

 * Innochain.net domain name registration: **Cost** : €20/year, **Total:** € **100** ( for five years) 

 

Uploads, classification and indexing of datasets is the
responsibility of the individual researchers. This will 
nevertheless follow the prescribed classification procedures 
offered by the Zenodo repository service, thus ensuring 
a clear taxonomy and both machine and human readable 
metadata.

# Data security

Sensitive ( personal) data will not be shared, and, as
 such, security will only be focused towards the intact 
preservation of the datasets and the anonymisation of
them if necessary. Data security shall be provided by
well established and up-to-date web technologies and is
the responsibility of the specific service providers (
i.e., Github/Zenodo).

Github provides an indefinite long-term availability of
the code repositories. Furthermore, Zenodo guarantees a 20 
year retention period. The indexing, searchability and 
discovery of these resources on the innochain.net website 
will be guaranteed for five years onwards from the end 
project by ensuring the domain name and hosting 
payments upfront.