Proposal for Processing-level

[elsadvd]

Hi,
Here is a modelisation proposal for Processing-level vocabularies #27 :

Modelling Processing-level in SKOS allows you to have a vocabulary where each level is a concept that can have several labels (altLabel).

• The first option would be to have, for example:

processing-level:raw a skos:Concept;
skos:prefLabel "Raw instrumental data"@en;
skos:altLabel "obscore: 0";
skos:altLabel "CODMAC:1";
skos:altLabel "CODMAC:raw";
skos:altLabel "PSA:0";
skos:altLabel "PDS3:UDR";
skos:altLabel "PDS4:Telemetry";
skos:altLabel "EPNTAP: 1";

Tools using this vocabulary for their data table can retrieve information about them by retrieving the altLabel containing the service referred to in each concept.

• The second option would be to create new Ivoasem properties for obscore ans epncore labels and create properties inside Processing-level for other labels, for example :

ivoasem:obscore_label a rdf:Property ;
rdfs:label "Label in ObsCore model"

ivosem:epncore_label a rdf:Property ;
rdfs:label "Label in EpnCore model"

processing-level:codmac_label a rdf:Property ;
rdfs:label "Label in CODMAC model"

Then for each concept we use those properties:

:raw a skos:Concept ;
skos:prefLabel "Raw instrumental data"@en ;
ivoasem:obscore_label: "0" ;
ivoasem:epncore_label: "1" ;
:codmac_label:"1"

Those options avoid multiplying the vocabularies even though the concepts are the same.

[BaptisteCecconi]

I wait for @msdemlei comment, but I like the second option very much.

For instance, we could reuse the ivosem:epncore_label in product-type to advertise the EPNcore labels for this vocabulary:

<#dynamic-spectrum> a skos:Concept;
  skos:prefLabel "Dynamic Spectrum";
  ivosem:epncore_label "ds" ;

[msdemlei]

On Tue, Jul 22, 2025 at 12:46:10AM -0700, elsadvd wrote: elsadvd created an issue (ivoa-std/Vocabularies#42) Modelling **Processing-level** in SKOS allows you to have a vocabulary where each level is a concept that can have several labels (altLabel). - The first option would be to have, for example: > processing-level:raw a skos:Concept; > skos:prefLabel "Raw instrumental ***@***.***; > skos:altLabel "obscore: 0"; > skos:altLabel "CODMAC:1";

I think that's an abuse of altLabel (if only because these are supposed to be human-readable, and asking machines to look at them is asking for trouble later). Let's not go this way.

> :raw a skos:Concept ; > skos:prefLabel "Raw instrumental ***@***.*** ; > ivoasem:obscore_label: "0" ; > ivoasem:epncore_label: "1" ; > :codmac_label:"1" Those options avoid multiplying the vocabularies even though the concepts are the same.

This is less ugly, but very frankly I'd be a lot more relaxed about having many concepts within a vocabulary, living in a nice hierarchy, than to have custom properties that interested clients would have to learn. But if we go that way, I think we should define the objects of the x_label properties as integers. That possibility actually is what I like most about that scheme. Also, if you look at EPN-TAP's infamous calibration level table (p. 13), you see that the concepts don't even map cleanly to each other (see "2 or 3" or "2-5"). So, if we can't live without hacks anyway, I'd much rather hack the identifiers, because for all I can see they're the problem: if we use up 1 of Obscore, we can't have an identifier of 1 for EPN-TAP. For clarity, where's what I'd like to have (but can't): epntap-level 1 (same-as obscore/0, same-as pds/telemetry, ...) 2 (same-as obscore/1, same-as pds/raw, ...) ... obscore-level 0 (same-as pds3/udr, same-as ...) ... codmac-level 1 (same-as epn/1, same-as obscore/0, ...) ... Neglecting for now that we'd have to choose a suitable same-as property (I don't think we want skos:exactMatch, but that's the only one that VocInVO2 sanctifies so far), the problem is that we need to get to unique identifiers. VocInVO2 says: In IVOA vocabularies, this fragment identifier MUST consist of ASCII letters, numbers, underscores and dashes exclusively. So, perhaps we should reserve the dash for our identifiers and have special rules *for the adopting standards*. You need to type-convert anyway in obscore, and then we can say "use what's behind the dash in terms below obscore-level in http://www.ivoa.net/rdf/processing-level, convert it to an integer and use that in our column"; and the same for epntap. Then, our vocabulary could be epntap-level epntap-1 (same-as obscore-0, same-as pds-telemetry..., label "EPNTAP PL 1") epntap-2 (same-as obscore-1, same-as pds-raw...) ... obscore-level obscore-0 (..., Label "Obscore PL 0") obscore-1 (...) ... pds3-level pds3-udr (same-as yadda) pds3-edr (ad nauseam; probably symmetrised by script) ... nasa-level nasa-0 nasa-1a nasa-1b ... I might be enticed to think a bit more about the same-as issue. But if we can live with this the slightly ugly rules about having to transform the labels, I think this plan ought to work.

[BaptisteCecconi]

Hi, since we could reuse the ivoasem:epncore_label in Product-type, I think it is worth give it a try. I talked with @elsadvd yesterday, and she will propose a full vocabulary using those properties, and we will prepare a small python script to explain how to use it.

[msdemlei]

On Thu, Jul 24, 2025 at 02:48:52AM -0700, Baptiste Cecconi wrote: Hi, since we could reuse the `ivoasem:epncore_label` in *Product-type*, I think it is worth give it a try. I talked with @elsadvd yesterday, and she will propose a full vocabulary using those properties, and we will prepare a small python script to explain how to use it.

Is this a "rather not" on the idea of making the EPN-TAP table machine-readable in the fashion proposed above? If so, my suggestion would be to reserve the single-digit labels for obscore and think about the other systems later.