UCDs and RDF [was: Versioned standardIDs for standard vocabularies?]

[Markus Demleitner]

Hi Rick,

On Thu, Mar 19, 2026 at 08:43:33AM +0000, Hessman, Frederic wrote:
> On 19 Mar 2026, at 09:04, Markus Demleitner via semantics <semantics at ivoa.net> wrote:
> Of course vocabularies shouldn't have grammars, but there's no
> reason something grammared couldn't be represented by a vocabulary
> as long as vocabularies are simply collections of tokens used in
> some context to represent something useful, as UCD's obviously are.
>
> Here's an example (yes, really ancient) :
>
> https://www.astro.physik.uni-goettingen.de/~hessman/rdf/UCD1/index.html

Oh, nice; I hadn't noticed this (or forgot about it).  This reminder
is timely in that there is a rull request taking up exactly this idea
since late 2024:  <https://github.com/ivoa-std/Vocabularies/pull/31>.
So far, this is supposed to be a seed of discussions.

Up front: "here is a UCD" should still not reference this.  It only
contains UCD *words* ("phot.mag"), not full UCDs
("phot.mag;em.opt.B").  My gut feeling is that these two things
should be kept separate for both humans and machines.

Then: One relevant question in the PR is the IVOA "flavour" (SKOS,
RDF class, RDF property) of this vocabulary.  I think it's pretty
clear that UCDs are not property-like.  You see, when you annotate a
column, you would not say

  (<this column> phot.mag <erm, no idea>)

but rather

  (<this column> *contains-physics phot.mag;em.opt.B)

The choice between SKOS and RDF class is harder to make.  This mainly
depends on what relationships we expect to have between the
individual concepts.  PR #31 does not define any relationships at
all, and I now think that's right.

This is because I don't think there is an advantage for a machine to
infer that some relationship between phys and phys.size exists (I
don't think I could explain what it is, frankly).  This is probably
different for phys.size vs. phys.size.diameter, but as Baptiste
points out in the PR comments, this kind of thing is at least not
generalisible (Baptiste's counter-example: stat.Fourier.amplitude and
stat.Fourier).

*If* we think the (rather rare) relationships of the phys.size -
phys.size.diameter type are useful enough to bother, we could
manually mark them up and use RDF class with real, hard,
inference-stable is-a relationships.  Implementing something like
"give me all kinds of sizes" at least sounds as if it might be a good
idea.  My suspicion, though, is that this is not *much* more useful
that the plain ``ucd LIKE 'phys.size%'``.

You, Rick, back in 2007 used the much softer SKOS relationships;
skos:narrower can mean many things, in particular is-a and
is-part-of, and it's probably pretty close to the way UCD atoms are
combined to form words.  The only question is: what would a client do
with this sort of information?

But mainly: Any feedback to Vocabularies PR #31 is most welcome.

Thanks,

          Markus