vo-dml for cube

[Laurino, Omar]

Francois,

On Wed, Dec 16, 2015 at 5:11 AM, François Bonnarel <
francois.bonnarel at astro.unistra.fr> wrote:

> - Semantically a coefficient is basically just a number and become a
> coefficient only in the context of polynomial. And we want anything done
> for polynomials in the STC model to be independant of the order


I agree, although a coefficient may have both an order and a value (hence a
polynomial without a coefficient for a given order would have 0 for that
order).

Three important points, imo:
   * Do Coefficients have identity? I don't think so, hence I think they
are DataTypes. And a Polynomial would be an Object Type (it has identity,
you can refer to a particular instance of a Polynomial by its "name"... it
may even be stored somewhere else) with a variable length array of
Coefficients. [For the record, I think that polynomials may be Data Types
just as well, but for the sake of argument I'll keep considering them
Objects]

   * You may want to represent polynomial instances within a Java
application: you would most likely use two classes: one for Polynomial,
with a List<Coefficient> coefficients field, a String description field,
and an ID field (maybe a URI); and one class for Coefficient, with an int
attribute for the order and a double for the value. They are both java
classes, but one represents an Object Type, and one represents a Data Type:
the semantic difference between the two fundamental Types is not reflected
by the structure you use to represent them in a specific implementation.
Data Types and Object Types may both map to classes in an OO language.

   * You may want to store polynomial instances within a relational
database: you would most likely have two tables, one for Polynomial, with
an ID column and a description column, and one table for Coefficients,
without primary key, but with a column Polynomial_ID that is a foreign key
pointing to the Polynomial instances, a column for the order, and a column
for the value. You would also have DB constraints that dictate that when a
Polynomial instance (a row in the table) is deleted, the corresponding
coefficients are deleted as well, because a coefficient does not make
sense, cannot exist, without the owning Polynomial, which is one of the
characterizations of Data Type.

In this discussion I am arguing that there is a clear mapping, through ORM,
between the Java representation of the instances (or any object-oriented
language), and their representation in the database, despite the fact that
Object Oriented languages and Relational Databases are intrinsically
different, and often times incompatible. If I was wrong, and this mapping
would not be clear, or possible at all, then my argument would fail and
variable length arrays should indeed be left off the language. This is the
crux of the issue, I believe.

The fact that VO-DML allows automatic data binding and code generation is a
plus that may be really useful for a number of applications, and may
validate the generality of the language, but it does not mean, in any
possible way, that VO-DML is meant to be used exclusively for automatic
generation of code. That's useful, by definition, for model-unaware
applications. Model-aware applications should apply their own optimizations
to efficiently represent and manipulate domain-specific instances.

Omar.


-- 
Omar Laurino
Smithsonian Astrophysical Observatory
Harvard-Smithsonian Center for Astrophysics
100 Acorn Park Dr. R-377 MS-81
02140 Cambridge, MA
(617) 495-7227
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20151216/eda001c3/attachment.html>