Three PRs for VOResource 1.3

[gilles landais]

Hello Markus and all.

About (2) and (3). I agree for the relation "IsContinuedBy" which exists 
also in DataCite.
But I don't see any equivalent of "DiscontinuedResource"  type in 
DublinCore or in DataCite (not surprising).
In a sens the status (OAI-compatible) described in (2) makes the job. So 
what's the benefit of duplicating methods?

I think too that removing capabilities is the basis for deletion. But it 
is enough considering EUDAT harvesting?
(eg: How the registry status is managed in EUDAT?)


About use case. We don't have today in CDS, but deletion and 
"IsContinuedBy" relation could be an option for instance with CDS HiPS 
resources (huge data).
Note that currently, we don't remove any HiPS resource and the plan 
consists to keep access for as long as possible.


For (unfortunate) deletion in Registry, I would be in favor to:

- removing capabilities.
... and update metadata as a tombstone page.  For instance, Data 
provider should update the description with deletion explanation.
Thus the explanation would be available in pyvo (registry module), and 
may be available in EUDAT(?)

- adding the status='deleted'

- adding the relationship=IsContinuedBy when possible

Gilles



Le 17/04/2025 à 16:27, Markus Demleitner via registry a écrit :
> Dear Registry folks,
>
> The Exec has recently approved VOResource 1.2 (main new feature:
> altIdentifiers on all vr:ResourceName-s) -- thanks to all who
> contributed in the various ways.  It ought to turn up on the doc repo
> soon.
>
> However, we collected a few open issues on VOResource during the review
> ofPR-1.2, and thus I have already started the cycle towards VOResource
> 1.3.  In consequence, there are now three PRs that I'd invite everyone
> here to review:
>
> (1) In mild confusion, we (well: I) added ivo-id attributes to Content
> and Creator in VOResource 1.1.  That was a bad idea even back then,
> because these interfere with the ivo-id attribute on Content/name and
> Creator/name (which have always been ResourceName-s).
> <https://github.com/ivoa-std/VOResource/pull/21> deprecates them (in
> words; I don't think we have a way to machine-readably deprecate things
> in our XSDs).   Thanks to Grégory for spotting this.  I don't think this
> is terribly contentious.
>
> (2) The explanations for the various values allowed for Resource/@status
> suggested that they were assigned by some sort of registry curator.
> That is now how these came out: In practice, it is the publishers
> assigning these values (and really, in general they shouldn't use them
> in the first place).  <https://github.com/ivoa-std/VOResource/pull/22>
> attempts to rectify this and to explain why under normal circumstances,
> you shouldn't use anything but active here.  If you ever found you
> wanted to set status to inactive of even deleted, please have a look at
> this and make up your mind on whether the new language covers what you
> need(ed).
>
> (3) While we don't really do any persistence in the Registry, there are
> situations in which we want to be able to say "this resource doesn't
> exist any more, but there's that other resource that you ought to use
> instead".  I'm proposing such a mechanism in
> <https://github.com/ivoa-std/VOResource/pull/23>: DiscontinuedResource.
>
> This PR is on top of #21 and #22, so if you review only this, only have
> a look at commit 554720c.  And for this, I am not at all positive that
> this is what we want to do.  Perhaps just saying "Use whatever record
> type you used before but dump all capabilities" would be about as good
> (although such a resource certainly shouldn't have any coverage, say).
> Anyway, please have a look and totally feel free to blast it if you feel
> that's not a good idea.  Perhaps read
> <https://github.com/ivoa-std/VOResource/issues/12> before reviewing to
> have the context.
>
> As I said: please review when you get a chance, and on (3) think about
> whether you have use cases when this would be useful for your resources
> (I think I have a few cases, by the way).
>
> Thanks,
>
>           Markus
>
> PS: Btw, if you want to build the document itself, you'll need ivoatex
> from its <https://github.com/ivoa-std/ivoatex/pull/157>.  If you find it
> in yourself to approve that, I'd also be grateful.
>