UType proposals

[Gerard]

Hi Norman
I think I agree with most of your proposal. 
In particular as far as it concerns the interpretation of the model-name.
But I definitly think there is merit in proposing a readable syntax for
Utype-s derived from a (well designed) data model.

The proposal for the Utype syntax in Mireille's document has its origins in
our work on SimDB.
In SimDB we wanted to come up with a rule for creating a Utype for the
elements in SimDB's data model,
mainly because we did not want to have to do two jobs: 
1. create the model
2. create a list of strings uniquely representing the elements in the model.

So we wanted a rule that allows us to generate the Utype for the model
(implemented in XSLT working on the XMI).
The Utype was to be a string that should be unique (within the context of
the model) and we wanted it to reflect the location of the referenced
element in the model. The latter allows one to find the element represented
by the string in the model by parsing the string.
In out rule (repeated in Mireille's note) the uniqueness of the string is
guaranteed by the structure of the rule and the constraints that data models
impose (e.g. uniqueness of names of classes in a package, uniqueness of
attribute names in a class etc).

We do associate these strings to various representations of the model,
though not yet in a dereferencable manner.
The HTML documentation for the model is generated and contains for each
documented element its Utype.
Also the "intermediate representation", a more readable XML version of the
XMI that is the basis for our generation pipeline, should contain the utype
for each element. So in principle the association is there and we could have
used SimDB:element1 etc.

For us the human readable structure of the Utype was important, as it allows
one to connect back directly to the UML diagram and find the appropriate box
or attribute. In documentation, emails, conversation I have already found it
very useful to be able to use a meaningful, Utype-like expression. 
For example dicsussing the relation between a SimDB:simdb/Resource and a
Registry:Resource it is nice I can use terms that make direct sense.
So for the DM group to propose a rule for deriving Utype-s from the data
model that does not require a separate lookup, i.e. is parsable by humans I
think is not a bad thing as it promotes homogeneity and readability between
different modelling efforts.

But this does not mean it can not be combined with your proposal. I think
they shold be dereferenceable as well.

So I do agree with you that the model-name should refer to a namespace, and
not "be" the namespace.
One should be able to infer from the context within which the utype is used
where to go to find this namespace. That's why I think such namespaces
should for example be explicitly defined in a VOTable that uses a particular
set of Utype-s. It should not depend on some list of abbreviations somewhare
in the IVOA.
Hence I also do not like the proposal NOT to insist on an xmlns:adql=...
declaration to infer info about the new 'xtype' attrbute.

I also agree that the Utype itself should be dereferencable to HTML.
The HTML that we generate for SimDB's data model can easily be accomdated to
be such a target. 
Currently we use XMI identifiers as anchors for cross-linking, but as our
Utype-s are unique those could be used as well.

As I mentioned above we generate an XML representation of the model that
contains the Utypes and could serve as a machine readable representation.
Currently this document could be the target for the SimDB namespace as a
whole, not for one single Utype. 
Those can be found from that document using simple XSLT (search for
*[@utype=...] or something like that).
Clearly other representations can be created, RDF or who knows what.

Finally, I think one thing that Mireille's note does not make clear is that
to be able to have a rule deriving parsable Utypes from a data model such as
the one used in SimDB, one must have defined the syntactic elements for
expressing one's data model. In SimDB we do this explicitly and we have
proposed a similar approach to the DM group. Once one has that one may also
have hope of creating instances for a specified Utype.

Really finally, I think we still need discussion about what it really means
to associate a Utype to some serialised construct.
For example, in VOTable, associating a Utype to a column, pointing to aan
attribute in a data model seems pretty well defined.
The column contains values that may have been obtained from that attribute
on instances of the referenced.

However what it means to associate a Utype to a TABLE is less clear. 
Should it be formally and completely equivalent to the referenced Class
(supposedly) in a UML diagram.
Should it then have the same attributes (represented as columns) for
example. 
Or is it the meaning less strict, more conceptual. Like "the TABLE is
somewhat similar to a SimDB:Simulation" for example.

Cheers

Gerard



> -----Original Message-----
> From: Norman Gray [mailto:norman at astro.gla.ac.uk] 
> Sent: Friday, June 12, 2009 12:23 AM
> To: dm at ivoa.net
> Subject: UType proposals
> 
> 
> Greetings, all.
> 
> For your delectation and delight, I present a concrete 
> version of the UType proposal I briefly discussed with some 
> people in Strasbourg two weeks ago.
> 
>      http://nxg.me.uk/note/2009/utype-proposals/
> 
> This document is not intended to be a counterproposal. I 
> believe it is at heart the same proposal as Mireille's, but 
> arrived at from a rather different direction, and so 
> justified in a different way. The principal syntactic 
> difference is that the model-name Utype elements are here 
> references to a namespace, rather than regarded as the 
> namespace themselves.
> 
> I don't claim that this is necessarily as polished or 
> well-argued as it could be, but if I continue to fiddle with 
> it, it'll never appear in time to make any useful 
> contribution to this process.
> 
> Best wishes,
> 
> Norman
> 
> 
> --
> Norman Gray  :  http://nxg.me.uk
> Dept Physics and Astronomy, University of Leicester
> 
>