Baseline use cases

[msdemlei]

I've always assumed the following has been the (rough) consensus agenda behind the effort, but I'm starting to realise that that is not necessarily the case, so I'm trying to raise the following (IMHO) baseline use case as an explicit issue.

"Let a client figure out non-VOTable metadata for a column independently of whether they are in a time series, a spectrum, or some generic table."

Examples (all assuming "if present in the table", of course):

• If I see an ra, figure out the corresponding dec
• If I have an ra/dec, figure out the reference system, the reference position, the epoch
• If I have a position, figure out an associated proper motion
• If I have any sort of quantity, figure out the/a error (and, eventually its sort, perhaps one day distribution paraemters, etc)
• If I have a flux or magnitude, figure out the band it's in, perhaps a zeropoint, etc.

Again, and that is important: Clients must not need to know a full data model (e.g., "timeseries") to do that. The rationale behind that is that client writers will curse us if they will have to re-implement "find an error for a value" again and again just because there's a new product type. And the data providers will curse us if they cannot annotate a value/error pair just because it's, say, a redshift and there's no "data model" for that.

I'll note here I will have a very hard time singing off to anything that does not show code that actually lets clients do these things and that will credibly make it to astropy and/or STIL.

I'll shamelessly link again to https://github.com/msdemlei/astropy, which is an astropy fork that can pull such information from annotation produced right now by DaCHS' time series code. An analogous astropy (or STIL, if you prefer) fork for the other proposals would really help to give me some confidence in them.

I'll freely admit that my fork clearly isn't ready for PR yet (it was hacked in 1 1/2 afternoons). But I claim, can be made ready for a PR with ~ a week of concentrated work, with write and programmatic annoation support possible in perhaps another week, and something like that would of course be enough to convince me of the other proposal's viability (as long as all the features proposed are exercised, which is particularly true for the SQL-in-XML part if you do insist on that).

Sorry for being a bit obstinate here, but I have apologised far too often that 20 years into the VO we still cannot give a reliable recipe for "what's the dec for this ra", and if we again fail to create that it would be a real shame.

After the introduction: Do people roughly agree these are use cases that our annotation, and the models, ought to support?

[gilleslandais]

I am agree that more simple is the output more it will be adopted by clients.
However, I don’t think that just gather a quantity with its error is enough – in the example I sent previously (https://github.com/ivoa/dm-usecases/wiki/mango) , I listed some examples of tables having columns with associated error, flags, ref..

why Mango ?
For me, the most important is that Mango is capable to expose measures – measure which can be composed by a column and associated columns like error, flags, etc. (and each measure even if it is a collection of columns is defined with a couple UCD+semantic – easily understandable by clients). It is well adapted for VizieR tables – enough generic also. Is it also adapted for other data-centers ?

With Mango, you can annotate with generic measure or you can use a DataModel (in my examples , I use the both: for position and photometry I use DM, and for other quantities GenericMeasure).
For me the question is more: what are the (trusted) DM expected in Mango ?

Note that I am not a fan of “everything in DM” because my feeling is that they are more complex to manage/parse – but a minimum why not ? (may be needed for photometry and always with the condition that nothing is required)

About complex structure (like timeseries): for me it is a bonus – possible with Mango!

You have an astropy version to parse vodmlinstance ? That is a good new - It could be use to demonstrate the benefit of the current work – could we imagine a mango extension possible :-) (limited in a first step to the Mango core) ?

[msdemlei]

