International Virtual Observatory Alliance

Difference: TCGf2f20251113 (5 vs. 6)

Revision 62025-11-13 - TomDonaldson

  META TOPICPARENT 
  name="IvoaTCG"  

 TCG Meeting - face-to-face - November 13 2025 @ 14:30 (Görlitz, Germany timezone) / 13:30 UTC 


 
  TCG Meeting - face-to-face - November 13 2025 @ 14:30 (Görlitz, Germany timezone) / 13:30 UTC 
 
 
  Attendees
 
   Actions
   Agenda
 
 


 Attendees 
 

 Attendees :
 
 

 Regrets :
 
 

 vconf link: zoom room
- META TOPICPARENT
+  name="IvoaTCG"
-<
<
+ New vconf link: https://caltech.zoom.us/j/6836876983
->
>
+ New vconf link: https://caltech.zoom.us/j/6836876983
  Actions 
 
 OPEN - put together a template for call for proposals; model after DAL (postponed)
  NEW - (ALL) brainstorm within groups about contributing to the data model usage hack-a-thon/workshop proposal (OPEN but postponed)
  NEW - put issues on DocStd git repo and work towards a F2F meeting with TCG (interop?) (ongoing)
 

 Agenda 
 

 Review actions
 
 

 IVOA Northern Fall November 2025 Interoperability Meeting 
 Görlitz (Germany) - starting tomorrow 
 program: InterOpNov2025 (program preparation: ProgramPrep2025B)
  website: https://indico.ict.inaf.it/event/3325/
  ADASS XXXV website: https://indico.dzastro.de/event/4/
 
  quick final review of the scheduled sessions
  highlights
->
>
+Ops highlight: What are people seeing with respect to bot volume? Increasing due to AI? Discuss impacts including cloud service costs. If authN is used to respond, can we think about client testing paradigms?
  expected interop outcomes
->
>
+Please present your expected outcomes, then update your roadmaps during the meeting if possible.
  (standing item): documents on track 
 RFC 
 VOEvent-2.1 - RFC page 
 recap status and agreement on not overdoing RFCs
 
  StandardsRegExt-1.1 RFC page: REC as of 2025-10-20. Thanks everybody! 
 simple bullet to check the REC is visible from the repo
 
  MANGO-1.0 RFC page: RFC status
->
>
+Please review. The pyvo implementation is merged as a prototype and will be released this week.

As a provider, please consider an implementation so that we can exercise it more to find more issues.

Simbad working on annotating TAP results using vollt (which is used across multiple providers)

Aladin can consume coords and movement.

Discussion of implementation coverage...
  DALI-1.2 RFC page: summary & start review
->
>
+Mostly claraification of ambiguities and several new xtypes. Also a few OpenAPI things which will feed into the next TAP spec which will use OpenAPI. The OpenAPI files end up in the doc repo. They are currently versioned with time stamps, but we should discuss that (towards an unversioned shared URL).

... could be like vocabularies and be referenced by http ivoa.net URIs.

We could put these in the registry, but that would only be useful if the reg is used for standard discovery.
  DocRegExt -1.0 RFC page: summary & start review
->
>
+MD: Hope this is quick. This is about putting education-related things (like a tutorial) into the registry. Started with a note a while ago. There is a service called VOTT that collects these. This turns the note into a REC. Doesn't have impact on things that are not registry or education.

Question about maintenance: Are these things reviewed and how do we know if they get stale? Yes they are reviewed and the date is recorded in the registry. Docregext has a source link which could help one address aging things. Detecting things that are broken is difficult. If there is CI for the resource, we could ptotentially reference ofr badge those. As with many resources, these require some human mainenance/curation...more extended discussion...
  EN 
 DataOrigin -1.1 in in PEN status ( PEN doc): review and/or vote
->
>
+Clarification that this should be v1.2. This should be fixed in the PEN doc.

Question about the difference between Note and Endorsed Note. Why should this be an EN?

This stuff should be reference from DALI. It would be formally wrong to reference an unendorsed note.

