Metadatamanagement: Maybe study.dataAvailability should correspond to da|ra

[rbirkelbach]

I think the field study.dataAvailability could be more fine grained to 100% correspond with dara, because they have 5 fields and our three fields only correspond to 2 of the five (delivery and not available). Not sure whether that's necessary though.

Also, see #1780

edit: dara:

availabilityType | definition
-- | --
Download | Released for everybody.
Delivery | Can be delivered.
On-site | Can be used on-site only.
Not available | Not available.
Unknown | No information is provided.

[UteH]

we will have to deliver availability to VFDB

• Verfügbar
• Nicht verfügbar
• Vorläufig nicht verfügbar

(optional können weitere Angaben im Freitextfeld availabilityFree gemacht werden, Semikolon als Trennzeichen)

I think we could just map our new system to the VFDB.

[rreitmann]

Generally we need to discuss the meaning and processing of study.dataAvailability. How does it correspond to release.version? Can we set it automatically? Do we need more values?...

[rreitmann]

We do not want to use the availabilityTypes from Dara cause they mix up accessWay and availability.

[rreitmann]

The idea of setting dara's availabilityType automatically for versions >= 1.0.0 came up again. Currently we think that we do not need this field in the study domain object.

[rreitmann]

Currently @fbaillet has found three studies which are set to unavailable although they are released with a version >= 1.0.0 ...

[UteH]

I think the studies are labeled as "not available" in the MDM? So I guess we just have to relabel?

[rreitmann]

Yep, but that would not be necessary if we simply removed the field study.dataAvailability. IMHO it is an user error we can prevent...

[UteH]

I think we wanted to use that for releases < 1.0.0, for example, if a project is "in Aufbereitung" (~which has not occurred as of today~).

If we do not use this field anymore, we need to give this information to the users in study.annotations.

[svietgen]

I just changed "not available" to "available" for gsl2012 and gsl2015 (I forgot to change it before releasing it)

[svietgen]

I think we wanted to use that for releases < 1.0.0, for example, if a project is "in Aufbereitung" (which has not occurred as of today).

We used it for bst02 (If I remember correctly)

[rreitmann]

The cases mentioned are just proving my statement:
version < 1.0.0 => In Aufbereitung (and not sent to da|ra anyway)
version >= 1.0.0 => data available
shadow copy.hidden => data unavailable

We do not need an extra field...

[rreitmann]

We need to delete the field from mongo and reindex elasticsearch:
db.getCollection('data_packages').updateMany({}, {$unset: {dataAvailability: ''}})