We did introductions and have a nice bit of diversity in this group.

Couldn't open overleaf

Not going to start with other's use-cases

Starting at Dataset Management...

Is this about tape or legacy data? Both, long term archival storage.

Need to be able to read data over a long period of time, but that's hard because versions change and things break.

Data preservation

being able to see the old data "seamlessly", I should be able to easily

Need to be able to rerun the software from that era.

They don't like to be able to open data in a modern version of the framework.

They only want to get a snapshot of the framework/data/ecosystem to *reproduce the results* not for new results.
	> The Notetaker thinks that we could aim higher, but others did not agree

Heard a Daya Bay case-study

The goal should be to read-in those data-products from legacy framework and convert that to a modern framework
	> CMS has the requirement that they need to be able to reprocess any data they have ever taken
	
Question about Data-Base, they also needs to get backed up and saved (thinks that hold run information, intervals of validity, etc.)

independence of data format from the framework, one could get access to the data without having to use the framework. One could access the data with "more standard tools". This would help with the longterm analyzability of the data. You would give up "database" connections because this happens through the framework.

CMS can read their outputs with raw ROOT, but you can get bells and whistles by using the framework

Distinction between "Processing framework" and "analysis toolkit", we shouldn't be forced to use the "processing framework" to do the analysis

Don't write output in binary format that only framework can read

We should be careful about keeping all the provanence information in the data files, since it might not scale. we should be able to track this information somehow.

Capture the actions of the framework.

Informations to keep:
	> Software Versions (current thing is UPS)
	> All the information you need to understand the data, time-varying and versioned parameters (might want a rollback time, or a tag!!! I vote for the second.)
	> Information about the goodness-or-badness of data

Need to be able to do cross (joint) experiment analyses at the lowest possible level, such that the framework does not inject systematics  

Most of the development in the current generation of LArTPC experiments seems to occur on local laptops, which is an issue for connecting to database

is data management more than archival storage? We said nothing about data distribution

Ability to access experiments data from multiple remote sites.

can't we just copy data to grid sites? Yeah, but it is silly slow

We should require that accessing the data is not the computing bottle-neck

there was a lot of confusing discussion about needing to know when events happened, were processed, and timestamping.