msdemlei
commented
1 year ago On Fri, Jul 08, 2022 at 10:29:17AM -0700, Mark Taylor wrote:
So I would like to introduce a new optional column in the links response table (I don't know what's the best name - "
type_code"?) into which services can place a suitable identifier (meaningful only within that service). In my Gaia DR3 example, all XP Sampled spectra could have the value "1", all RVS spectra "2", etc.
This sounds reasonable to me, although I'm not so wild about the term "type_code", which combines two of the most overloaded terms in IT. Actually, I can top this: resource_type_code.
More seriously, what this should be is an identifier to build correspondences between rows in different datalink responses from the same service. So, in a way, having "correspondence" in the name would be nice, except that's too many chars to type and too many letters to print in table headers an the like. In particular, when one would write "correspondence_association". Perhaps "corr_assoc"? Or "assoc_id"?
"cross" is nice and short, and since it's an identifier: "cross_id"? But that would sound a bit as if it were a true foreign key, which this is not (mainly because there are many tables, and they're all peers).
In the end, what I'm least unhappy with at this point would probably be:
column name: local_semantics type: text UCD: meta.id.assoc description: An identifier that allows clients to associate rows from different datalink documents on the same service with each other.
I've briefly thought about making this an int, but that would greatly increase the risk of creating collisions between local_semantics of different services. These aren't bad in theory (they're local identifiers, after all), but in practice there will be bugs, and these will make clients try to correlate responses from different services. Having "bp spectrum" rather than "1" here will give some resilience here.
A very relevant point, though: I think to make this work as Mark imagines it, we have to require that within each document, a local_semantics value must not occur twice, as otherwise a client would still be confused about which row to choose.
Well: Should we take this to the DAL list?
mbtaylor
Bonnarel
jd-au
I would like to be able to identify "corresponding" rows in the DataLink tables associated with different rows of the same catalogue.
Example: a user looks at a DataLink table for a row from the Gaia DR3 source catalogue. They choose to plot data from the row corresponding to the XP Sampled Spectrum. They then choose a different source catalogue row, and are likely to want the XP Sampled Spectrum again. But there is currently no reliable mechanism for the client to identify the row in the second DL table (if any) that's "the same as" or "corresponding to" the row the user selected in the first DL table. At present I'm hacking round this in topcat by matching parts of the
semanticsanddescriptioncolumns. I identified this issue in my Datalink Feedback presentation at the Victoria 2018 Interop (see the slide marked 7/8 "Row Correspondance"), but I don't think it's made it into a github issue till now.So I would like to introduce a new optional column in the links response table (I don't know what's the best name - "
type_code"?) into which services can place a suitable identifier (meaningful only within that service). In my Gaia DR3 example, all XP Sampled spectra could have the value "1", all RVS spectra "2", etc.