On Fri, Apr 16, 2021 at 09:25:12AM -0700, gilleslandais wrote: I am agree that more simple is the output more it will be adopted by clients. However, I don’t think that just gather a quantity with its error is enough – in the example I sent previously (https://github.com/ivoa/dm-usecases/wiki/mango) , I listed some examples of tables having columns with associated error, flags, ref..

Yeah, but as I wrote there: we need concrete *use* cases to figure out if and how to annotate such columns. Annotation is there for clients, and if they can't do anything with the annotation, it's worse than useless (because it may lead to confusion when, at a later time, an actual use case is identified; cf. caproles). Let me try for these flag-like columns: (1) Error-like flags (e.g., "uncertain"). These should probably be dealt with in Meas; doing anything machine-readably with them might, however, be so hard that it may not be worth it. (2) For anything else, the only real use case I can imagine would be "When showing a subset of columns, show and hide this set of columns as one". This sounds like "presentation-oriented" annotation, for which we so far have to DM. Perhaps there should be one? What other cases are there for these groups? What purpose would the machine-readable annotation have for them? Oh, and also note that for VizieR-internal use (where interoperable clients can just look the other way) you can always add private annotation like, perhaps: ``` <INSTANCE dmrole="viz-pres:ColGroup"> <ATTRIBUTE dmrole="header" value="All about V mag"/> <ATTRIBUTE dmrole="group_leader" ref="vmag"/> <ATTRIBUTE dmrole="group_members"> <COLLECTION> <ITEM ref="vmag_quality"/> <ITEM ref="vmag_source"/> <ITEM ref="vmag_err"/> <ITEM ref="vmag_flag"/> </COLLECTION> </ATTRIBUTE> </INSTANCE> ```

why Mango ? For me, the most important is that Mango is capable to expose measures – measure which can be composed by a column and associated columns like error, flags, etc. (and each measure even if it is a collection of columns is defined with a couple UCD+semantic – easily understandable by clients). It is well adapted for VizieR tables – enough generic also. Is it also adapted for other data-centers ?

Well, if, as you say, machines should be aware of these things when processing a measurement, then I argue whatever it is should go into Meas -- if it's needed interoperably at all.

With Mango, you can annotate with generic measure or you can use a DataModel (in my examples , I use the both: for position and photometry I use DM, and for other quantities GenericMeasure).

Yes -- except I still don't understand what you win by saying "this is a special measurement that can have photometry metadata" over just attaching the PhotDM metadata when it's there to a normal Measurement. My usual question: what can a machine *do* with this extra annotation that it cannot do with just the PhotDM annotation?

For me the question is more: what are the (trusted) DM expected in Mango ?

You mean: what DMs can a client rely on? I am totally sure that no client can ever rely on any particular annotation in everything it sees. As I point out in https://github.com/msdemlei/astropy (look at the README), it's a lot better if clients look for annotation they need when they need it (and fail in a defined way when it's not there). And of course you can convey the notion of, say, time series in that scheme rather plainly (look at the time-series, md-proposal).

About complex structure (like timeseries): for me it is a bonus – possible with Mango!

...as with anything else currently discussed.

You have an astropy version to parse vodmlinstance ? That is a good

Well, not the gruesome 25-element proposal, but something with six new elements (MODEL and children should go, too: they're just INSTANCE-s, too). And yes, that's what https://github.com/msdemlei/astropy is. Again, see its README for how this intended to be used.

new - It could be use to demonstrate the benefit of the current work – could we imagine a mango extension possible :-) (limited in a first step to the Mango core) ?

Since I have doubts there is such a benefit, I'd love to look into this. What kind of functionality would you be interested in?

[lmichel]

I believe that the use-case agenda hasn't changed:

1. Showing whether MCT/PhotDM cover our need
2. Adopting a mapping strategy
3. Adopting a mapping syntax

Honestly, IMO putting forward a library prototype does not help that much for the discussion.

I won't rehash my argument in this post but I'll ask the true question which relates to the exact scope of the Markus's proposal.

The annotation block starts with a list of the models on which data are mapped.

• If that list contains Meas and Coord, clients will understand they can find both Meas and Coord instances in the mapping block.
• If that list contains Meas, Coord and Cube, clients will understand they can find Meas , Coord and Cube instances in the mapping.
  • They are is free to ignore classes of one of these models (likely Cube for the Markus's client)
  • The syntax is clean enough to easily retrieve any object by type or role or both (e.g. looking for POSITION instances within a CUBE). It's a matter of XPath.

This clearly shows that technically both approaches can live together.
I come to the conclusion that the real question asked by @msdemlei is to say whether the IVOA have to get ride of integrated models (CUBE, MANGO,..) or not.

• If YES: this must be set as a headline of the workshop.
• If NO: let's consider that both are valid and let's refine the syntax to facilitate the job for all.
  This question is not only a matter of annotation

[msdemlei]

On Mon, Apr 19, 2021 at 05:57:02AM -0700, Laurent MICHEL wrote: I believe that the use-case agenda hasn't changed: 1. Showing whether MCT/PhotDM cover our need 2. Adopting a mapping strategy 3. Adopting a mapping syntax Honestly, IMO putting forward a library prototype does not help that much for the discussion.

Well, it would for me; as I said, I cannot see at this point how ordinary clients will consume these complex data models *in the VO* (which is a slow and dirty place of long-lived services and clients) to satisfy these simple use cases. But if I get shown plausible ways how they can do that with a reasonable effort, I'll stop whining immediately. By the way, writing such a thing is effort well spent: After all, we're doing all this for the consumers, and seeing how they'll do the consuming in common cases is very informative all around (let me also mention that getting an impression of the ease of implementation is a good thing, too).

The annotation block starts with a list of the models on which data are mapped. - If that list contains `Meas` and `Coord`, clients will understand they can find both `Meas` and `Coord` instances in the mapping block. - If that list contains `Meas`, `Coord` and `Cube`, clients will understand they can find `Meas` , `Coord` and `Cube` instances in the mapping.

Oh... you mean, clients should go for the MODEL declarations? Frankly, I doubt that's a good idea, because a single model may contain all kinds of classes, and a model declaration as such doesn't tell you which of them might be used (since I've just played with it today, see ProvDM: what would a client learn from knowing there's ProvDM annotation in a VOTable?). Conversely, I'd be interested in your opinions about the API I'm proposing over at https://github.com/msdemlei/astropy (get_annotations(dmtype), iter_annotations()). Are you saying something like that won't work for MANGO? Or just isn't suitable?

- They are is free to ignore classes of one of these models (likely `Cube` for the Markus's client)

Well, I'd put it the other way round: They'll look at the annotation they need for a given task; and of course "my" client would look at cube annotation, too, when figuring out what to plot against what (say).

This clearly shows that technically both approaches can live together. I come to the conclusion that the real question asked by @msdemlei is to say whether the IVOA have to get ride of integrated models (CUBE, MANGO,..) or not.

This is *related* to the question I'm asking, yes. But I'd not worry about God models (note: Cube doesn't need to be one; if it just points to the dependent and independent axes and leaves the rest to other DMs, it'll be a very compact and tidy DM) if there is a clear way in which to satisify these basic use cases in spite of them, and with a clear vision of what happens if we do have a major version change in one of our fundamental DMs.

- If YES: this must be set as a headline of the workshop. - If NO: let's consider that both are valid and let's refine the syntax to facilitate the job for all. This question is not only a matter of annotation

I also suspect that entangled DMs cannot be fixed in the annotation, which is where the thread last October came from. But perhaps that is just me -- which is why some sample implementation would help me a lot. If entangled models can be done in a way that don't impact client operations for the use cases presented, there's not much I'm worried about (but I'm still rather convinced programmers like Lego bricks better than pre-assembled models). So, yes, I *would* propose "Bricks or Death Stars" as the workshop's headline.

[mcdittmar]

Markus, Have you looked at the implementations done so far? I feel that a lot of these questions are addressed there.

Again, and that is important: Clients must not need to know a full data

model (e.g., "timeseries") to do that. The rationale behind that is that client writers will curse us if they will have to re-implement "find an error for a value" again and again just because there's a new product type. And the data providers will curse us if they cannot annotate a value/error pair just because it's, say, a redshift and there's no "data model" for that. There is no 're-implement "find an error for a value" again and again'. With the model re-use, if you understand meas:Measure, you know where the errors are in any model that uses it. These examples become rather too trivial to be interesting...

Examples (all assuming "if present in the table", of course): If I see an ra, figure out the corresponding dec

these are part of the same instance, so if you've found the instance containing RA, you already have the DEC. pos = doc.find_instances(LonLatPoint)[0] ra = pos.longitude dec = pos.latitude

If I have an ra/dec, figure out the reference system, the reference

position, the epoch frame = pos.coord_sys.frame.space_ref_frame epoch = pos.coord_sys.frame.equinox

If I have a position, figure out an associated proper motion

I know Astropy combines the position and proper motion elements together in the same object.. So far, the models define no specific association between them. With 'Mango', you could have a Source with Position and ProperMotion as associated properties. In the rama package, it converts meas:Position to astropy SkyCoord whenever possible, so if there is an associated proper motion element as well, it could be incorporated into that instance.

If I have any sort of quantity, figure out the/a error (and, eventually

its sort, perhaps one day distribution paraemters, etc) I'm assuming you don't mean the ivoa:Quantity.. which is not something that would be grabbed individually prop = doc.find_instance(<any Measure type>) err_type = type( prop.error.stat_error )

If I have a flux or magnitude, figure out the band it's in, perhaps a

zeropoint, etc. This is a bit complicated by the fact that PhotDM is not tied into the other models, so there is no coordinate system which includes photometry metadata. That was a target of the SpectralDM work. Mango has a stub in place to work with.. prop = doc.find_instance(Photometry) band = prop.coord.coord_sys.frame.name zeropoint = prop.coord.coord_sys.frame.zeroPointFlux Re: Prototype library.. * Omar's rama package is a prototype library, available on GIT, uses standard VOTable parser to interpret the VOTable, and custom parser for the Annotation.. * it auto-converts Position and Time instances to astropy SkyCoord and Time objects when possible. * presents an API to the user (see above commands; and any of the example implementation pages) * as I mentioned in your other thread, has a similar front-end to yours. * often following the model class structure * but can be extended with helpers for convenience. * eg implemented in rama: conversion to astropy, plotters, shortcuts from cube axes -> data * I've always expected it to become publicly available once the model/annotation questions are resolved.. the way things are going, probably as a PyVO package. One of the questions I've had with the 'just search for what you are interested in' approach is illustrated in the standard_properties case: * Table with Master Source properties * Table with Detections (also Source instances) If I open that file and do sources = doc.find_instances(Source) I get ALL the Source instances.. master and detections.. there is very little that I can reasonably do with that. Same for many of the base elements pos = doc.find_instances(Position) returns all the Source positions, Detection positions, Target Position, possibly the Reference Position of the satellite, etc.. any Position in the file. The approach seems too loose for anything but the simplest cases.

[msdemlei]

On Tue, Apr 20, 2021 at 03:22:57PM -0700, Mark Cresitello-Dittmar wrote: Have you looked at the implementations done so far? I feel that a lot of these questions are addressed there.

Presumably not nearly the latest ones, more like Mango of a year ago and Omar's code as of Shanghai or so, and I have to admit I have lost track of what goes on where. Perhaps you could point us to the current version(s) of the packages you have mentioned? Having a concise overview over where to look (in which branches where applicable) is a good thing with a view to the workshop, too. Of course, I'd be particularly grateful if brief docs on solving the mentioned use cases (which clearly are not trivial, as evinced by the fact that we still can't do them 20 years in the VO) could easily be located.

[Bonnarel]

@msdemlei wrote

This is related to the question I'm asking, yes. But I'd not worry about God models (note: Cube doesn't need to be one; if it just points to the dependent and independent axes and leaves the rest to other DMs, it'll be a very compact and tidy DM) if there is a clear way in which to satisify these basic use cases in spite of them, and with a clear vision of what happens if we do have a major version change in one of our fundamental DMs.

Cube is much more than that, as far as I remember. Dependent and independent axes fit well with TimeSeries and Spectrum dataproduct types, but in ND Cubes all but one axes are independant and in event list everything is independant.
Important and different question : are the axes sparsed or regularly sampled ? event list are sparsed, TimeSeries may be, ND cubes are regular, etc...

• If YES: this must be set as a headline of the workshop. - If NO: let's consider that both are valid and let's refine the syntax to facilitate the job for all. This question is not only a matter of annotation
  I also suspect that entangled DMs cannot be fixed in the annotation, which is where the thread last October came from. But perhaps that is just me -- which is why some sample implementation would help me a lot. If entangled models can be done in a way that don't impact client operations for the use cases presented, there's not much I'm worried about (but I'm still rather convinced programmers like Lego bricks better than pre-assembled models). So, yes, I would propose "Bricks or Death Stars" as the workshop's headline.

Of course if you change one of the models the annotation will change and clients will have to adapt. But this is true wether the models are entangled or not. Or there is something I do not understand

[mcdittmar]

On Wed, Apr 21, 2021 at 3:57 AM msdemlei ***@***.***> wrote: On Tue, Apr 20, 2021 at 03:22:57PM -0700, Mark Cresitello-Dittmar wrote: > Have you looked at the implementations done so far? I feel that a lot of > these questions are addressed there. Presumably not nearly the latest ones, more like Mango of a year ago and Omar's code as of Shanghai or so, and I have to admit I have lost track of what goes on where.

I was referring to these workshop cases...

Perhaps you could point us to the current version(s) of the packages you have mentioned? Having a concise overview over where to look (in which branches where applicable) is a good thing with a view to the workshop, too.

Each of my implementation pages have a summary of the packages used, with pointers. e.g., https://github.com/ivoa/dm-usecases/tree/main/usecases/time-series/mcd-implementation

Of course, I'd be particularly grateful if brief docs on solving the mentioned use cases (which clearly are not trivial, as evinced by the fact that we still can't do them 20 years in the VO) could easily be located.

Perhaps my point is that with the data properly annotated to the current models, these operations become trivial. With the 'Death Star' approach, there is no 'figuring out' where something is, you simply follow the path (modulo API helpers). With the 'Bricks' approach, you have Coordinate A using FIELD x.. you have to find Measure B also using FIELD x. I'd be happy to put a page together that goes through that set of actions specifically, but I'm sure each is covered within the various cases (module position-propermotion maybe).

[msdemlei]

On Wed, Apr 21, 2021 at 06:37:48AM -0700, Mark Cresitello-Dittmar wrote: > Of course, I'd be particularly grateful if brief docs > on solving the mentioned use cases (which clearly are not trivial, as > evinced by the fact that we still can't do them 20 years in the VO) > could easily be located. > Perhaps my point is that with the data properly annotated to the current models, these operations become trivial. With the 'Death Star' approach, there is no 'figuring out' where something is, you simply follow the path (modulo API helpers).

