[utypes] Wild edit towards more principled definitions
Markus Demleitner
msdemlei at ari.uni-heidelberg.de
Wed Feb 8 02:55:38 PST 2012
Hi,
On Wed, Feb 08, 2012 at 09:51:56AM +0100, Laurent Michel wrote:
> A DM contains quite more information than a graph can do. Semantic
> information is for instance completely ignored by the graph. The
> exact nature of vertex (class or role) is also skipped.
Yes, true; I never intended to imply data modelling should take place
using DAGs. The point was to extract what all formalisms must have
in common *and* is just sufficient to come up with utypes.
By the way, I believe the most important information thrown away in
the abstraction process is types. I think this may be a good moment
to discuss whether we can reach a consensus on the approach in the
"wild edit", viz,
The values in utype-value pairs are always strings.
The *interpretation* of these strings (as sedecimal integers, ISO
date times, STC-S strings, or whatever) is up to the data model in
this approach. Serialization rules the container format (VOTable,
FITS, text files) might have do not apply. Thus, the interface
between a library handling a data model would accept "sequences of
pairs of strings" (possibly arranged in a superstructure) as opposed
to "sequences of pairs of string and parsed values".
Does this sound like a reasonable plan to you?
> I propose to suggest DM designers to provide such graphs with their
> models. That could very helpful to ensure the consistence between
> UTypes and the DM they come from, but we can not consider graphs
> themselves as model definitions.
100% agreed. Let me just add that usually, the DM specs would not
explicitely give the graphs but rather means of coming up with them;
for (a subset of) XSD files, I've already done this (using XSLT), so
the additional effort is probably neglible if your data model
definition comes as an XSD. I'd expect analogous formalisms aren't
hard to develop for alternative modelling tools.
Cheers,
Markus
More information about the utypes
mailing list