4D Nucleome Network Wiki

Notes drafted by Kathia Zaleta

01-23-2017 4DN POLICY MINUTES - Kathia Zaleta Rivera

Next meeting February 13th \2017 AGENDA: - Revise the membership of the policy working group - Feedback on the manuscript track - Release policy \

1.- Revise membership of the policy working group

• Include more people to policy working group
• Bring this up to the steering committee meeting
• Include participants with different opinions
• Email individually to people for participation
• Include people that have experience on sharing data, since they know the challenges of sharing data.

\ 2. Feedback on the manuscript tracker * There is no feedback and no one responded, take it as great. * Few papers are listed, but not as many as expected. There is a way to know if people are complain? The only way to monitor would be with the new publications coming out that have never been in the manuscript tracker. * There is a system to monitor it in the 4DN portal * Remind people in the steering committee meeting to use the manuscript tracker. * Make manuscript tracker more visible? This can’t be done because manuscript tracker is only internal \

3.- Release policy (See flow chart proposed by Nils Gehlenborg)

Question:

Struggle to define what is production data? and what is technology development data?

• During the steering committee meeting was suggested that there is data types that can be defined clearly, but how will be the QC process? If we have an automatic QC process and if we have a data model how will capture it? (see flow chart)
• Is there any QC process and do we have meta data model to capture the data associated with that data type?
• If ‘YES’, we have a current pipeline in the data portal and the first default will make it automatically available to the network. The question is: Is the data available good enough to be released publicly automatically? Here, we have a QC pipeline and based on it we were be able to distinguish two different QC flags (Green and Yellow).
• ‘Green Flag’ (Pass QC): Data will be automatically available to the network and public
• ‘Yellow Flag’ (Failed QC): Automatically released only to the network. Question: Release data when failed QC although does not meet QC standards.
• If we don't have pipeline, this will be only for the technology data, the visibility of this data is private and because there is no QC it will be a ‘Red flag’, since there is not information about the quality of the data.

Figure 1| Flowchart for release policy proposed by Nils Gehlenborg. QC:Quality Control

Feedback of the release flowchart policy proposal:

• Lisa Chadwick suggested NOT to have only private for the investigators
• One concern is the lack of NO QC standards, since there is nothing to compare.
• To achieve QC standards, \__data has to be available to everybody
• Important to create automated QC pipelines
• For now, everything will be in the manual (no automation) but investigators will have the opportunity to make data available without QC and make it accessible to the network and public.
• Question: Submitting the data will mean it has all the metadata? For this, the first step will be to have a model that describe the experiment and automatically QC data.
• In order to establish QC standard, we want data with QC
• Having a flag along w
• ith the comments since we need something automatically to filter.
• Question: Should we consider QC as post-submission? Could be ideal, but investigators are still skeptical.
• Question: Who will see the data? (no discussed)
• There will be some investigators that won’t release their data
• Have investigators to release data to establish QC, it can be with a flag, but still need to release data.
• Submit and provide QC to public release? There is a concern to have data around in a format that in a year later people is not going to use. This will affect all the data types. This happens in ENCODE.