Vocabulary terms in MANGO

[Laurent Michel]

Markus

> On 6 Nov 2024, at 15:00, Markus Demleitner via semantics <semantics at ivoa.net> wrote:
> 
> Dear Laurent,
> 
> On Wed, Nov 06, 2024 at 01:57:44PM +0100, Laurent Michel via semantics wrote:
>> I wrote a few comments below, but to be short I propose
>> to take the following actions:
>> 
>> - create a vocabulary named "property_qualifier"
> 
> Uh... Let me be very frank and say that I don't like that name much
> exactly because it is so generic; the name would probably fit for
> every vocabulary we already have.  I think we can do a lot better if
> we spell out:
> 
> (a) properties of what?
> (b) how, i.e., in which way, are these properties qualified?
> 
> I'm pretty sure we will find a much more descriptive and much less
> generic name if you sketch the concepts you'd like to include.  Or
> for that matter, name*s*, if that's what it takes.

OK let’s get ride of  “property_qualifier".
> 
> 
>> - serialize it as "property_qualifier.desise"
>>    - is desise a suitable format?
> 
> No, don't bother with anything so formal.  The actual input will be a
> simple CSV anyway, see
> https://github.com/ivoa-std/Vocabularies/blob/master/examples/terms.csv
> for an, pun intended, example.  But really, just the identifiers,
> descriptions and possibly the hierarchy of the concepts will be
> enough, and I'll be happy to cover the technical side.

ok

> 
>> - put this file in a 'vocabulary' folder into the MANGO projects
>>  to make it part of the RFC
> 
> I'd actually much prefer if we work in
> https://github.com/ivoa-std/Vocabularies immediately.  That way, the
> vocabulary's history will be where it belongs, and PRs within that
> repo will later let people figure out what happened to it when they
> want to understand why something is the way it is.

OK, no vocabulary in the MANGO repository but links to https://github.com/ivoa-std/Vocabularies

>> - change the model accordingly
>> - open a PR with that stuff
> 
> There ought to be a PR against Mango describing the use of the
> vocabulary and stating its URI, but that's about it.

of course

> 
> I'm sure you are aware that VO-DML actually has a hook for this kind
> of thing?  See sect. 4.15, where we probably want to steer clear of
> SKOS these days unless we actually need to looser properties
> (explanation for that preference on request).  Perhaps we can even
> prototype more formal rules for bridging VO-DML and VocInVO2?  Just
> to explain the lack of existing rules: VO-DML predates or current,
> more formal, vocabularies.

I'm aware of this. 
VODML supports the use of semantic references in attribute definitions.
As far as I know, there is no tool or model that uses this feature.
Once we have adopted the vocabularies, I'll see if there is a convenient way to include them in the MANGO VODML.
In any case, the control of the attribute values by a vocabulary can be specified in the standard document.

> 
>> OK, let's start we something simple.
>> e.g.
>>                   |- raw-data
>> calibration-level -|- ...
>>                   |- calibrated-data
> 
> That would be a vocabulary of its own, right?  In this particular
> case, it would be great if the descriptions (or something else)
> discussed your concepts' relationships to what EPN-TAP has in its
> description of the processing_level column (EPN-TAP2, CODMAC, PSA,
> PDS3, PDF4, and Obscore levels).

I’m not expert in vocabularies, but I guess that such a calibration vocabulary could include specific branches per domain (ObsCore, EPN-TAP…) and setup cross links between them.
For know, we can start with simple words derived from obscore concepts.
> 
>> Looking at https://www.ivoa.net/rdf/, I see no obvious place for
>> the terms I'm proposing.  The MANGO scope is to enhance the
>> desciption of complex quantities exploded in table columns.  AFAIK,
>> there is no vocabulary covering this field yet.
> 
> Ummm: Did you mean to write "exploded" here?  If so, what does that
> mean here?

I mean that the MANGO properties describe complex quantities that are built from multiple column values and from various meta-data. This pattern can apply to any (or so) measurement axis or computed properties. 
In other words, MANGO is not a model specific for a particular domain or describing some product category.
Therefore, either we build a vocabulary specific for MANGO, my first (bad) idea, or domain specific vocabularies, one per MANGO class which requires it.
> 
> If this is what I think it is, I strongly suspect you want multiple
> vocabularies; for instance calibration-level, photometry-type, etc.
> Quite possibly, you then want to forsee full concept URIs
> ("http://www.ivoa.net/rdf/calibration-level#raw" rather than just
> "raw" or "#raw") whereever you keep the concept identifiers.

From a VODML point view, if you want to use a vocab, you have to  type the attribute as a string and specify which vocabulary this string must be part of.
Doing so you require that the attribute value must be set to a narrower term than the one pointed to by the URI. 
Checking this supposes that the model validator is able to explore the vocabulary in depth. 

The other way to proceed is to set the attribute value with the vocabulary URI itself, so that the validator has just to check that the URI does exist. 
This is quite more simple.
In the MANGO context, we do not need to deal with narrower or wider concepts . A region is serialized as a MOC or a STMOC. No need to  know which one is the  narrower or the  wider


> Having several distinct vocabularies that MANGO will use is no reason
> for alarm.  Many small, focused vocabularies are generally preferable
> to some behemoth that makes you forget what exactly it's for.

OK,

Let’s start with the three vocabularies I need for MANGO:
- calibration levels
- photometry measurements 
- sky region


Laurent

> 
> Thanks,
> 
>              Markus
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/semantics/attachments/20241107/257f53a9/attachment.htm>