[utypes] Wild edit towards more principled definitions

[Laurent MICHEL]

H,


Le 08/02/12 11:55, Markus Demleitner a écrit :
> 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.

I Agree, this point must be a bit more developed in the document
>
> 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?
Looks 100% OK to me according to the fact that Utypes do not carry any 
type information.


>
>> 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.

The point is here to make sure that UTypes attached to a given model 
have a structure consistent with that model and that UType path elements 
reflect model nodes.

Cheers
LM
>
> Cheers,
>
>         Markus
>
> _______________________________________________
> utypes mailing list
> utypes at ivoa.net
> http://www.ivoa.net/mailman/listinfo/utypes

-- 
---- Laurent MICHEL              Tel  (33 0) 3 68 85 24 37
      Observatoire de Strasbourg  Fax  (33 0) 3 68 85 24 32
      11 Rue de l'Universite      Mail laurent.michel at astro.unistra.fr
      67000 Strasbourg (France)   Web  http://astro.u-strasbg.fr/~michel
---