Machine-readable "uses tool X"

[msdemlei]

On https://wiki.ivoa.net/twiki/bin/view/IVOA/DocRegExt10RFC, Gilles has made this point:

listing tools is cool, but as free text, they sound as keywords :( This distorts the meaning of linked data in terms of "relationships".

Suggest: (I like the idea to attach tools) it would need an additional step consisting to register tools in registry. A tool-resource with URLs to dowload softwares, documentation(s), examples... it would be nice ?

I'd tend to agree, but as I say loc cit:

I've been advocating this sort of thing for a long time, but considerations of registering software have always led to unproductive discussions.

However, there already is a list of astronomical software that could count as good enough to provide unique identifiers for VO tools: http://www.ascl.net/.

So, what if we recommended using Cites relationships with a human-readable tool name as the resource name, no ivo-id and an ASCL identifier in altIdentifier? ASCL's own ids would do it already (where we should probably mention the schema in VOResource's next release). In that way, saying "I'm using TOPCAT" would look like this:

<relationship>
  <relationshipType>Cites</relationshipType>
  <relatedResource altIdentifier="ascl:1101.010">TOPCAT</relatedResource>
</relationship>

A more implicit (and therefore to me less desirable) but perhaps more accessible variant would be to replace the URI prefix with the baked-in resolver and write https://ascl.net/1101.010.

[mbtaylor]

Sounds like sense to me.

[pahjbo]

I like the URI approach - i.e no direct resolver

[gilleslandais]

Sounds good for ascl !

I'm not sure if I'm wrong, but does the "altIdentifier" attribute requires a xsi:URI with "https?" today?
I'm not against using ID instead of URL — we could use them for DOI for other purposes.

[msdemlei]

On Fri, Jan 30, 2026 at 10:06:08AM -0800, gilleslandais wrote: gilleslandais left a comment (ivoa-std/DocRegExt#4) Sounds good for ascl ! I'm not sure if I'm wrong, but does the "altIdentifier" attribute requires a xsi:URI with "https?" today? I'm not against using ID instead of URL — we could use them for DOI for other purposes.

The normative language on alternate identifier schemes is here: https://ivoa.net/documents/VOResource/20250416/REC-VOResource-1.2.html#tth_sEc2.2.5 I have a personal preference for using per-scheme URI schemes ("doi:10.5072/7273288") rather than baked-in resolvers (https://orcid.org/0000-0001-2345-6789) on grounds that I generally am skeptical of building in central services into things that are intended to last for decades (what if in 10 years we'd like to resolve using a protocol other than https? It's happened before going from http to https...) and it's noticeably prettier to say altIdentifier like 'doi:%') than altIdentifier like 'https://orcid.org/%'. So, unless someone comes out strongly on the side of baking in the ascl HTTP service, I'd go for the (pseudo-) URI form ascl:nnnn-mmmm.

[gilleslandais]

oh yes -
It was my own mistake in reading the VO-Resource XSD . I ignored also that it was possible to an attribute "altIdentifier" in "relatedResource".
So it is ok -

[ehenneken]

Do you anticipate a need to be able to reference a specific release of a tool? If that's the case, ASCL does not provide the required granularity. If there happens to be a Zenodo record for this release, I guess the Zenodo DOI for this release could be used in the relatedResource entry?

[msdemlei]

On Mon, Feb 02, 2026 at 07:16:32AM -0800, Edwin Henneken wrote: ehenneken left a comment (ivoa-std/DocRegExt#4) Do you anticipate a need to be able to reference a specific release of a tool? If that's the case, ASCL does not provide the required

No, that would rather certainly defeat the purpose of the whole thing. The use case is: "Hey, I want to show off aladin on something extragalactic." Requiring people to say "show me tutorials using aladin-version-10 or aladin-version-11 or aladin-version-12" makes this totally non-fun and unobvious. So, we really need what ascl does: one tool, one unique identifier. Sure, the discovery query can't filter out tutorials using (perhaps useless) ancient versions of some tool. But for bitrot we have ***@***.***=inspected.

[gilleslandais]

I'm not very aware with software identifiers. But I heard also about SWHID (https://www.swhid.org/).
I think it is used by SoftwareHeritage.

[msdemlei]

On Mon, Feb 02, 2026 at 10:00:37AM -0800, gilleslandais wrote: gilleslandais left a comment (ivoa-std/DocRegExt#4) I'm not very aware with software identifiers. But I heard also about SWHID (https://www.swhid.org/). I think it is used by SoftwareHeritage.

On the plus side, this is a discipline-spanning standard. On the minus side, it's ISO with all the implications that may at some point have on the accessibility of the standard text, although right now it's still apparently open (although the download page is broken for my normal browser and I'm too grumpy because of that to try and figure it out). On the plus side, the "onboarding" <cough> slides are in LaTeX beamer. Also on the plus side, Stefano Zacchiroli is on board, who I think once was Debian Project Leader. But on the minus side, I think this solves a largely unrelated purpose (identifiers down to a particular edit state of individual files), and shoehorning it into what we need seems extremely involved. After paging through the slide set, I still have no idea where to even start when I'd like to get "an" SWHID "for TOPCAT" (I don't think that's even a well-defined question with SWHID). For ASCL, that explanation is a single sentence. And they've been around for 10+ years. So, even if ASCL ids limit us to references to astro software, it seems to me ASCL is going to be hard to beat for the foreseeable future for having easy-to-find unique ids for the software we're interested in.