The context of the INFO element changes with respect to DALI are difficult to see.

This is lighter-weight than an RFC, and also would need to be adopted by a WG. It's not in DALI proper because its content may change more quickly than DALI.

More discussion is needed to clarify the differences between the EN and RFC processes.

Question on the table: Do we want an RFC instead on this doc?

- Not risky with respect to programmatic interoperability since it's mostly human-oriented

MCD: Relationship to DMs means that I care a lot for an RFC, less for a PEN and not so much at all for a Note. Would like to clarify more the differences between PEN and RFC. Hope to take it up in the process meeting on Sunday or at next TCG meeting.

PD: DALI could really only say MAY which they can already do anyway.

MD: SHOULD means there would be a validator warning for non-compliance which would actually be helpful, at least for a few pieces of central metadata.

MM: Is it late for DALI 1.2?

PD: Adding a paragraph saying what you can do is not a problem. Not sure if we can pick out some specific things for SHOULD. Someone SHOULD make a comment on the RFC. 😃
  Errata 
 foreseen a SimpleDALRegExt one (clarifying references to ConeSearch)
->
>
+(Please add Errata, notes, etc. to the TCG page when you start them to help ensure they end up here.)
  VEPs 
 VEP-018? 
 exists only as "new", maybe too early
 
  vocabularies (only if news to report) 
 Calibration levels ( DRAFT)
  Object types ( DRAFT)
  https://github.com/ivoa-std/SLAP2/pull/1 -> UCDs (https://github.com/ivoa-std/SLAP2/pull/1)
  "vocabularize" UCDs
 
 
 
 
 

 looking at roadmaps: 
 Apps & tessellation formats: ecosystem status
->
>
+Several presentations in Apps on tesselation
  DAL: DALI-1.2 in RFC, what's next
->
>
+More and more use of OpenAPI. TBD, not sure if we want to continue with the current UWS API. Might want to trim it down.

JF: His implementation of UWS was more forward-looking and is a good reference rather than starting of a description. Agree with Pat on the possible trimming of UWS.

SG: IRSA is using JF's UWS spec in their ops.

Would be nice to sit down together to decide direction. Will try to arrange a hybrid splinter during this meeting (~0.5 hours).
  DM, and HE, Radio, TD: ObsCore update and extensions expectations 
 + too many activities to follow?
 
  DSP: ExecutionBroker & VOAuth (100%?)
  Registry: simulations & registry + uptake of tesseled-discrete coverages
  Semantics: internals (VEPs, vocabularies, UCDs) & externals (SPASE and general ontologies visibility)
  (IGs: I'm not skipping your roadmaps, just trying to let everybody be aligned)
->
>
+MD: Request to remove old unused standards (like CDP) from doc page (move to Obsolete IVOA Documents table). Also file an issue against the architecture diagram to remove them.

MCD: Candidate may be SpectralDM 2.0 (not previous versions)

SG: There may be other docs which appear to be progress but really aren't.

JF: Perhaps someone can remove the “VO Query Language” entry from the IVOA wikipedia page while we’re at it? https://en.wikipedia.org/wiki/International_Virtual_Observatory_Alliance 😃
  Docrepo/archdiag triage: Have a look at what standards should be moved to the obsolete section and make sure we drop them from the architecture diagram, too (exampless: LineTAP, perhaps CDP...)
  (long standing topics reminder) 
 astronet.ru 
 MM will report last vconf decision at Exec (in a couple of hours)
 
  positions still TBF: Radio IG vice-chair role is open
  new website: report
  IGs & TCG/CSP interfacing
 
 
 

 Try to prepare your roadmaps ( 2025BRoadmap) during the meeting 
 or: suggest a better way to build Roadmap(s)
 
 
 

 Date for the next TCG 
 what about a last vconf in 2025 to wrap up Görlitz? does Thursday 11 December @ 21 UTC sound good?
 
 

TCG meeting dates, as well as other relevant meetings, should always be reported also at the IVOA Events page.
-<
<

View topic | History: r6 < r5 < r4 < r3 | More topic actions...