But that's different each time depending on whether you have a time series, a catalogue, or yet something else, right? So, a client that doesn't know SparseCube but just PhotDM would be out of luck when trying to work out the, say, band of the magnitudes in https://github.com/ivoa/dm-usecases/blob/main/usecases/time-series/mcd-implementation/gavo_summary.md right? It is this kind of "new code per high-level DM" thing that I'd really love to avoid, because it will be hard sell on our clients (I'll mention again I'm only here because we failed to sell STC1). And it'll be an even tougher sell once we change the first basic DM and all these high-level DMs start to break.

I'd be happy to put a page together that goes through that set of actions specifically, but I'm sure each is covered within the various cases (module position-propermotion maybe).

Yeah, that would help me a lot. Just putting up the various steps I'll have to do until the code on the gavo_summary.md actually runs would give me a much better idea of what all this entails. But, frankly, what I'm really after is code that satisfies the precise use cases in the original issue: "use annotation X" if it's there, where X is Meas, Coord, or Phot -- and do that regardless of what "sort" of data one is dealing with.

[msdemlei]

On Wed, Apr 21, 2021 at 06:13:10AM -0700, Bonnarel wrote: @msdemlei wrote Of course if you change one of the models the annotation will change and clients will have to adapt. But this is true wether the models are entangled or not. Or there is something I do not understand

