From laurent.michel at astro.unistra.fr  Tue Apr  1 15:27:22 2025
From: laurent.michel at astro.unistra.fr (Laurent Michel)
Date: Tue, 1 Apr 2025 15:27:22 +0200
Subject: Design of MANGO errors: feedback expected
Message-ID: <06D8761E-8E2A-479F-BE0F-E19F1FE76BF9@astro.unistra.fr>

Hello DM,

(cf issue https://github.com/ivoa-std/MANGO/issues/60)

We would like get feedback from the WG about the MANGO error.

In the MANGO use cases, we have the cross-match case which requires the errors to come with statistical parameters (distribution and confidence level).

For this purpose, Mango has an abstract. datatype  with these parameters (mango:PropertyError) from which some concrete error types (e.g. ellipse ?) derive.
    ? Symmertrical error  1D and 2D
    ? ASymmertrical error  1D
    ? Ellipse error

These 4 classes have counterparts in Meas, but they have more handy attributes.
    ? Individual roles for each attribute (majorAxis, minorAxis, angle) instead of value arrays [x, x, x].

These classes also have specific names in order to prevent conflicts with measure classes.

The question is to decide whether the abstract mango:PropertyError should or not derive from the astract meas:Uncertainty?
    ? PRO: any Measurement error type could then be reused by Mango properties
    ? CON: this will make Mango providing different error types form the same purpose (meas:ellipse or mango:PErrorEllipse)
    ? CON: in our experience, cross model references are a burden for clients and particularly for annoters
    ? CON: The MIVOT annotation of some Meas error classes may be tricky to interpret for the clients (attribute values in arrays).

We suggest not deriving mango:PropertyError from meas:Uncertainty.

We would like to get the group (des)agreement before opening the corresponding GIT PR

Mireille and Laurent

From mdittmar at cfa.harvard.edu  Tue Apr  1 16:23:13 2025
From: mdittmar at cfa.harvard.edu (CresitelloDittmar, Mark)
Date: Tue, 1 Apr 2025 10:23:13 -0400
Subject: Design of MANGO errors: feedback expected
In-Reply-To: <06D8761E-8E2A-479F-BE0F-E19F1FE76BF9@astro.unistra.fr>
References: <06D8761E-8E2A-479F-BE0F-E19F1FE76BF9@astro.unistra.fr>
Message-ID: <CAH4enyMhOTPLQL_c+pzKm3o2LjXkNOJs=iNOVjcRh1E-tfeP0w@mail.gmail.com>

Laurent/Mireille,

I was literally on my way to submit a comment on this!

I think your proposal is the best approach at this point.. separate the
mango:PropertyError from meas:Uncertainty.
Unless we, as a working group, have a consensus on how to execute these
situations in the models, I think it's better to avoid the conflicts which
arise from having these stem from the same base.

re:
    ? CON: in our experience, cross model references are a burden for
clients and particularly for annoters
    ? CON: The MIVOT annotation of some Meas error classes may be tricky to
interpret for the clients (attribute values in arrays).

This is worth discussing in the group (Running Meeting?)...
I read this as "you've changed the modeling to avoid issues with the
annotation".

Mark




On Tue, Apr 1, 2025 at 9:27?AM Laurent Michel via dm <dm at ivoa.net> wrote:

> Hello DM,
>
> (cf issue https://github.com/ivoa-std/MANGO/issues/60)
>
> We would like get feedback from the WG about the MANGO error.
>
> In the MANGO use cases, we have the cross-match case which requires the
> errors to come with statistical parameters (distribution and confidence
> level).
>
> For this purpose, Mango has an abstract. datatype  with these parameters
> (mango:PropertyError) from which some concrete error types (e.g. ellipse ?)
> derive.
>     ? Symmertrical error  1D and 2D
>     ? ASymmertrical error  1D
>     ? Ellipse error
>
> These 4 classes have counterparts in Meas, but they have more handy
> attributes.
>     ? Individual roles for each attribute (majorAxis, minorAxis, angle)
> instead of value arrays [x, x, x].
>
> These classes also have specific names in order to prevent conflicts with
> measure classes.
>
> The question is to decide whether the abstract mango:PropertyError should
> or not derive from the astract meas:Uncertainty?
>     ? PRO: any Measurement error type could then be reused by Mango
> properties
>     ? CON: this will make Mango providing different error types form the
> same purpose (meas:ellipse or mango:PErrorEllipse)
>     ? CON: in our experience, cross model references are a burden for
> clients and particularly for annoters
>     ? CON: The MIVOT annotation of some Meas error classes may be tricky
> to interpret for the clients (attribute values in arrays).
>
> We suggest not deriving mango:PropertyError from meas:Uncertainty.
>
> We would like to get the group (des)agreement before opening the
> corresponding GIT PR
>
> Mireille and Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20250401/f996f112/attachment.htm>

From laurent.michel at astro.unistra.fr  Tue Apr  1 17:50:32 2025
From: laurent.michel at astro.unistra.fr (Laurent Michel)
Date: Tue, 1 Apr 2025 17:50:32 +0200
Subject: Design of MANGO errors: feedback expected
In-Reply-To: <CAH4enyMhOTPLQL_c+pzKm3o2LjXkNOJs=iNOVjcRh1E-tfeP0w@mail.gmail.com>
References: <06D8761E-8E2A-479F-BE0F-E19F1FE76BF9@astro.unistra.fr>
 <CAH4enyMhOTPLQL_c+pzKm3o2LjXkNOJs=iNOVjcRh1E-tfeP0w@mail.gmail.com>
Message-ID: <077cd283-434b-4193-aa29-40212d9bb2ac@astro.unistra.fr>



Le 01/04/2025 ? 16:23, CresitelloDittmar, Mark a ?crit?:
> Laurent/Mireille,
> 
> I was literally on my way to submit a comment on this!
> 
> I think your proposal is the best approach at this point.. separate the mango:PropertyError from meas:Uncertainty.
> Unless we, as a working group, have a consensus?on how to execute these situations in the models, I think it's better to avoid 
> the conflicts which arise from having these stem from the same base.

OK, I'll do this in the next PR

> 
> re:
> ? CON: in our experience, cross model references are a burden for clients and particularly for annoters
>  ? ? ? CON: The MIVOT annotation of some Meas error classes may be tricky to interpret for the clients (attribute values in arrays).
> 
> This is worth discussing in the group?(Running Meeting?)...

Yes of course.

> I read this as "you've changed the modeling to avoid issues with the annotation".

I do not say this. Any pattern can be annotated.

I'm just saying that:
- in my perspective, stackholders will prefer to deal with ellipses defined as
      {majorAxis, minorAxis, angle} (one role per item)
   rather than
       [x, y, z] (one role per item rank)
   this point do no relate with the annotation.
- There is no issue with the annotation, but let's mix model
   components only when necessary to keep the annotation process simple.

Laurent
> 
> Mark
> 
> 
> 
> 
> On Tue, Apr 1, 2025 at 9:27?AM Laurent Michel via dm <dm at ivoa.net <mailto:dm at ivoa.net>> wrote:
> 
>     Hello DM,
> 
>     (cf issue https://github.com/ivoa-std/MANGO/issues/60 <https://github.com/ivoa-std/MANGO/issues/60>)
> 
>     We would like get feedback from the WG about the MANGO error.
> 
>     In the MANGO use cases, we have the cross-match case which requires the errors to come with statistical parameters
>     (distribution and confidence level).
> 
>     For this purpose, Mango has an abstract. datatype? with these parameters (mango:PropertyError) from which some concrete
>     error types (e.g. ellipse ?) derive.
>      ? ? ? Symmertrical error? 1D and 2D
>      ? ? ? ASymmertrical error? 1D
>      ? ? ? Ellipse error
> 
>     These 4 classes have counterparts in Meas, but they have more handy attributes.
>      ? ? ? Individual roles for each attribute (majorAxis, minorAxis, angle) instead of value arrays [x, x, x].
> 
>     These classes also have specific names in order to prevent conflicts with measure classes.
> 
>     The question is to decide whether the abstract mango:PropertyError should or not derive from the astract meas:Uncertainty?
>      ? ? ? PRO: any Measurement error type could then be reused by Mango properties
>      ? ? ? CON: this will make Mango providing different error types form the same purpose (meas:ellipse or mango:PErrorEllipse)
>      ? ? ? CON: in our experience, cross model references are a burden for clients and particularly for annoters
>      ? ? ? CON: The MIVOT annotation of some Meas error classes may be tricky to interpret for the clients (attribute values in
>     arrays).
> 
>     We suggest not deriving mango:PropertyError from meas:Uncertainty.
> 
>     We would like to get the group (des)agreement before opening the corresponding GIT PR
> 
>     Mireille and Laurent
> 

--
English version: https: //www.deepl.com/translator
-- 
jesuischarlie/Tunis/Paris/Bruxelles/Berlin

Laurent Michel
SSC XMM-Newton
T?l : +33 (0)3 68 85 24 37
Fax : +33 (0)3 )3 68 85 24 32
Universit? de Strasbourg <http://www.unistra.fr>
Observatoire Astronomique
11 Rue de l'Universit?
F - 67200 Strasbourg

From mathieu.servillat at obspm.fr  Wed Apr  9 12:01:01 2025
From: mathieu.servillat at obspm.fr (Mathieu Servillat)
Date: Wed, 9 Apr 2025 12:01:01 +0200
Subject: Next DM running meeting Tuesday 15 April at 14:00 UTC
Message-ID: <0310567b-ba21-4a2b-9f4e-3996b518b0e3@obspm.fr>

Dear DMers,

our next running meeting is planned Tuesday 15 March at 14:00 UTC, here 
is a Zoom link:

https://cnrs.zoom.us/j/93579163662?pwd=osNtfnJVbbs1IehjnaW5bkx0lTfD27.1

There are several topics of interest:
- ObsCore topic
 ??? - Define request to IG from DM
 ??? - ObsCore v1.1 on Github status
- Preparation for interop
 ??? - Registration (in person or not)
 ??? - Roadmap status
 ??? - Abstract submissions
 ??? - ?Plenary? topics

Some other topics are proposed here :
https://wiki.ivoa.net/twiki/bin/view/IVOA/IvoaDMRunningMeetings

Next meeting dates, probably :
* Tuesday May 20 2025 @ 14:00 UTC
* Sessions at Interop, 2-6 June

Best regards,

Mathieu & Mark

-- 
Dr. Mathieu Servillat
LUX - Laboratoire d'?tude de l'Univers et des ph?nom?nes eXtr?mes
B?t 18, Bur. 222
Observatoire de Paris, Site de Meudon
5 place Jules Janssen
92195 Meudon, France
T?l. +33 1 45 07 78 62
--


From laurent.michel at astro.unistra.fr  Wed Apr  9 12:38:51 2025
From: laurent.michel at astro.unistra.fr (Laurent Michel)
Date: Wed, 9 Apr 2025 12:38:51 +0200
Subject: Next DM running meeting Tuesday 15 April at 14:00 UTC
In-Reply-To: <0310567b-ba21-4a2b-9f4e-3996b518b0e3@obspm.fr>
References: <0310567b-ba21-4a2b-9f4e-3996b518b0e3@obspm.fr>
Message-ID: <8dd7c681-e4d3-440c-a455-2ec49ccd13e6@astro.unistra.fr>

Hello,

I can also give a few MANGO update.

LM

Le 09/04/2025 ? 12:01, Mathieu Servillat via dm a ?crit?:
> Dear DMers,
> 
> our next running meeting is planned Tuesday 15 March at 14:00 UTC, here is a Zoom link:
> 
> https://cnrs.zoom.us/j/93579163662?pwd=osNtfnJVbbs1IehjnaW5bkx0lTfD27.1
> 
> There are several topics of interest:
> - ObsCore topic
>  ??? - Define request to IG from DM
>  ??? - ObsCore v1.1 on Github status
> - Preparation for interop
>  ??? - Registration (in person or not)
>  ??? - Roadmap status
>  ??? - Abstract submissions
>  ??? - ?Plenary? topics
> 
> Some other topics are proposed here :
> https://wiki.ivoa.net/twiki/bin/view/IVOA/IvoaDMRunningMeetings
> 
> Next meeting dates, probably :
> * Tuesday May 20 2025 @ 14:00 UTC
> * Sessions at Interop, 2-6 June
> 
> Best regards,
> 
> Mathieu & Mark
> 

--
English version: https: //www.deepl.com/translator
-- 
jesuischarlie/Tunis/Paris/Bruxelles/Berlin

Laurent Michel
SSC XMM-Newton
T?l : +33 (0)3 68 85 24 37
Fax : +33 (0)3 )3 68 85 24 32
Universit? de Strasbourg <http://www.unistra.fr>
Observatoire Astronomique
11 Rue de l'Universit?
F - 67200 Strasbourg

From mathieu.servillat at obspm.fr  Mon Apr 14 18:28:27 2025
From: mathieu.servillat at obspm.fr (Mathieu Servillat)
Date: Mon, 14 Apr 2025 18:28:27 +0200
Subject: Fwd: [Heig] Workshop on ObsCore extensions and HEIG in Paris - 29-30
 April 2025
In-Reply-To: <c01b384c-d8d2-415f-b00d-f69fc71f2a27@obspm.fr>
References: <c01b384c-d8d2-415f-b00d-f69fc71f2a27@obspm.fr>
Message-ID: <c4702b8d-55c3-4714-a7a1-73549ec71086@obspm.fr>

Dear all,

I transfer this message as the workshop we will host in Paris, 29-30 
April 2025, may be of interest to other IVOA WG or IG, as we will 
enlarge the discussion to ObsCore extensions in general.

Don't hesitate to register and come to the workshop !

Best regards,

Mathieu for the organization committee (Ada, Mireille, Catherine, Bruno, 
Laurent, Pierre C.)


-------- Message transf?r? --------

Dear HEIG,

Here is the workshop page with the general program (to be further detailed):

https://indico.obspm.fr/event/2674/

Please register if you can attend (remote or in person), and propose 
discussion topics.

We propose to have a HEIG session Tuesday 29 April from 1pm to 4pm UTC 
(9am-12pm EDT, 3pm-6pm CEST), and a 1h HEIG meeting Wednesday 30 April 
at 1pm UTC (9am EDT, 3pm CEST). An extra slot after the HEIG meeting is 
possible to further discuss next plans.

On Tuesday, we plan to have overviews of ObsCore and the proposed 
extensions, then a discussion on the proposed attributes for the HEIG 
extension (see online table via the link above), and the content of a 
HEIG note on this topic.

On Wednesday, we plan to prepare the proposed discussion at the Interop, 
involving working groups: DM, DAL, Registry and others Interest Groups.

Best regards,

Mathieu for the organization committee (Ada, Mireille, Catherine, Bruno, 
Laurent, Pierre C.)

-- 
Dr. Mathieu Servillat
LUX - Laboratoire d'?tude de l'Univers et des ph?nom?nes eXtr?mes
B?t 18, Bur. 222
Observatoire de Paris, Site de Meudon
5 place Jules Janssen
92195 Meudon, France
T?l. +33 1 45 07 78 62
--

-- 
heig mailing list
heig at ivoa.net
http://mail.ivoa.net/mailman/listinfo/heig


From mathieu.servillat at obspm.fr  Tue Apr 15 15:40:18 2025
From: mathieu.servillat at obspm.fr (Mathieu Servillat)
Date: Tue, 15 Apr 2025 15:40:18 +0200
Subject: Next DM running meeting Tuesday 15 April at 14:00 UTC
In-Reply-To: <0310567b-ba21-4a2b-9f4e-3996b518b0e3@obspm.fr>
References: <0310567b-ba21-4a2b-9f4e-3996b518b0e3@obspm.fr>
Message-ID: <1fd4a6d2-6f6b-4fc6-a85f-0d020055a3ca@obspm.fr>

Hi all,

this is a reminder for our meeting today at 2pm UTC (4pm CEST / 10am 
East Coast / 7am West coast) !

Best regards,
Mathieu & Mark



Le 09/04/2025 ? 12:01, Mathieu Servillat via dm a ?crit?:
> Dear DMers,
>
> our next running meeting is planned Tuesday 15 March at 14:00 UTC, 
> here is a Zoom link:
>
> https://cnrs.zoom.us/j/93579163662?pwd=osNtfnJVbbs1IehjnaW5bkx0lTfD27.1
>
> There are several topics of interest:
> - ObsCore topic
> ??? - Define request to IG from DM
> ??? - ObsCore v1.1 on Github status
> - Preparation for interop
> ??? - Registration (in person or not)
> ??? - Roadmap status
> ??? - Abstract submissions
> ??? - ?Plenary? topics
>
> Some other topics are proposed here :
> https://wiki.ivoa.net/twiki/bin/view/IVOA/IvoaDMRunningMeetings
>
> Next meeting dates, probably :
> * Tuesday May 20 2025 @ 14:00 UTC
> * Sessions at Interop, 2-6 June
>
> Best regards,
>
> Mathieu & Mark
>

-- 
Dr. Mathieu Servillat
LUX - Laboratoire d'?tude de l'Univers et des ph?nom?nes eXtr?mes
B?t 18, Bur. 222
Observatoire de Paris, Site de Meudon
5 place Jules Janssen
92195 Meudon, France
T?l. +33 1 45 07 78 62
--


From kellecruz at gmail.com  Wed Apr 16 20:36:31 2025
From: kellecruz at gmail.com (Kelle Cruz)
Date: Wed, 16 Apr 2025 14:36:31 -0400
Subject: DER_SNR?
Message-ID: <CAApiRV63Un2Nkapanfz4ZVQONpfh6SxnASswwUA6w8PAsG8pAg@mail.gmail.com>

Hi folks,

I'm working on a new data reduction pipeline and trying to get the output
spectra to comply with SpectrumDM1.2.  I'm currently having a struggle
convincing the team to use the "DER_SNR" FITS keyword to store the
calculated SNR of a spectrum.  Some people are worried that using this
keyword will imply that a specific algorithm was used to calculate the SNR.
Specifically, this one: http://www.stecf.org/software/ASTROsoft/DER_SNR/.
 Anyone care to comment on this?

Thanks,
Kelle

--
Kelle Cruz, PhD (she/her, they/them)
Assoc. Professor, Physics and Astronomy, Hunter College
CEO, ScienceBetter Consulting, LLC
CFO, Startorialist, Inc. <http://shop.startorialist.com>
Editor-in-Chief, AstroBetter Blog and Wiki <http://astrobetter.com>
Research Associate, American Museum of Natural History
Visiting Scholar, Flatiron Institute
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20250416/9c35efb1/attachment.htm>

From skoda at sunstel.asu.cas.cz  Wed Apr 16 23:11:35 2025
From: skoda at sunstel.asu.cas.cz (Petr Skoda)
Date: Wed, 16 Apr 2025 23:11:35 +0200 (CEST)
Subject: DER_SNR? 
Message-ID: <d538e33a-2190-75b2-bf47-77bba132951b@sunstel.asu.cas.cz>

Dear Kelle,

What spectrograph is it - echelle ?

The DER_SNR is a algorithm which is not only recommended in SDM (about 2008) 
but also in various spectrographs simulators... (e.g. MOES)
One of my student used it many years ago and it seemed to be able to work well 
in many cases os single order spectra ...

But it may be quite complicated in case of echelle spectra due to the blaze 
function (the SNR is varying along or individual orders).
The SNR will be also faked by pipeline reduction (e.g. dividing by extracted 
flat field to unblaze the echelle order)

The DER_SNR is working only in certain cases (described in the paper
https://adsabs.harvard.edu/full/2008ASPC..394..505S
the STECF newsletter paper does not exists probably - links at many places are 
bad.)

But despite this, it is so far the only one method that is reasonably general. 
But concerning the VO - it is the officially suported recommendation to use it 
in SDM

(in SDM1.2 it is chapter 5.3.1
https://www.ivoa.net/documents/SpectrumDM/20231215/REC-SpectrumDM-1.2-20231215.pdf


So IMHO it is correct to use this FITS KW as it directly maps to SDM in the 
recommended way.

Best regards,

Petr Skoda


On Wed, 16 Apr 2025, Kelle Cruz via dm wrote:

> Date: Wed, 16 Apr 2025 20:36:31
> From: Kelle Cruz via dm <dm at ivoa.net>
> Reply-To: Kelle Cruz <kellecruz at gmail.com>
> To: dm at ivoa.net
> Subject: DER_SNR?
> 
> Hi folks,
> 
> I'm working on a new data reduction pipeline and trying to get the output
> spectra to comply with SpectrumDM1.2.  I'm currently having a struggle
> convincing the team to use the "DER_SNR" FITS keyword to store the
> calculated SNR of a spectrum.  Some people are worried that using this
> keyword will imply that a specific algorithm was used to calculate the SNR.
> Specifically, this one: http://www.stecf.org/software/ASTROsoft/DER_SNR/.
> Anyone care to comment on this?
> 
> Thanks,
> Kelle
> 
> --
> Kelle Cruz, PhD (she/her, they/them)
> Assoc. Professor, Physics and Astronomy, Hunter College
> CEO, ScienceBetter Consulting, LLC
> CFO, Startorialist, Inc. <http://shop.startorialist.com>
> Editor-in-Chief, AstroBetter Blog and Wiki <http://astrobetter.com>
> Research Associate, American Museum of Natural History
> Visiting Scholar, Flatiron Institute
>

*************************************************************************
*  Petr Skoda                         Tel   : (323) 649201, l. 361      *
*  Stelarni oddeleni                          (323) 620361              *
*  Astronomicky ustav AVCR, v.v.i     Fax   : (323) 620250              *
*  251 65 Ondrejov                    e-mail: skoda at sunstel.asu.cas.cz  *
*  Ceska republika                                                      *
*************************************************************************

From skoda at asu.cas.cz  Wed Apr 16 23:04:58 2025
From: skoda at asu.cas.cz (Petr Skoda)
Date: Wed, 16 Apr 2025 23:04:58 +0200 (CEST)
Subject: DER_SNR?
In-Reply-To: <CAApiRV63Un2Nkapanfz4ZVQONpfh6SxnASswwUA6w8PAsG8pAg@mail.gmail.com>
References: <CAApiRV63Un2Nkapanfz4ZVQONpfh6SxnASswwUA6w8PAsG8pAg@mail.gmail.com>
Message-ID: <898fa280-f01a-4549-bdef-21f6d2a1000a@asu.cas.cz>

Dear Kelle,

What spectrograph is it - echelle ?

The DER_SNR is a algorithm which is not only recommended in SDM (about 
2008) but also in various spectrographs simulators... (e.g. MOES)
One of my student used it many years ago and it seemed to be able to work 
well in many cases os single order spectra ...

But it may be quite complicated in case of echelle spectra due to the 
blaze function (the SNR is varying along or individual orders).
The SNR will be also faked by pipeline reduction (e.g. dividing by 
extracted flat field to unblaze the echelle order)

The DER_SNR is 
working only in certain cases (described in the paper
https://adsabs.harvard.edu/full/2008ASPC..394..505S
the STECF newsletter paper does not exists probably - links at many 
places are bad.)

But despite this, it is so far the only one method that is reasonably 
general. But concerning the VO - it is the officially suported 
recommendation to use it in SDM

(in SDM1.2 it is chapter 5.3.1
https://www.ivoa.net/documents/SpectrumDM/20231215/REC-SpectrumDM-1.2-20231215.pdf


So IMHO it is correct to use this FITS KW as it directly maps to SDM in 
the recommended way.

Best regards,

Petr Skoda


On Wed, 16 Apr 2025, Kelle Cruz via dm wrote:

> Date: Wed, 16 Apr 2025 20:36:31
> From: Kelle Cruz via dm <dm at ivoa.net>
> Reply-To: Kelle Cruz <kellecruz at gmail.com>
> To: dm at ivoa.net
> Subject: DER_SNR?
> 
> Hi folks,
>
> I'm working on a new data reduction pipeline and trying to get the output
> spectra to comply with SpectrumDM1.2.  I'm currently having a struggle
> convincing the team to use the "DER_SNR" FITS keyword to store the
> calculated SNR of a spectrum.  Some people are worried that using this
> keyword will imply that a specific algorithm was used to calculate the SNR.
> Specifically, this one: http://www.stecf.org/software/ASTROsoft/DER_SNR/.
> Anyone care to comment on this?
>
> Thanks,
> Kelle
>
> --
> Kelle Cruz, PhD (she/her, they/them)
> Assoc. Professor, Physics and Astronomy, Hunter College
> CEO, ScienceBetter Consulting, LLC
> CFO, Startorialist, Inc. <http://shop.startorialist.com>
> Editor-in-Chief, AstroBetter Blog and Wiki <http://astrobetter.com>
> Research Associate, American Museum of Natural History
> Visiting Scholar, Flatiron Institute
>

*************************************************************************
*  Petr Skoda                         Tel   : (323) 649201, l. 361      *
*  Stelarni oddeleni                          (323) 620361              *
*  Astronomicky ustav AVCR, v.v.i     Fax   : (323) 620250              *
*  251 65 Ondrejov                    e-mail: skoda at sunstel.asu.cas.cz  *
*  Ceska republika                                                      *
*************************************************************************

From mathieu.servillat at obspm.fr  Wed Apr 23 23:33:15 2025
From: mathieu.servillat at obspm.fr (Mathieu Servillat)
Date: Wed, 23 Apr 2025 23:33:15 +0200
Subject: Call for contributions to Data Model Working Group sessions - College
 Park 2-6 June
Message-ID: <1d253deb-8a15-41a2-a551-bbde96b331a6@obspm.fr>

Dear IVOA members and DMers,

This is an invitation to submit contributions to Data Model Working 
Group sessions at the upcoming Northern Spring IVOA Interop meeting that 
will take place at the University of Maryland, College Park, US, June 
2-6 2025:
https://indico.ict.inaf.it/event/3121/

There will be *two plenary sessions* connected to DM topics :
 ? - ObsCore & Extensions (multi WG topic)
 ? - Data Models: modularity, levels, endorsement

There will also be *one or two DM sessions* to cover topics related to 
the current DM roadmap:
https://wiki.ivoa.net/twiki/bin/view/IVOA/2024BRoadmap#Data%20Model%20WG

Please respond to this thread if you would like to make a contribution 
to the sessions,

Best regards,

Mathieu & Mark

-- 
Dr. Mathieu Servillat
LUX - Laboratoire d'?tude de l'Univers et des ph?nom?nes eXtr?mes
B?t 18, Bur. 222
Observatoire de Paris, Site de Meudon
5 place Jules Janssen
92195 Meudon, France
T?l. +33 1 45 07 78 62
--


From mdittmar at cfa.harvard.edu  Thu Apr 24 23:03:20 2025
From: mdittmar at cfa.harvard.edu (CresitelloDittmar, Mark)
Date: Thu, 24 Apr 2025 17:03:20 -0400
Subject: DM Running Meeting notes - 20250415
Message-ID: <CAH4enyOZ+bJjyw7z-f1L-kQMhUuXdSd+M94H3sFeGW_6zrZoWw@mail.gmail.com>

All,

Below are our notes (mostly Mathieu's) from the recent Running meeting.

I'll post them to the Twiki shortly.


Participants:
   Pat Dowler (PD), Laurent Michel (LM), Fran?ois Bonnarel (FB), Mireille Louys
(ML), Mark CD (MCD), Mathieu Servillat (MS)



ObsCore:

     - Define the request to IGs from DM WG -- what do we need from them?
         - IG to prepare Endorsed Note (EN)
         - Include tables as in the ObsCore REC
         - Propose terminology, descriptions, and corresponding use cases
     - ObsCore v1.1 on Github status
         - https://wiki.ivoa.net/twiki/bin/view/IVOA/ObsCore
         - PD: will try to convert to ivoatex next week
         - The plan is to add sections in ObsCore for e.g. Radio Ext, and
refer to the RadioIG EN for justification and details
             - e.g. a table + 2 pages : can be included in ObsCore
             - the Notes can better address the effort of the interest group
 and capture the domain of knowledge for each extension proposed.
         - Relations with CAOM
             - PD: CAOM 2.5 will integrate Radio Ext
             - Implemented in SRCNet prototype (SKAO)
                 - group with Paul Harrison, using CAOM 2.5

                 - used CADC software for v2.4

         - IVOA Note by Markus to register tables
             - standardID in the TAPSchema as a utype for data discovery

             -
[
https://ivoa.net/documents/Notes/TableReg](https://ivoa.net/documents/Notes/TableReg)
             - rk: updated for typo on github

         - How to handle versions of ObsCore and extensions ?
             - versions may not be the doc version
             - e.g. : Core1.1 Radio1.0 (and doc v1.2...)
         - TCG plenary at next Interop (2-6 June)
             - opportunity to validate Endorsed Notes

         - HEIG workshop on ObsCore Extension (29-30 April)
             - https://indico.obspm.fr/event/2674

- ObsCore includes the ObsTAP stuff? which should be DAL.

  - PD: can shift emphasis from ObsTap? but will need some content
describing the expectation of doing a ?natural join? of the tables but for
DAP protocol, it would need to describe an equivalent.



Preparation for Interop:

  - Registration - most attending; not many in person

  - RoadMap

        - MANGO: LM waiting for green light on 2 issues.

  - epoch ? new issue

  - photometric properties ? see new issue.

         - CAOM 2.5 Integration
         - ObsCore/RadioExtension reconciliation
             - Port ObsCore 1.1 document to ivoatex
         - VO-DML 1.1
         - Cube 1.0
         - VOEvent 2.2

  - Call for Abstracts coming

        - Abstract submissions
        - ?Plenary? topics


Next Meeting: Tue May 20 @14:00 UTC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20250424/4a8802cf/attachment.htm>