[vo-dml] Clarification on composition rule..

[Gerard Lemson]

Hi
For a philosophical point in support of Pat’s view:
IF a TOperation is supposed to be a function in the math sense, then a DataType (or ValueType) can well be a/the correct representation.
For example if we consider functions as points in a “function space” (https://en.wikipedia.org/wiki/Function_space), they may be treated similarly to integers, or reals, or points in a more standard multidimensional space.
Importantly, In general the existence of a particular function is self-evident based on the definition of the class of functions it is supposedly a member of.
For example the definition of “polynomial function” implicitly defines all of its instances and we do not have to explicitly state that “2*x^3+4” exists, it is implied by the definition.
As written on page 31 of the vo-dml spec,this is a defining characteristic of a ValueType as opposed to an ObjectType.

If instead a TOperation instead is supposed to represent “the application of a function in a particular context”, that may well deserves to be an ObjectType.
But it seems to me that in the transformation model that role is played by the TMapping? And I think it is good indeed to separate these two concepts.

It may seem that a TOperation should be an ObjectType because it may have a complex structure. As Pat argues that is no reason not to use a DataType.
It may be due to the particular representation chosen in the model. I guess it would be possible to model the operation be a string representing a mathematical equation, with some prescription how axes or so are represented as variables. Interpreters need to be able to parse the expression, but again “valid mathematical function definition” would, with some details added, be sufficient to see if a certain string qualifies as a valid value of the type. Hence be a ValueType.
Actually, it seems to me from https://volute.g-vo.org/svn/trunk/projects/dm/STC/Trans/doc/WD-Trans-1.0.pdf that the model still misses a “prescription how axes or so are represented as variables". To me the essential elements for a transformation model would be representation of the actual “things” that are being mapped or transformed and how these are represented in the operations. (I have some initial suggestion how that can be modelled if you’re interested).

Cheers
Gerard




From: dm-bounces at ivoa.net <dm-bounces at ivoa.net> On Behalf Of Patrick Dowler
Sent: Friday, March 6, 2020 23:14
To: CresitelloDittmar, Mark <mdittmar at cfa.harvard.edu>
Cc: Data Models mailing list <dm at ivoa.net>
Subject: Re: [vo-dml] Clarification on composition rule..

I don't understand "NOTE: the nature of several operations require it to be an ObjectType rather than a DataType, so these can't be Attributes."

I have created models with DataType(s) that are "structures" so I could use them as attributes in multiple places and I have declared DataType(s) that extend (subclass) other DataType(s). Both of those are vodml compliant...  what is it that requires TOperation to be an ObjectType? Is it a philosophical issue?

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


On Wed, 4 Mar 2020 at 09:43, CresitelloDittmar, Mark <mdittmar at cfa.harvard.edu<mailto:mdittmar at cfa.harvard.edu>> wrote:
Hi,

In the Transform model, we have a case where we want to use the same Object with different roles in the parent Object.
Specifically, we want to define a "Mapping" with a forward and inverse "Operation".

What I'd like to do is:
[A.png]

But the VO-DML rec states; Section 4.17, pg 48, "an ObjectType can only be the target of at most one Composition relation".
And this does indeed fail vo-dml validation.   NOTE: the nature of several operations require it to be an ObjectType rather than a DataType, so these can't be Attributes.

I CAN do:
[B.png]

Which has only 1 composition, but is hacky and not very user-friendly.. I'd really prefer to have explicit 'forward' and 'inverse' tags.
To make a vo-dml compliant version of the first diagram, I need to add a layer to the model.  This works fine, and is the current model, but is rather ugly and makes it a little more difficult to interpret.

[C.png]

Mainly, I think I'm looking to confirm that the rule in Section 4.17 is intended to include this case.
I expect it is, and has to do with RDB implementations and distinguishing the instances, but I'm not a DB person and don't fully get all that.

Mark

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20200307/2741b60c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 14429 bytes
Desc: image001.png
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20200307/2741b60c/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 17641 bytes
Desc: image002.png
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20200307/2741b60c/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 24587 bytes
Desc: image003.png
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20200307/2741b60c/attachment-0005.png>