The question, again, is: When you change, say, Meas to Meas2, will this only break uses of Meas, or will it take Coord, Dataset, Cube, Spectrum and everything else with it? With entangled models, Meas2 will immediately mean Coord2, Dataset2, Cube2, Spectrum2, and so on, so a legacy client will no longer understand *any* annotation at all. It won't, for instance, find the reference system for a position, although if it found it and boldly interpreted it it would actually work. Client developers will not be amused. With isolated models, a client still can figure out that ra/dec is in ICRS even after a full Meas2 migration. It will still work fine for anything that doesn't require figuring out the errors. Overall: *much* better use experience in many common cases (and graceful failure in the others). Oh, and of course it's simple to provide Meas and Meas2 annotation at the same time, and it's straightforward to write clients to "use the best one"; see https://github.com/msdemlei/astropy#choosing-the-most-expressive-annotation for how clients would do that. Sure, you could have multiple annotations with entangled models, too -- but then you'll have a tag soup explosion, because you will have to repeat *all* annotations in *all* the God blocks, most of them identical except for the DM names. Annotators will now be amused.

[mcdittmar]

On Thu, Apr 22, 2021 at 3:56 AM msdemlei ***@***.***> wrote: On Wed, Apr 21, 2021 at 06:37:48AM -0700, Mark Cresitello-Dittmar wrote: > > Of course, I'd be particularly grateful if brief docs > > on solving the mentioned use cases (which clearly are not trivial, as > > evinced by the fact that we still can't do them 20 years in the VO) > > could easily be located. > > > > Perhaps my point is that with the data properly annotated to the current > models, these operations become trivial. > With the 'Death Star' approach, there is no 'figuring out' where something > is, you simply follow the path (modulo API helpers). But that's different each time depending on whether you have a time series, a catalogue, or yet something else, right? So, a client that doesn't know SparseCube but just PhotDM would be out of luck when trying to work out the, say, band of the magnitudes in https://github.com/ivoa/dm-usecases/blob/main/usecases/time-series/mcd-implementation/gavo_summary.md right?

