relatedResource/altIdentifer [was: VOResource PR #1]

[Markus Demleitner]

Hi Gilles,

On Fri, Dec 09, 2022 at 11:03:08AM +0100, gilles landais wrote:
> > So... what if we defined relatedResource/altIdentifier as an element
> > and said maxOccurs=1?  Do people already have use cases that would
> > blow that up?
> 
> I don't see any reason to add more than 1 identifier for a single remote
> resource.
> But multiple relations could be appropriate for other relationshipType like
> 'related-to' (ex: ivo://cds.vizier/J/AJ/161/36)

Sure -- that would not be affected by this change.  As long as you're
happy with that *each* of these related resources can only have zero
or one alternates, that'll work fine.

In case you didn't check -- reminder: you can prefix any IVOID with 
http://dc.g-vo.org/I/ to look at (an XSLT-processed version of) the
resource record, so a quick way to look at this would be to go to
<http://dc.g-vo.org/I/ivo://cds.vizier/J/AJ/161/36>: that
resource has a metric ton (eyeballing: 30) of other CDS records under
related-to.

Talking about which:
<http://www.ivoa.net/rdf/voresource/relationship_type> deprecates
related-to -- that's legacy VOResource 1.0, and I've always thought
related-to was a mistake to begin with because it doesn't convey any
new information (beyond what vr:Relationship already says).

So, can I perhaps nudge towards a less generic term (bonus: you can
immediately use it in your DataCite record).  What about
IsDerivedFrom?  Or perhaps Cites?

> > And Gilles, are you available as a guinea pig to write records having
> > such altIdentifiers?
> 
> I would like to add the original source as I did for the DOI of
> VizieR Gaia catalogues  - It needs an additional metadata in VizieR
> (not ready yet) for a value which could be a DOI or a URL.  In any
> cases, this curation would be limited  to large dataset coming from
> space agencies.

Sooo... should I read this as: Markus, go ahead, put this into
VOResource 1.2, and I'll do the reference implementation, and I'll
valiantly defend that feature in the (unlikely) case someone will
dispute it during RFC?

Thanks,

         Markus