<div dir="ltr"><div class="gmail_default" style="font-size:small">This looks like a useful feature. Am I right in seeing this as a way to disambiguate where there are multiple links with the same {ID,semantics}? <br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">If that's the case/intent, does it have to completely disambiguate? Does {ID,semantics,local_semantics} have to be unique? I'm not sure that's necessary and don't know what we would tell providers to do if they can't make the tuple unique... <br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br clear="all"></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div>--<br></div><div>Patrick Dowler<br></div>Canadian Astronomy Data Centre<br></div>Victoria, BC, Canada<br></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 22 Aug 2022 at 23:43, Markus Demleitner <<a href="mailto:msdemlei@ari.uni-heidelberg.de">msdemlei@ari.uni-heidelberg.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi DAL,<br>
<br>
On Fri, Aug 12, 2022 at 09:54:27AM +0100, Mark Taylor wrote:<br>
> So I'd like to see an additional column to facilitate this.<br>
> Markus has suggested the following definition for such a column:<br>
> <br>
>    column name: local_semantics<br>
>    type: text<br>
>    UCD: meta.id.assoc<br>
>    description: An identifier that allows clients to associate rows from<br>
>       different datalink documents on the same service with each other.<br>
> <br>
[...]<br>
> <br>
> Any comments?  Assuming some agreement or lack of disagreement is<br>
> established here about the general idea and specifics, then if<br>
> at least one data provider implements this I will add code in<br>
> topcat to make use of it.<br>
<br>
I think it's a good thing to have that, and in my book it's fairly<br>
orthogonal to semantics (or any other feature we have in datalink so<br>
far).  Hence, I've put it into DaCHS (SVN only so far; DaCHS<br>
operators: if you want this, let me know and I'll make a beta<br>
release), and I've taught a service where this looks reasonable to<br>
spit out local_semantics.<br>
<br>
That's PPAKM31, a service giving narrow-band maps of HII regions in<br>
M31 from cubes (reference URL:<br>
<a href="https://dc.zah.uni-heidelberg.de/browse/ppakm31/q" rel="noreferrer" target="_blank">https://dc.zah.uni-heidelberg.de/browse/ppakm31/q</a>); the datalink<br>
essentially links together the maps in the various bands extracted<br>
from each cube, and hence the local semantics is just an (opaque)<br>
label with the band info.<br>
<br>
To try this, go to the TAP service at <<a href="http://dc.g-vo.org/tap" rel="noreferrer" target="_blank">http://dc.g-vo.org/tap</a>> and<br>
execute:<br>
<br>
  select accref, imagetitle, cube_id  from ppakm31.maps<br>
<br>
In TOPCAT, you can then configure an activation action "Invoke<br>
Service"; the default "View Datalink Table" is fine.  When you then<br>
activate a row, you will see the local_semantics column already in<br>
non-aware TOPCATs.  Mark's proposed functionality would then let<br>
people say "whatever band I'm actually looking at, I always want the<br>
[OIII]5007 image of the field in my extra datalink window".<br>
<br>
Which, I'd say, is a highly reasonable thing to want.<br>
<br>
So... you'd totally have my support for adding this to a<br>
Datalink-1_2-Next page on the Wiki.<br>
<br>
          -- Markus<br>
</blockquote></div>