No.. If you are starting at the top (SparseCube vs Mango), the path to the Meas would, of course be different. If you only understand Meas and PhotDM, you can ( if using the rama package ) mags = doc.find_instances( Photometry ) << find the photometry Measure band = mags[0].coord.coord_sys.frame.filter.name << band name of the PhotometryFilter * assuming photDM:PhotometryFilter if off the CoordFrame. This is always true, regardless of the data product in which the Photometry resides. You can do this because you know it is a Photometry type Measure, and therefore, the PhotometryFilter resides in the associated CoordFrame. If you only understand PhotDM (and not Meas), not sure how you found 'mag', but.. you can still find all PhotometryFilters filters = doc.find_instances( PhotometryFilter ) band = filters.name If there is only 1 filter, that must apply to your mag, otherwise you have some troubles.

[msdemlei]

On Thu, Apr 22, 2021 at 07:21:19AM -0700, Mark Cresitello-Dittmar wrote: On Thu, Apr 22, 2021 at 3:56 AM msdemlei ***@***.***> wrote: > On Wed, Apr 21, 2021 at 06:37:48AM -0700, Mark Cresitello-Dittmar wrote: If you are starting at the top (SparseCube vs Mango), the path to the Meas would, of course be different. If you only understand Meas and PhotDM, you can ( if using the rama package ) mags = doc.find_instances( Photometry ) << find the photometry Measure band = mags[0].coord.coord_sys.frame.filter.name << band name of the PhotometryFilter * assuming photDM:PhotometryFilter if off the CoordFrame.

