[vo-dml] Clarification on composition rule..

[CresitelloDittmar, Mark]

Pat,

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


On Fri, Mar 6, 2020 at 5:13 PM Patrick Dowler <pdowler.cadc at gmail.com>
wrote:

> 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> 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:
>> [image: 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:
>> [image: 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.
>>
>> [image: 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/20200309/a1f1ec63/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: A.png
Type: image/png
Size: 14429 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20200309/a1f1ec63/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: B.png
Type: image/png
Size: 17641 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20200309/a1f1ec63/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: C.png
Type: image/png
Size: 24587 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20200309/a1f1ec63/attachment-0005.png>