DM Running Meeting Notes: 20250218

[CresitelloDittmar, Mark]

All,

  Thanks for another very productive meeting!  Lots of attention on ObsCore
Extensions this time.
   Lots of good work going on!  Mango has made a lot of changes, it'd be
VERY helpful to give that
   a read/review, even if you've done so before.

Mark


Participants:
  Mark Cresitello-Dittmar (MCD),
  Mathieu Servillat (MS),
  Paul Harrison (PH),
  Mark Taylor (MT),
  Bruno Khelifi (BK),
  Gerard Lemson (GL),
  Jesus Salgado (JS),
  Mark Kettenis (MK),
  Renaud Savalle (RS)

  Contributions by email:
    François Bonnarel (FB)
    Laurent Michel (LM)

Open Action Summary:
  New actions

  Carry-over actions
  * [PH] vo-dml 1.1 candidate list
     - deliver summary of update candidates to DM mail list, (can reference
git issues).
       Please organize by the threads they support.
     - set a timetable for steps moving forward, and send this to MCD/MS
for the roadmap.
     STATUS: In progress.. working twiki page (
https://wiki.ivoa.net/twiki/bin/view/IVOA/VODML_1_1)
  * [MS] schedule ObsCore/Extension cross-group coordination meeting.
      - This may wait for the next Radio Interest Group internal meeting to
review
        'the plan' to move forward on the [Endorsed] Note, and then the
relevant
        working groups pick up content to integrate into the relevant
standards.
        At that point, it'd be good to have a meeting with RIG, TDIG, HEIG
to
        help define the paths each should take in producing content
relevant to
        those domains.  i.e.: what should they be producing for the next
interop.
  * [MCD] bring the 'Shape' discussion to the DM mail list, with a goal to
      gain consensus on where this model element should live in the DM
ecosystem
  * [MCD] bring vo-dml 'version' attribute to DM mail list for discussion..
      at least to form a plan IF the attribute is, in fact, needed for
upcoming
      vo-dml standard updates.

Agenda Topics:
ObsCore extensions from Interest Groups
  [MS] provided review of the HEIG meeting discussion, highlighting that
there
       is a large percentage of the Radio Extension candidates that applies
to
       the HEIG domain as well.  The HEIG will continue their work,
focusing on
       the domain specific extension items and any missing concepts in the
       ObsCore + 'common extension items' set.
       The DMWG job is to review the proposals, sort common elements, and
work
       the Standard updates.
       The DAL WG should perform a complimentary review for the procedure
for
       accessing ObsCore Extensions.
       Question: Who is editing this work?

       [MCD] It is unclear, to me, that the radio group is OK with the goal
of
       delivering an Endorsed Note, rather than Standards updates..
          o [MS] points out that the recent FB email suggested just this.
          o [MK] agrees that is one path.. Q: what happens with the truly
Domain
                 specific extension elements?
                 o [MCD] the DM group should review the Note and provide
feedback
                   on the structure, to facilitate the migration from Note
to Standards.
                   e.g. the "common" candidates should be separated from
the "domain-
                   specific" candidates.
                 o [MK] we should probably discuss at the TCG level
(especially the
                   question on how to discover extension content.  These
portions
                   of the Note will need to be picked-up by the appropriate
group.
                 o [MK] RIG is holding a 'local' meeting to discuss the
path and
                   see if this works from their 'client' perspective.  They
will
                   keep us informed on the outcome.
       [JS] Reminder that extensions should be *extensions*... and not
modify
            existing content.  We must be mindful NOT to break existing
            implementations.
            ** general agreement that we MUST consider the impact on
implementations **
       [MS] What is the status of the ObsCore Standard?  Is there a
plan/action
            to port this to the ivoa-std repository?
            o [PD] Porting the ObsCore standard it ivoatex is a TODO item
            o *ACTION*: Create repository in ivoa-std for this project.
       [MS] Extension implementation.
            Markus has updated DaCHS to the radio extension content
(incomplete,
            but many).. this is the JIVE implementation FB references.
       Question: What does Endorsed Note mean?
         o [MCD] interprets as being a path for handling the use case,
which
           the IVOA supports, and perhaps encourages others to follow.
But,
           as a Note, is subject to change in any Standards updates to
handle
           the supported cases.
          o [PD] as Endorsed, providers would/could start reviewing how to
populate
            the ObsCore elements in their databases.  This could give them
a
            running start in providing implementations for the ObsCore
standard
            update.  This would be helpful, it is always the hardest part.
          o [MK] if we publish the Note and people develop to that, the
same
            problem of breaking implementations occurs if/when things move.
              - if we only include the domain specific items, that would
still
                provide benefits over ObsCore 1.1.
   ** Follow-up: HEIG could use help identifying exactly what they are
to produce
for the next interop.

MANGO Update
  There has been a lot of activity since the last meeting addressing Issues
  submitted by MCD and MT.  LM has sent an email summarizing the status of
  update, along with Issues which remain open and why.
  o [MT] It's looking better than it was.  The prototype in TopCat shows
proof-
    of-concept of annotating data to support the epoch propagation use case.
    Will update the implementation when new sample files are provided.
  o [MCD] restatement of concern..
       EpochPosition is a 2nd mode of representing content which can be done
       with the Measurement types.  This is generally considered bad
practice.
       I would be MUCH happier with the object if it were associated with
       GAIA data, more than the "Epoch Propagation" use case.  i.e. that it
       is an object which supports the very complex GAIA (or GAIA-like) data
       which the Measurements model is currently unable to support.
       That would give providers/clients a more clear picture of WHEN to use
       this Object over the PhysicalProperty representation.
  o [MCD] my current focus is on making sure that there is proper
documentation
    of the model coverage in implementations so things can move forward.
  ** I may be reading into things, but I felt there was a general agreement
that
     the object IS very GAIA-based and that may not be a bad idea.

CAOM Integration
[PD] We conducted a focus meeting last week which covered some of the lower
level
CAOM/VO-DML topics:
  o extraction of datatypes from CAOM, and importing them in CAOM (e.g.
Shapes)
  o schematron warnings for open-ended multiplicities which is 'strongly
discouraged'
    but is really hard to do polygons without that.  CAOM needs a Polygon
model
    so implementations have the same data structure for certain use cases.
    o [GL] has been working a lot of polygons (geolocation) and there are
standard
      formats for polygons (strings) which are useful for databases
    o [PD] format is reflecting the data model, and we want the same data
structure
      for interoperability.
    o [GL] depends on the purpose of the object.. perhaps a standard string
is
      enough, similar to datetime.
    o [PD] we do have a string format in DALI.. but that doesn't have a
model
      backing.  There are some things which require the structure to be
implemented
      the same way.
    o <discussion between PD, PH, GL>
        - PH is opposed to removing the schematron check, it is valuable to
          know that the practice is strongly discouraged
    o [GL] real, integer vs long, int, double, float.. we don't specify
that as
      this is a serialization issue, outside the model concern.

Next Meeting:
  Mar. 18, 2025 @ 15:00 UTC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20250220/251d5c48/attachment.htm>