MCT - model document delivery.
Laurent Michel
laurent.michel at astro.unistra.fr
Mon Sep 21 16:05:36 CEST 2020
Hi Gerard,
Let me clarify what we are talking about.
The mapping snippets in the current thread refer (in free-style mode) to the proposal I'm working on after many discussions we
had 2 years ago.
The baselines of this proposal - based on yours - are 2 folds:
- Getting a better human readability.
- Trying to facilitate the annotation process for archival data centers.
This project (rationale + syntax proposal + demo) has been exposed several time in Interops (Shangai, Victoria, College Park +
VirtualMay).
I've been exercing it first as a workbench for Time Domain data and then I decided last spring to promote it in parallel with
MANGO, the model for source data.
The goal of MANGO is to provide an answer to the question that Tom asked in the name of client developpers:
"Where is my Proper Motion?".
In other words, providing a conveniant way to discover source parameters rather than to get standard source instances.
In this context we need an appropriate mapping to test the whole annotation life-cycle:
- Model VODMLization
- Building of annotation components
- Merging annotation components for particular datasets
- Consuming annotated data-sets
Mango and the mapping are totally separated but the development of one requiers to other to work and vice-versa.
The proposed mapping is absolutely not ad-hoc.
Cheers
LM
Le 18/09/2020 à 20:02, Gerard Lemson a écrit :
> HI
> Sorry to jump in, I will try to find time to follow this thread.
>
>> You seem not be aware about the documentation role of the models I
>> mentioned in my former message.
>> If you consider that an error is just a value, you do not need any model at all,
>> just a UCD.
>> If you want to go deeper in the modeling, you have to build a class hierarchy
>> and the annotation must able to restitute that hierarchy.
>>
>> My approach for the annotation is to build a tree of XML elements that
>> denotes the model structure (or a subpart of) and to tune the element
>> attributes to connect the actual data.
>> So that I'm sure we can write generic code enable to reconstruct instances of
>> any model and I'm confident we can facilitate the mapping process even for
>> complex things.
>> I'm affraid that any other approach will lead to had-hoc annotations.
>>
> I don't know what mapping approaches you are referring to, but I do want to remind people that there has been a proposal for mapping out for some 7 years now.
> In a number of incarnations that tried to accommodate feedback from the community, it provides a rigorous approach how to identify model instances in votables or tap schems.
> And it is most definitely NOT ad hoc and I'd be keen to participate in any calls on mapping in general and maybe reviving this effort.
> Hopefully Markus' comments might lead to developing some of the concrete use cases we have been dearly missing.
>
> Cheers
> Gerard
>
>>
>> Laurent
>>
>> Le 17/09/2020 à 16:26, Markus Demleitner a écrit :
>>> Dear Laurent,
>>>
>>> On Thu, Sep 17, 2020 at 03:02:22PM +0200, Laurent MICHEL wrote:
>>>> Le 17/09/2020 à 12:13, Markus Demleitner a écrit :
>>>>> And if I understand you right: How will you specify the annotation?
>>>>> Do you forsee additional, per-DM specifications that will tell
>>>>> implementors how to serialise instances?
>>>>
>>>> No, I don't. The annotation must be model independent an it must keep
>>>> consistent even when a part of the model only is mapped and clients
>>>> must be clever enough to work with model subsets.
>>>
>>> But then the VO-DML and the model *does* matter for how clients will
>>> deal with the annotations, which is why I'm whining about nested,
>>> entangled DMs and pleading for relatively flat, independent ones.
>>> Let me give you an example in roughly the syntax of
>>> ModelInstanceInVOT, where you have a catalogue with a position and
>>> photometry:
>>>
>>> <FIELD name="ra"/>
>>> <FIELD name="ra_err"/>
>>> <FIELD name="dec"/>
>>> <FIELD name="dec_err"/>
>>> <FIELD name="mag"/>
>>> <FIELD name="mag_err"/>
>>>
>>> What I would like to see in the end is something like:
>>>
>>> <INSTANCE type="meas:NaiveMeasure">
>>> <ATTRIBUTE role="expectation" ref="ra"/>
>>> <ATTRIBUTE role="error" ref="ra_error"/>
>>> </INSTANCE>
>>>
>>> <INSTANCE type="meas:NaiveMeasure">
>>> <ATTRIBUTE role="expectation" ref="mag"/>
>>> <ATTRIBUTE role="error" ref="mag_error"/>
>>> </INSTANCE>
>>>
>>> <INSTANCE type="coords:Position">
>>> <ATTRIBUTE role="ref_frame" value="ICRS"/>
>>> <ATTRIBUTE role="latitude" ref="dec"/>
>>> <ATTRIBUTE role="longitude" ref="ra"/>
>>> </INSTANCE>
>>>
>>> <INSTANCE type="phot:PhotPoint">
>>> <ATTRIBUTE role="band_name" value="G"/>
>>> <ATTRIBUTE role="value" ref="mag"/>
>>> </INSTANCE>
>>>
>>> -- notice how all of position, photometry, and errors are annotated
>>> without one annotation (or model) having to know anything about the
>>> other. A client interested in positions will easily find all
>>> positions, a client interested in errors will easily find value/error
>>> pairs (or later the distributions), and clients needing both still
>>> have a rather easy time.
>>>
>>> Which becomes really crucial when we will get a meas2 DM, in which
>>> case you simply simply *add*:
>>>
>>> <INSTANCE type="meas2:NewNaiveMeasure">
>>> <ATTRIBUTE role="mean" ref="ra"/>
>>> <ATTRIBUTE role="uncertainty" ref="ra_err"/>
>>> </INSTANCE>
>>>
>>> If you can pull off this latter trick with entangled DMs, I'll shut up
>>> about Meas including Coords. The central point being: We can't have
>>> flag days in the VO, where everyone moves from one model version to
>>> the next. We will have to plan for something like a decade in which
>>> an old and a new major version will be sitting next to each other. I
>>> don't like that myself, but if we can learn anything from the last
>>> decade of the VO (where I've just succeeded this year in purging the
>>> last ProtoSpectralAccess services), and of 40 years of FITS evolution,
>>> it's that we ignore that requirement at our peril.
>>>
>>>> -- still not WDs yet --
>>>>
>> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
>>>> hub.com%2Fivoa-
>> std%2FMANGO&data=02%7C01%7Cglemson1%40jhu.edu%7Cc6
>>>>
>> 8e5244507c4b156bd008d85be6cd31%7C9fa4f438b1e6473b803f86f8aedf0dec
>> %7C0
>>>>
>> %7C0%7C637360394139457144&sdata=gD8ehB0pDwkvjD5TPhRVWIgh8i
>> mN1LHdN
>>>> kYBo1GBE9I%3D&reserved=0
>>>>
>> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
>>>> hub.com%2Fivoa-
>> std%2FModelInstanceInVot&data=02%7C01%7Cglemson1%4
>>>>
>> 0jhu.edu%7Cc68e5244507c4b156bd008d85be6cd31%7C9fa4f438b1e6473b803
>> f86f
>>>>
>> 8aedf0dec%7C0%7C0%7C637360394139457144&sdata=L5FALHl30axBE%
>> 2B4KpO
>>>> u%2BoGnA6tg4jaNitm3BXZr3FKk%3D&reserved=0
>>>
>>> I'd be happy to help out on ModelInstanceInVot (full disclosure:
>>> at this point I'd like to do away with TABLE_ROW_TEMPLATE, FILTER,
>>> JOIN, GROUPBY, and the shortcuts, and I'd like to restrict inline
>>> literals to strings and use PARAMs otherwise, but in all these points
>>> I might be swayed).
>>>
>>> What if we had a Mapping telecon with the express goal of getting
>>> implementors on board and seeing what we can still chip away?
>>>
>>> -- Markus
>>>
>>
>> --
>> English version:
>> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
>> w.deepl.com%2Ftranslator&data=02%7C01%7Cglemson1%40jhu.edu%7
>> Cc68e5244507c4b156bd008d85be6cd31%7C9fa4f438b1e6473b803f86f8aedf0d
>> ec%7C0%7C0%7C637360394139457144&sdata=qX5E8kxO6Bm5bqKmxw
>> PqXvrPyWiNp%2FfyipjH3YjWeJg%3D&reserved=0
>> --
>> jesuischarlie/Tunis/Paris/Bruxelles/Berlin
>>
>> Laurent Michel
>> SSC XMM-Newton
>> Tél : +33 (0)3 68 85 24 37
>> Fax : +33 (0)3 )3 68 85 24 32
>> Université de Strasbourg
>> <https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fww
>> w.unistra.fr%2F&data=02%7C01%7Cglemson1%40jhu.edu%7Cc68e5244
>> 507c4b156bd008d85be6cd31%7C9fa4f438b1e6473b803f86f8aedf0dec%7C0%7
>> C0%7C637360394139457144&sdata=KzmYiivgBqS7vlC%2F4jrhzio4n1LzgQ
>> kXfUnzKZxoT3w%3D&reserved=0>
>> Observatoire Astronomique
>> 11 Rue de l'Université
>> F - 67200 Strasbourg
--
English version: https://www.deepl.com/translator
--
jesuischarlie/Tunis/Paris/Bruxelles/Berlin
Laurent Michel
SSC XMM-Newton
Tél : +33 (0)3 68 85 24 37
Fax : +33 (0)3 )3 68 85 24 32
Université de Strasbourg <http://www.unistra.fr>
Observatoire Astronomique
11 Rue de l'Université
F - 67200 Strasbourg
More information about the dm
mailing list