# participants = 47
This text is intended as a starting point for the discussion.
We will edit the text together during the session and then transfer the final version back to the IVOA wiki afterwards.

*Topics to discuss 

Dave Morris: Main goals of the session
    Step 1: accept Latex version
    Step 2: new changes
	    PR on GitHub to add requirements from SSIG
	
	Baptiste  describes the needs of the SSIG:
	1. target name as a locatoin (asteroid, solar wind...)
	2. planetary body ref. frame (Jupiter,... using IAU name convention)
	3. time range
	
	Rob Seaman - Support for IAU ADES (Astrometry Data Exchange Standard)? https://github.com/IAU-ADES/ADES-Master
	
	Also see PDS4 (https://pds.nasa.gov/datastandards/about/)
	
	Matthew Graham - The Jovian example includes times in ISO format; does that make any sense? Would you want to have a local Jovian timeframe defined as well?

	Matthew Graham - If you remove the list of valid identifers, how do you validate an arbitrarily defined AstroCoordSystem presented in a VOEvent? What other horrors from the full STC spec could be used?
	B: have brokers decide what a valid coord is
	M: big tech change
	B: vocabulary maintained by the semantic group 
	M: if we add a validator that adds some latancy that you don't want 
	
	Markus Demleitner: The validation would probably use the (currently draft) voca bulary of reference frames, http://www.ivoa.net/rdf/refframe.  We'd add a toplevel term solarsystem (or so), and then actual planetary systems (with proper references!) as they are used.
	
	
	
	Matthew Graham: But I want to define my own reference frame and use that in VOEvents
	Roy Williams: My parser will only deal with the frames it understands.
	Matthew Graham: But the standard would allow me to do this which seems unnecessary if what you want is a large curated vocabulary
	VOEvent inherits the coordinate handling from STC. Modify that first.
	VOEvent uses a subset of STC
	An intentionally large subset of STC
	But one that did not break code generation which full blown STC did
	The schema is a much smaller part of STC than the normative document...there are parts of STC that are largely irrelevant to describing observational data, but anything in an <ObsDataLocation> is a-ok.
	
Dave mentions FRB VOEvent cat :https://arxiv.org/abs/1710.08155
GitHub for VOEvent:  https://github.com/ivoa-std/VOEvent/

Roy Williams: Is VOEvent Transport Protocol part of the standard? I would much rather use Kafka. Your comments welcome.

John Swinbank: It is a different standard. VOEvent itself is intentionally transport agnostic.

Baptiste: Links for tools and services need to be checked in the document since sometimes they don't work. 
Matthew Graham. SkyAlert does not exist operationally anymore


Dave: 
    Findable: No registry on VOEvents - VOEventRefExt, is anyone using it?
    Accessible: <what> ok, <why> not so much
    Interop. Yes
    Reuseable No, but if we add url to VOEvent?
    
    For Reusable: in Solar System, we have a TAP service coupled with VOEvent stream, so that we can reuse. I can prepare a note to explain this. Let me know.

DM: Filtering (R<19...): do VOEvent brokers support that? 
    MG: Not VOEvent brokers
. But all ZTF alert brokers support this type of filtering

    JS: Comet supports filtering https://comet.transientskp.org/en/stable/filtering.html

    RS: The word “broker” has evolved to include filtering engines like ANTARES, etc. The original notion as being described here of an elaborated network of brokers is something else.

DM: Streams
    
    
    footprint would already be covered by mainstream registry, even for solar system, once we have the respective frames in. cf. http://docs.g-vo.org/talks/2019-adass-regstc.pdf
    
    Filtering by footprint, space, but also time?
    ST-MOC for prediction & retrospectively 
    
    Markus' appeal: keep it simple, at least for now.  As long as there are <100 resources, I'd argue for most realistic cases it's fine if people can just say "give me all VOEvent streams there are", perhaps with a bit of fulltext constraints (or otherwise standard VOResource).Andy L: I agree with this point. The key point is not to miss anything; filtering on the characterstics of the streams is probably overkill for now.  I volunteer to put in a chapter saying just that into the VOEvent document itself.  Just ping me (Markus Demleitner).
        
Voevent registry Extentions should include aggregating-brokers in addition to VOEvent authors, since their event stream has genuine information (based on their aggregation strategy)