adding DataLink table example in UseCase

[Bonnarel]

First change is in use case 1.4 : if the exposed dataset is a bundle we don't actually need the DataLink acces mode. The access_url would benefit to be directly pointing the application/fits (whatever High energy flavor for the bundle) bundle dataset.

Second change is in use case 1.6 : I created a dummy DataLink response table consistent with this use case. Just because the pseudo-code given in this use case may be more understandable with this table. In addition in this use case I changed event-bundle to event-list because if you expose event-bundle in ObsCore you don't need DataLink (except if you use url with fragments in the DataLink table but this another story and was not implied by the use case text)

I would like to propose other changes for use case 1.3 and 1.9 but I will first create an issue to explain that because it could be more controversial

[loumir]

Ok for these changes . datalink represent associated data , so the data product type is event-list , the 'head' data set and associated data are in the other parts of the data link table .

[bkhelifi]

I think I am not in phase with that.
When we have a Datalink (as stated in the title of this use case), the response of this query is not a fits. Do I mistaken?

[Bonnarel]

I think I am not in phase with that. When we have a Datalink (as stated in the title of this use case), the response of this query is not a fits. Do I mistaken?

If the dataproduct_type of the dataset is "bundle" the single link contains everything. SO you can write its mime type directly in acces_format. Why would you like to have DataLink with several "options" in that case ? The only situation I can imagine is if you want to point towards the various subparts of the bundle using url with fragments. But that didn't seem to be the intention.

[iannevans]

I think I am not in phase with that. When we have a Datalink (as stated in the title of this use case), the response of this query is not a fits. Do I mistaken?

If the dataproduct_type of the dataset is "bundle" the single link contains everything. SO you can write its mime type directly in acces_format. Why would you like to have DataLink with several "options" in that case ? The only situation I can imagine is if you want to point towards the various subparts of the bundle using url with fragments. But that didn't seem to be the intention.

Suppose I want to make available both an event-list and an event-bundle (i.e., the event list plus other associated data products) via separate ObsCore records (because some users just want the event list and others want the entire bundle). The end user can differentiate the query because one has dataproduct_type = 'event-list' and the other has dataproduct_type = 'event-bundle'. However I don't want to create a single bundle file for the latter that includes all the products because doing so would require duplicating a very large event list data product, which would dramatically increase archive storage requirements. How would I do this using datalink?

[iannevans]

I think I am not in phase with that. When we have a Datalink (as stated in the title of this use case), the response of this query is not a fits. Do I mistaken?

Bruno, I think you need to sign off on changes to these use cases, since we state in the text that these are event-bundle use cases and I'm not sure what is the priority is here (event-bundle use case vs. datalink use case). As far as the technical content, I'm fine although I have some minor tweaks as far as to the textual descriptions in the example datalink table (e.g., the aeff is not the "effective area of the event-list" but rather the effective area of the telescope/instrument associated with the event list).

[bkhelifi]

I think I am not in phase with that. When we have a Datalink (as stated in the title of this use case), the response of this query is not a fits. Do I mistaken?

Bruno, I think you need to sign off on changes to these use cases, since we state in the text that these are event-bundle use cases and I'm not sure what is the priority is here (event-bundle use case vs. datalink use case). As far as the technical content, I'm fine although I have some minor tweaks as far as to the textual descriptions in the example datalink table (e.g., the aeff is not the "effective area of the event-list" but rather the effective area of the telescope/instrument associated with the event list).

A datalink is per definition a bundle, is not it? the access url is towards a kind of dictionnary containing access to many files... This case is perfectly in line with our current definition of event-bundle.
But a bundle is not necessary a datalink (ex: a tar file containing many files, so the data access url is towards a file).

I really disagree that for the use case "Search for event bundles via DataLink that include Cas A for a TeV spectromorphology study", the access_format can not be a fits, because a Datalink response object is expected. The use case is clear in its description: we expect a Datalink.

About "the aeff is not the "effective area of the event-list" but rather the effective area of the telescope/instrument associated with the event list", I agree, of course;) Well seen