[vo-dml] Clarification on composition rule..

[Gerard Lemson]

I think both these examples, polygon and polynomial generally deserve their own specific serialization.
I would not anticipate for example publishers mapping a polygon t some normalized representation, taking up multiple rows in multiple tables in a database.
And DB vendors generally support them using specialized types and serializations like geojson or WKT.

Is there no option doing something similar for these more complex mathematical expressions in the transformation model?
Could the parameter description language (http://ivoa.net/documents/PDL/20140523/REC-PDL-1.0-20140523.pdf) play a role there?
Or might something like the ANTLR calculator grammar (https://github.com/antlr/grammars-v4/blob/master/calculator/calculator.g4) be useful ?

Cheers
Gerard

From: Patrick Dowler <pdowler.cadc at gmail.com>
Sent: Monday, March 9, 2020 15:43
To: Gerard Lemson <glemson1 at jhu.edu>
Cc: CresitelloDittmar, Mark <mdittmar at cfa.harvard.edu>; Data Models mailing list <dm at ivoa.net>
Subject: Re: [vo-dml] Clarification on composition rule..

As you may know, I don't let the warning from vo-dml validation about open ended multiplicity bother me too much. Polynomial is another good example where it greatly limits/impacts how one might model something... I ran into it way back at point, circle, polygon (oops! non-fixed size). I don't expect this can be feasibly made illegal in future... I expect the warning/admoinishment to be softened, maybe with some good advice about when such cardinality is warranted and when another pattern may be a better choice.

my 2c,


--
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada


On Mon, 9 Mar 2020 at 06:05, Gerard Lemson <glemson1 at jhu.edu<mailto:glemson1 at jhu.edu>> wrote:
HI Mark
Just for now:
From the vo-dml spec:
“Modelers SHOULD NOT use open ended multiplicities, i.e. with maxOccurs=-1, but it is not illegal in the current version of this specification. "
indicates it is not illegal to use non-fixed size data type instances. (not that I like them as you know)

The fact that you think you need it here may be due to an incompleteness in the model as I described in my previous email.
It may well be that the structure of the mapping, including explicitly representation of what-is-mapped-to-what, could make the need for an explicit indication of forward vs inverse redundant.
So looking forward to seeing more details of the model (and I can comment on another thread).

Cheers
Gerard


There are flavors which have open ended list of content
   Lookup table has open ended list of Entries
   Polynomials have open ended list of Coefficients,  to avoid individually modeling the different order of polynomial functions.

DataTypes are supposed to have fixed size.

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20200309/3f1f6d8e/attachment-0001.html>