ObsCore's data_rights and VODataService - broken reference

[Dubois-Felsmann, Gregory P.]

Hi, Markus,

Thank you for the rapid reply!

Pinning the VODataService version to 1.1 in an erratum sounds reasonable.

Regarding the three-value data model, my mostly Rubin- and IPAC-oriented take on the problem is this:

* The distinction between "public" and "secure" seems quite meaningful, especially since the "must log in just to identify yourself" approach to things is becoming more and more common, even for non-proprietary data.
* However, I have a hard time understanding when it would be of great use *from row to row* in an ObsCore (SIAv2 or ObsTAP) query result.  I suspect that it will be far more common for it to be a service-level choice whether public (non-proprietary) data are available for anonymous access or only to known users.  So, in the absence of the inertia from an existing standard, I'd have assumed that a "must log in to do anything"-vs-"anonymous OK" flag would be part of a service's self-description and its Registry record.
* I do think a simple flag that says "you may or may not be able to access this dataset depending on who you are" is of real use to clients.  There are IRSA examples where the UI colors specific rows in data product tables pink to indicate that identity-based authorizations apply to a dataset.   I'll try to research what attributes IRSA is using to drive this, but it's certainly a real use case.
* I agree with Markus that something in ObsCore that helps answer the question "OK, but what do I do next" would be a useful next step.

* For Rubin in particular, we would likely only ever use "secure" or "proprietary" on our planned ObsCore data products, with "secure" only appearing for data beyond the proprietary period.  I do not view it as urgent for Rubin to get this working soon, though, so I'm open to a serious reconsideration of what a future ObsCore should do about this.

Anastasia and Pat may want to comment on these:

* IRSA's _existing_ SIAv2 service does not return data_rights; it does return obs_release_date.  IRSA is in the process of revisiting its ObsCore modeling and how it is derived from CAOM2, and that was the proximate cause for my looking into the documentation for the data_rights attribute.

* It appears CADC's SIAv2 also only provides obs_release_date and not data_rights.

So, from what I am familiar with it's not clear that a lot of tears would be shed about a change in this area.

Gregory

________________________________________
From: dm <dm-bounces at ivoa.net> on behalf of Markus Demleitner <msdemlei at ari.uni-heidelberg.de>
Sent: Friday, October 6, 2023 12:03 AM
To: dm at ivoa.net
Subject: Re: ObsCore's data_rights and VODataService - broken reference

Dear DM,

On Fri, Oct 06, 2023 at 01:42:57AM +0000, Dubois-Felsmann, Gregory P. wrote:
> Apologies if this has been noted previously, but I just noticed
> that because ObsCore 1.1's definition of the "data_rights"
> attribute depends on VODataService, and because the relevant parts
> of VODataService were removed in the transition from 1.1 to 1.2,
> the definitions of "public", "secure", and "proprietary" have been
> effectively orphaned.

Oh bother... I had totally disregarded this incoming link into
VODataService.  Sorry about this.

> What's the right way to fix this in ObsCore?  Pull the definitions
> into the body of the document?  Can we do this in an erratum?

The short-term fix is, I think, to have a version-sharp reference
(which, incidentally, is also what ivoatex does).  So, I'd say we
ought to have an erratum that says:

  Replace the content of section B 4.4 with:

    This parameter allows mentioning the availability of a dataset.
    Possible values are: public, secure, or proprietary as stated in
    VODataService 1.1 (Plante et al. 2010), sect. 3.1.1.

  Replace the citation for Plante et al. 2010 with

    Plante, R., Stébé, A., Benson, K., Dowler, P., Graham, M.,
    Greene, G., Harrison, P., Lemson, G., Linde, T. and Rixon, G.
    (2010), ‘VODataService: a VOResource Schema Extension for
    Describing Collections, Services Version 1.1’, IVOA
    Recommendation 02 December 2010, arXiv:1110.0516.
    http://doi.org/10.5479/ADS/bib/2010ivoa.spec.1202P

Poke me and I'll write it.

On the longer run, however, I'd raise the question of whether
data_rights should stay the way it is in the first place.  In
Registry, we've found that the three values in VODataService 1.1
turned out to be woefully inadequate and hence unused, which is why
we changed it.

This *may* be different on the dataset level (i.e., obscore), but: Is
anyone aware of data_rights actually being used (as in: read and
evaluated, not just given a value in a table)?  If so, what for?

My suspicion is that it would be worth revisiting the use cases and
then figure out what we'd actually need in this department; this
could be

* nothing (people just try the access URL and we rely on the
  headers of a potential 401 response to tell them what they need to
  know; I think that's what our current work on auth converges upon),

* a machine-readable licence declaration (if we believe discovering
  data by the strings attached to it is an important use case),

* free text (if we consider obscore to be the right place for things
  like "if you use this data, please tell janet at doe.person and cite
  1955Sci...122..911B")

* use the link_auth/link_authorized combo from Datalink 1.1
  (https://ivoa.net/documents/DataLink/20230413/PR-DataLink-1.1-20230413.html#tth_sEc3.2.11)

* still something else.

       -- Markus