<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Markus<br><div>
</div>
<div><br><blockquote type="cite"><div>On 6 Nov 2024, at 15:00, Markus Demleitner via semantics <semantics@ivoa.net> wrote:</div><br class="Apple-interchange-newline"><div><div>Dear Laurent,<br><br>On Wed, Nov 06, 2024 at 01:57:44PM +0100, Laurent Michel via semantics wrote:<br><blockquote type="cite">I wrote a few comments below, but to be short I propose<br>to take the following actions:<br><br>- create a vocabulary named "property_qualifier"<br></blockquote><br>Uh... Let me be very frank and say that I don't like that name much<br>exactly because it is so generic; the name would probably fit for<br>every vocabulary we already have. I think we can do a lot better if<br>we spell out:<br><br>(a) properties of what?<br>(b) how, i.e., in which way, are these properties qualified?<br><br>I'm pretty sure we will find a much more descriptive and much less<br>generic name if you sketch the concepts you'd like to include. Or<br>for that matter, name*s*, if that's what it takes.<br></div></div></blockquote><div><br></div>OK let’s get ride of “property_qualifier".<blockquote type="cite"><div><div><br><blockquote type="cite">- serialize it as "property_qualifier.desise"<br> - is desise a suitable format?<br></blockquote><br>No, don't bother with anything so formal. The actual input will be a<br>simple CSV anyway, see<br>https://github.com/ivoa-std/Vocabularies/blob/master/examples/terms.csv<br>for an, pun intended, example. But really, just the identifiers,<br>descriptions and possibly the hierarchy of the concepts will be<br>enough, and I'll be happy to cover the technical side.<br></div></div></blockquote><div><br></div>ok</div><div><br><blockquote type="cite"><div><div><br><blockquote type="cite">- put this file in a 'vocabulary' folder into the MANGO projects<br> to make it part of the RFC<br></blockquote><br>I'd actually much prefer if we work in<br>https://github.com/ivoa-std/Vocabularies immediately. That way, the<br>vocabulary's history will be where it belongs, and PRs within that<br>repo will later let people figure out what happened to it when they<br>want to understand why something is the way it is.</div></div></blockquote><div><br></div>OK, no vocabulary in the MANGO repository but links to https://github.com/ivoa-std/Vocabularies</div><div><br><blockquote type="cite"><div><div><blockquote type="cite">- change the model accordingly<br>- open a PR with that stuff<br></blockquote><br>There ought to be a PR against Mango describing the use of the<br>vocabulary and stating its URI, but that's about it.<br></div></div></blockquote><div><br></div>of course</div><div><br><blockquote type="cite"><div><div><br>I'm sure you are aware that VO-DML actually has a hook for this kind<br>of thing? See sect. 4.15, where we probably want to steer clear of<br>SKOS these days unless we actually need to looser properties<br>(explanation for that preference on request). Perhaps we can even<br>prototype more formal rules for bridging VO-DML and VocInVO2? Just<br>to explain the lack of existing rules: VO-DML predates or current,<br>more formal, vocabularies.<br></div></div></blockquote><br><div><div>I'm aware of this. </div><div>VODML supports the use of semantic references in attribute definitions.</div><div>As far as I know, there is no tool or model that uses this feature.</div><div>Once we have adopted the vocabularies, I'll see if there is a convenient way to include them in the MANGO VODML.</div><div>In any case, the control of the attribute values by a vocabulary can be specified in the standard document.</div><div><br></div></div></div><div><blockquote type="cite"><div><div><br><blockquote type="cite">OK, let's start we something simple.<br>e.g.<br> |- raw-data<br>calibration-level -|- ...<br> |- calibrated-data<br></blockquote><br>That would be a vocabulary of its own, right? In this particular<br>case, it would be great if the descriptions (or something else)<br>discussed your concepts' relationships to what EPN-TAP has in its<br>description of the processing_level column (EPN-TAP2, CODMAC, PSA,<br>PDS3, PDF4, and Obscore levels).<br></div></div></blockquote><div><br></div>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.<br>For know, we can start with simple words derived from obscore concepts.<br><blockquote type="cite"><div><div><br><blockquote type="cite">Looking at https://www.ivoa.net/rdf/, I see no obvious place for<br>the terms I'm proposing. The MANGO scope is to enhance the<br>desciption of complex quantities exploded in table columns. AFAIK,<br>there is no vocabulary covering this field yet.<br></blockquote><br>Ummm: Did you mean to write "exploded" here? If so, what does that<br>mean here?<br></div></div></blockquote><div><br></div>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. </div><div>In other words, MANGO is not a model specific for a particular domain or describing some product category.</div><div>Therefore, either we build a vocabulary specific for MANGO, my first (bad) idea, or domain specific vocabularies, one per MANGO class which requires it.<br><blockquote type="cite"><div><div><br>If this is what I think it is, I strongly suspect you want multiple<br>vocabularies; for instance calibration-level, photometry-type, etc.<br>Quite possibly, you then want to forsee full concept URIs<br>("http://www.ivoa.net/rdf/calibration-level#raw" rather than just<br>"raw" or "#raw") whereever you keep the concept identifiers.<br></div></div></blockquote><div><br></div><div>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.</div><div>Doing so you require that the attribute value must be set to a narrower term than the one pointed to by the URI. </div><div>Checking this supposes that the model validator is able to explore the vocabulary in depth. </div><div><br></div><div>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. </div><div>This is quite more simple.</div><div>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</div><div><br></div></div><div><br><blockquote type="cite"><div><div>Having several distinct vocabularies that MANGO will use is no reason<br>for alarm. Many small, focused vocabularies are generally preferable<br>to some behemoth that makes you forget what exactly it's for.<br></div></div></blockquote><div><br></div>OK,</div><div><br></div><div>Let’s start with the three vocabularies I need for MANGO:</div><div>- calibration levels</div><div>- photometry measurements </div><div>- sky region</div><div><br></div><div><br></div><div>Laurent</div><div><br><blockquote type="cite"><div><div><br>Thanks,<br><br> Markus<br><br></div></div></blockquote></div><br></body></html>