Can I see this in a complete script? I'm wondering at the moment where the Photometry symbol comes from.

If you only understand PhotDM (and not Meas), not sure how you found 'mag', but.. you can still find all PhotometryFilters filters = doc.find_instances( PhotometryFilter ) band = filters.name If there is only 1 filter, that must apply to your mag, otherwise you have some troubles.

I hope you'll understand that this statement unnerves me a bit given we're talking about the solution to our 20-years-old coordinates troubles here... So, why not attach the PhotometryFilter directly to the magnitude? It's clearly more robust and works just as well, no?

…

-- Markus

[lmichel]

@msdemlei

But if I get shown plausible ways how they can do that with a
reasonable effort, I'll stop whining immediately.

I spent last 2 days on an implementation aiming at satisfying your request . This implementation, based on Mango, can be used at different model friendships levels.
1- Doing nothing with the model
2- Just take the frames/filters in the globals, as you do.
3- Picking MCT instances by exploring the map of the MANGO parameters as I suggested for you.
4- Get the binding between model leaves and fields (e.g. pos + error is mapped on columns 2, 3, 9). That way, clients can read the data with their usual APIs and provide on demand data counterpart onto the model. This is close to what you are doing as well.
5- Directly getting data rows as model instances. I know that this way to proceed won't replace what is working very well so far, but I bet it will be attractive when data will get more complex (e.g. multiple objects in one table, joint data tables)

