<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div class="elementToProof" style="font-family: Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
I can add what our use case was. </div>
<div class="elementToProof" style="font-family: Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
There was a local team building a web tool for x-ray spectra viewing and quick line identification, so I asked them to use our SSA for it. We then added a datalink service descriptor to our SSA results and served the response matrices in the datalink table
result. (The SSA result at the time had the link to the FITS file.) It worked internally with their tool for a while but the tool didn't make it to production. So that was our use case. </div>
<div class="elementToProof" style="font-family: Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Now we are working more on our ObsTAP and its datalinks. But precisely the question of which products get their own row in our ObsCore table is what we're working on now. Presumably, whatever we decide, this hypothetical tool could work with as long as the
service is performant. But from the client point of view, being given a tarball is more annoying to code for. I would prefer listing the spectrum product alone in ObsCore and give each ancillary file its own row in the DataLink result table. I.e., list a
spectrum in ObsCore and return additional rows in the DataLink result for each of the files that would constitute the bundle. What would the bundle as a tarball facilitate? </div>
<div id="appendonsend" style="color: inherit;"></div>
<div style="font-family: Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<hr style="display: inline-block; width: 98%;">
<div dir="ltr" id="divRplyFwdMsg" style="color: inherit;"><span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"><b>From:</b> heig <heig-bounces@ivoa.net> on behalf of Mireille Louys via heig <heig@ivoa.net><br>
<b>Sent:</b> Monday, May 5, 2025 1:50 PM<br>
<b>To:</b> heig@ivoa.net <heig@ivoa.net><br>
<b>Subject:</b> Re: [Heig] [EXTERNAL] [BULK] Re: vocabulary update: proposal for dataproduct_type update for high energy data : event-list definition and event-bundle</span>
<div> </div>
</div>
<div style="font-size: 11pt;">CAUTION: This email originated from outside of NASA. Please take care when clicking links or opening attachments. Use the "Report Message" button to report suspicious messages to the NASA SOC.<br>
<br>
<br>
<br>
<br>
Hello,<br>
<br>
Thanks Tess and Laurent for these examples .<br>
<br>
This was a proposal during the HE workshop last week to bring some examples<br>
<br>
showing an Obscore data discovery ( obscore entry here ) and exploring<br>
various settings of data link scenarios .<br>
<br>
Any volunteer for examples from other archives ?<br>
<br>
Best , Mireille<br>
<br>
<br>
Le 05/05/2025 à 18:14, Laurent Michel via heig a écrit :<br>
> Hello,<br>
><br>
><br>
><br>
> Le 05/05/2025 à 08:56, Markus Demleitner via semantics a écrit :<br>
>> Hi Tess,<br>
>><br>
>> On Wed, Apr 30, 2025 at 01:48:29PM +0000, Jaffe, Tess (GSFC-6601) via<br>
>> semantics wrote:<br>
>>> Possibly dumb question:<br>
>><br>
>> Not at all; you're touching a topic that has been discussed quite a<br>
>> few times now without a satisfying result yet: What does it mean if<br>
>> there are multiple items with the same semantics in Datalink? Is it<br>
>> "all of them together give the thing" or is it "they are<br>
>> alternatives"? Or yet something else?<br>
>><br>
>> Previous rounds suggested that the interpretation will probably<br>
>> depend on the concept, but the details turned out to be fairly messy.<br>
>><br>
>><br>
>>> If an ObsCore table lists an event-bundle as a separate row with<br>
>>> its own product_type, and the access_url follows best practice<br>
>>> specifying a datalink that will return the bundle, what should the<br>
>>> DataLink result include as #this? We are actively putting this<br>
>>> together now at HEASARC. If the product type is simply a spectrum,<br>
>><br>
>> That's excellent news!<br>
>><br>
>>> our datalink result has the spectrum file as #this and the response<br>
>>> matrices, background, etc. as related products in the same result<br>
>>> table. If the product itself is a bundle, what is the #this? Do<br>
>>> we have to provide a tarball or something? Or are there multiple<br>
>>> #this with different dataproduct_subtypes? The latter doesn't<br>
>>> sound right to me.<br>
>><br>
>> Given my preamble, I'd avoid multi-#this. The ideal solution would<br>
>> IMHO be a standard archive if the HEIG can commit to such a thing.<br>
>> Failing that, I think a tar archive of the individual components<br>
>> would be the second best thing. CADC does something like this,<br>
>> although the other way round: They're handing out everything tarred<br>
>> together as a #package. Offering the components individually,<br>
>> possibly as #progenitor-s, would help cases when people really only<br>
>> want to fetch a single part.<br>
><br>
> I agree that having multiple #this is confusing (which one is the good<br>
> one.??).<br>
> In my understanding #this must match the product_type as in the<br>
> Obscore record.<br>
><br>
> If a spectrum bundle is exposed in a separate row, we should have<br>
> something like this:<br>
><br>
> Obscore row:<br>
> -----------<br>
> - product_type=spectrum-bundle (tbd)<br>
> - access_format=application/x-votable+xml;content=datalink<br>
><br>
> Datalink response:<br>
> -----------------<br>
> - link #1<br>
> - semantics=#this<br>
> - content_qualifier=spectrum-bundle (TBD)<br>
> - content_type=application/tar+gzip<br>
> - description="spectrum file + preview + ARF + RMF + Background<br>
> spectrum"<br>
><br>
><br>
> If the spectrum is exposed in a separate row:<br>
><br>
> Obscore row:<br>
> -----------<br>
> - product_type=spectrum<br>
> - access_format=application/x-votable+xml;content=datalink<br>
><br>
> Datalink response:<br>
> -----------------<br>
> - link #1<br>
> - semantics=#this<br>
> - content_qualifier=spectrum<br>
> - content_type=application/fits<br>
> - description="spectrum file"<br>
> - link #2<br>
> - semantics=#package<br>
> - content_qualifier=spectrum-bundle (TBD)<br>
> - content_type=application/tar+gzip<br>
> - description="spectrum file + preview + ARF + RMF + Background<br>
> spectrum"<br>
><br>
> I do not believe we are able to design a standard HEIG archive because<br>
> this too much mission/tool specific.<br>
> Do we really needs the archive content to be machine readable?<br>
> Anyway, individual files can be exposed with an adapted semantics.<br>
><br>
> Laurent<br>
><br>
><br>
>><br>
>> But at least for a prototype (and, if that works fine, perhaps also<br>
>> as a long-term practice), I think nobody would be terribly confused<br>
>> if #this were just the time series or spectrum, in particular if a<br>
>> content-qualifier would let machines figure out what it is they'll<br>
>> get.<br>
>><br>
>> I'm not too happy with #progenitor for the individual components,<br>
>> though. Perhaps datalink/core should have a concept #component with<br>
>> the definition "for datasets where #this is composed of multiple<br>
>> individual artefacts, #component rows offer access to individual<br>
>> artefacts. Use local-semantics to consistently mark up the roles of<br>
>> the components." or so.<br>
>><br>
>> In the end, I think we need to see what will help clients consuming<br>
>> this. Do we have software that we could use to try that out? What<br>
>> do people use to work this #event-bundle-s?<br>
>><br>
>> -- Markus<br>
>><br>
><br>
> --<br>
> English version: https: //https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.deepl.com%2Ftranslator&data=05%7C02%7Ctess.jaffe%40nasa.gov%7C6075ae45df2e4bb5325508dd8bfd5006%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C638820642266465078%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=vYY2ZoY99F8RvAPlu9Ske3PYa0z8E2Ne12cW%2BdF8Kl4%3D&reserved=0<br>
<br>
--<br>
--<br>
Mireille Louys, MCF (Assistant Professor)<br>
Centre de données Astronomiques (CDS) Equipe Images, ICube<br>
Observatoire de Strasbourg Telecom Physique Strasbourg<br>
11, rue de l' Université 300, Bd Sebastien Brandt CS 10413<br>
F-67000 Strasbourg F-67412 Illkirch Cedex<br>
<br>
--<br>
heig mailing list<br>
heig@ivoa.net<br>
<a href="http://mail.ivoa.net/mailman/listinfo/heig" id="OWA2dc2fe19-a333-6255-b857-4440c58b3f43" class="OWAAutoLink" data-auth="NotApplicable">https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.ivoa.net%2Fmailman%2Flistinfo%2Fheig&data=05%7C02%7Ctess.jaffe%40nasa.gov%7C6075ae45df2e4bb5325508dd8bfd5006%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C638820642266487767%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=YfJb4jKT78AkfN4F7QVYmofeRGcMreiSO0uI9ObBHWo%3D&reserved=0</a></div>
</body>
</html>