Obscore 1.1 Erratum 3

[Markus Demleitner]

Hi Jesus,

On Thu, Dec 08, 2022 at 11:22:09AM +0000, Salgado, Jesus wrote:
> I am not really against of the proposal as there could be cases
> where having a non-NULL obs_id is not really justified, but I have
> defined different DAL protocols and I have always defined the id
> field as non-NULL. The reason is to allow clients that are
> gathering responses from various services to have a consistent view
> of the results (e.g. if the view of the result is expressed like a
> tree in the client, the name of the branches is the id). Not having
> a defined non-NULL field implies to construct this branch
> identifier on the fly with other metadata or using a different
> field. Having a unique non-NULL field makes life easier for client
> developers, in my view.

Is anyone actually using obs_id like this?  If so, that would be a
valid argument.  But frankly, at least for all of my data, and I
think for the overwhelming majority of other data published through
obscore, too, that would look clumsy, because there would be a 1:1
relationship between parent and child throughout because obs_id is
just the suffix of obs_publisher_did.

Because it may sound different above let me mention in passing that
obs_id is *not* suitable to organise results *between* services
(Obscore 3.3.3: "The form of the obs_id string is up to the data
provider so long as it uniquely identifies, within the context of the
archive, all data products resulting from the observation.").  So,
Jesus' tree would have three levels, archive/obs_id/dataset.

> As said, I am not against of the proposal but just to provide a
> historical insight of why this could be originally defined as
> non-NULL.

Thanks for that.  If client developers indicate that they at least
consider presenting all-VO obscore results in this way and would be
impacted by having to handle NULLs in obs_id in a special way, I
would probably retract the Erratum.

Outside of the current context (because there's far too much
installed base out there that has obs_id ≈ obs_pub_did to help
current clients) and out of pure curiosity: I'd expect it would
actually be easier for clients to know when the intermediate level in
the tree is just clutter because each node would just have one child
if this fact were indicated by obs_id IS NULLs.  Am I missing
something?

        -- Markus