[lmichel]

@msdemlei

Conversely, I'd be interested in your opinions about the API I'm
proposing over at https://github.com/msdemlei/astropy

My opinion is that we roughly agree on HOW to consume annotated data

• having getters (selectors indeed) parametrized with model elements (or mapping keys).
• I presented such API in JAVA in a TDIG session at Victoria (AFAR)

but we definitely disagree on WHAT to consume.

• e.g. Cube instances vs sparse sets of properties

[mcdittmar]

if you only understand Meas and PhotDM, you can ( if using the rama package )
mags = doc.find_instances( Photometry ) << find the photometry Measure
band = mags[0].coord.coord_sys.frame.filter.name << band name of the PhotometryFilter
* assuming photDM:PhotometryFilter if off the CoordFrame.

Can I see this in a complete script? I'm wondering at the moment where the Photometry symbol comes from.

The Standard Properties case: Annotated CSC file
The file has several PhotometryFilter bands, and FIELD 'col15' annotated as a meas:Photometry instance from EB1.
NOTE: These PhotometryCoordSys elements point to the PhotometryFIlter instances as per the models.

  <INSTANCE dmtype="mango:coordinates.PhotometryCoordSys" ID="_photsys_EB1">
  <INSTANCE dmtype="mango:coordinates.PhotometryCoordSys" ID="_photsys_EB2">
  <INSTANCE dmtype="mango:coordinates.PhotometryCoordSys" ID="_photsys_EB3">
  <INSTANCE dmtype="mango:coordinates.PhotometryCoordSys" ID="_photsys_EB4">

          <INSTANCE dmtype="mango:measures.Photometry">
            <ATTRIBUTE dmrole="mango:measures.Photometry.coord">
              <INSTANCE dmtype="mango:coordinates.PhotometryCoord">
                <ATTRIBUTE dmrole="mango:coordinates.PhotometryCoord.luminosity">
                 <COLUMN dmtype="ivoa:RealQuantity" ref="col15"/>
                </ATTRIBUTE>
                <REFERENCE dmrole="coords:Coordinate.coordSys">
                  <IDREF>_photsys_EB1</IDREF>
                </REFERENCE>
              </INSTANCE>
            </ATTRIBUTE>
          </INSTANCE>

Python Script:

#!/usr/bin/env python
from rama.reader import Reader
from rama.reader.votable import Votable
from rama.models.mango import Photometry

infile = "ivoa_csc2_example_annotated.vot"
doc = Reader( Votable(infile) )

flux = doc.find_instances(Photometry)[0]
band = flux.coord.coord_sys.frame.name

print("Flux: {} [band: {}]".format( str(flux.coord.luminosity[0]), band) )

Produces:
Flux: 1.7599881487057e-14 erg/s/cm^2 [band: CHANDRA/ACIS.broad]

Summary:
The rama package interprets the annotation and generates python classes.
As far as accessing the instances and using them goes, it makes NO DIFFERENCE, if the Photometry data is in a TimeSeries, Source, or are stand-alone. The package finds the nodes annotating the class and returns the instances.

If you only understand PhotDM (and not Meas), not sure how you found 'mag', but.. you can still find all PhotometryFilters filters = doc.find_instances( PhotometryFilter ) band = filters.name If there is only 1 filter, that must apply to your mag, otherwise you have some troubles.

I hope you'll understand that this statement unnerves me a bit given we're talking about the solution to our 20-years-old coordinates troubles here...

What is unnerving? The model associates the 'col15' flux Measure with the proper PhotometryFilter. With that relation defined, finding the band becomes trivial, without it there is. no way to know which of the 4 bands is relevant.. you really can't do it.

So, why not attach the PhotometryFilter directly to the magnitude? It's clearly more robust and works just as well, no?

That could be done, but the models try organize the concepts. The PhotometryFilter is not a direct property of the Photometry Measure, but rather associated metadata on the environment which produced the value. This sort of information is relegated to the associated coordinate Frame in all Measures.
I could certainly see adding a helper method to the Photometry class which short-cuts this for users.