[utypes] Wild edit towards more principled definitions

Fri May 18 04:37:43 PDT 2012

Gerard,

This is great! And maybe I didn't do a good job, but this is mostly what I
had understood of vo-urp, and we basically agree on the problem and its
solution.

What I didn't get was that you have your own language: when I tried to use
vo-urp it looked like I was required to use one particular uml modeler
because vo-urp needed a particular xmi flavor to start doing its magic. If
that's not true, then we are closer than I thought.

The other concern is that we have some serious interoperability issues with
utypes. They become apparent more on the client side when you try to build
science applications. We should make sure that we address these issues, if
you haven't already.

I remember that after Pune we decided to ask you if you could finalize a
work you had started on an abstract data model definition. I didn't have
any news about your availability, so I started working on my own meta-model
and proposed that one, suggesting that we could later bind it to vo-urp,
which I wanted to include in the picture from the start (I think I
mentioned it even in Pune).

So, I hope you will be available to help putting all together. We need to
make sure that we address all the requirements and issues that have been
raised.

See you in Urbana,

Omar.

P.S. I am not sure how to read your comments about "theory guys", but this
is the common use of the term at least here in the States: it refers to
people of either sex, as acknowledged also by the Oxford dictionary.
On May 18, 2012 6:08 AM, "Gerard Lemson" <lemson at mpa-garching.mpg.de> wrote:

> Dear Omar ****
>
> ** **
>
> My apologies for jumping into this utype discussion so late. ****
>
> Markus had pointed me to this thread on UTYPEs, which I had seen, but not
> read in detail. ****
>
> ** **
>
> I want to give some comments from both Laurent Bourges and me.****
>
> It's also a preview of points I will make in my presentation in the UTYPEs
> session.****
>
> I CC the DM mailing list as I think it deserves a broader context.****
>
> ** **
>
> Both Markus and you do seem to realize the need for a more abstract,
> common language for describing data models. ****
>
> We agree with that. We also agree with you that Markus' proposal for "data
> model as DAG" is too****
>
> limited to describe real data models. ****
>
> We disagree with you though that such a language must still be developed.
> ****
>
> ** **
>
> Instead extensive work in this direction has been performed already.****
>
> You acknowledge "the theory guys" (i.e. us) have done work on this, but
> misrepresent our approach.****
>
> (Btw, the girls who were leading the DM WG when we started working on this
> have been made aware of our effort****
>
> From the beginning and also Patrizia Manzato has contributed to the theory
> work).****
>
> ** **
>
> The work I refer to is VO-URP, which stands for ‘Virtual Observatory - UML
> Representation Pipeline‘****
>
> and is a spin-off of the theory simulation data model effort.****
>
> VO-URP was developed to simplify data modeling efforts like the one we did
> for simulations, ****
>
> but it is independent of any theory-related concepts.****
>
> First of all it defines what we call  the .vo-urp representation of a data
> model.****
>
> This can be seen as a domain specific language for data modeling within
> the VO context****
>
> It basically is an abstract data modeling language like the one both you
> and Markus are looking for.****
>
> ** **
>
> From this representation, VO-URP automates the derivation of alternative
> representations of the model.****
>
> Such representations are generally necessary to work with a model in
> particular contexts.****
>
> Some of these accompany the SimDM specification, notably XML schemas and a
> UTYPEs list ****
>
> (which are somehow mandatory for IVOA DM efforts).****
>
> The automation was very helpful during the SimDM effort as it greatly
> simplified forwarding data model changes ****
>
> to the other representations. ****
>
> ** **
>
> VO-URP was also extremely helpful in creating a reference implementation
> of the model.****
>
> http://galformod.mpa-garching.mpg.de/dev/SimDM-browser/****
>
> is a web application implemented using generated Java class,****
>
> that allows one to browse a database designed according to the (automated)
> ****
>
> relational mapping of SimDM. This mapping is represented using a
> (generated) TAP_SCHEMA and the web app allows****
>
> one to query the database with SQL (full TAP support can be added).****
>
> The webapp allows up- and downloading XML documents following the
> (generated) XML schema representation of SimDM.****
>
> Documentation of the data model is available in the form of a (generated)
> cross linked****
>
> HTML file that contains a full list of UTYPEs identifying each element in
> the data model and****
>
> as an extra a clickable model diagram produced using GraphViz from
> generated 'dot' files.****
>
> ** **
>
> VO-URP has been worked on mainly by Laurent and me, but with lots of
> feedback and use by the “theory people” in France, San Diego and Italy. It
> has its own GoogleCode project in http://vo-urp.googlecode.com.****
>
> VO-URP has been presented at many interops, either explicitly (starting in
> Trieste, 2008), or as part of ****
>
> presentations on SimDM. It also has been explicitly mentioned in the SimDM
> spec itself. ****
>
> ** **
>
> All of this we thought would be of interest to the data modeling efforts
> in the IVOA in general.****
>
> But though we have asked for contributions from the VO community, VO-URP
> has mainly been ignored outside the SimDM effort.****
>
> Only the part of VO-URP dealing with UTYPEs, a BNF defining UTYPEs in
> terms of data model constructs, ****
>
> has been used in Mireille's first drafts of the UTYPE document. That
> document pulls it out of context,****
>
> so much that the core concepts underlying VO-URP were apparently lost on
> subsequent editors.****
>
> ** **
>
> We think that the VO-URP project contains most features required for a
> domain specific data modeling language.****
>
> It contains proven, workable, implemented mappings to other useful
> representations.****
>
> We produce UTYPEs, but think (with you and Markus and likely others) that
> a simple grammar to produce a list of words****
>
> is not sufficient for a proper (re)use of data models in general.****
>
> And we'd love to finally be able to further develop VO-URP with those
> concepts in the context of the IVOA DM WG.****
>
> ** **
>
> Looking forward to discussing all of this with you all in Urbana****
>
> ** **
>
> Best regards****
>
> ** **
>
> Gerard Lemson****
>
> also for Laurent Bourges****
>
> ** **
>
> ** **
>
> *From:* utypes-bounces at ivoa.net [mailto:utypes-bounces at ivoa.net] *On
> Behalf Of *Omar Laurino
> *Sent:* 20 December 2011 16:27
> *To:* Mireille Louys
> *Cc:* utypes at ivoa.net
> *Subject:* Re: [utypes] Wild edit towards more principled definitions****
>
> ** **
>
> Hi Markus,****
>
> ** **
>
> Again, thank you for moving this effort forward.****
>
> ** **
>
> I like your formal approach very much, I think we need it. And I like your
> efforts to abstract the data model description.****
>
> ** **
>
> However, I have some concerns:****
>
> 1. Your formalization (and the previous draft, to some extent), starts
> from the XML schema to define the DM graph and then the Utypes. However, I
> think that the XSD should be a final product of the Data Modeling effort.
> ****
>
> ** **
>
> I think this for several reasons. First of all, you need to be sure that
> the XSD is properly representing your Data Model, and this looks more like
> a "trial and error" process to me [write the XML schema, see how the graph
> looks like, then go back to the XSD and iterate]. In other words, I think
> the Data Model comes first, and then you produce all the data products (you
> need the Data Model at least in your mind to describe it using XSD,
> right?). To be honest, I even think that the DM description document should
> be written automatically as a stub, and then the human should simply add
> the human relevant information. So, I would go the other way, turning over
> the algorithm to go from the Graph to the XSD.****
>
> ** **
>
> I think this was the approach of the Theory guys, by the way: they start
> from the Data Model UML description (in XMI) and then use it to derive all
> the "products" (XSD schema, utypes, documentation). I don't think this
> approach can work for a standard specification, though, because it assumes
> the use of tools (XMI compliant Data Modeling tools) that are hardly
> interoperable. I still think the approach is great, but it is an approach
> that *uses* a standard definition of Data Models and Utypes, not being the
> standard itself. It can be considered a reference implementation that
> validates the standard employing a particular set of tools, though. In
> other terms, we still need an interoperable description for IVOA Data
> Models (which is a subspace of the infinite data modeling space).****
>
> ** **
>
> 2. It seems to me that your model doesn't capture instantiation and
> inheritance. In your sample XSD you define both TimeAxisType and
> SpectralAxisType, even though SpectralAxis and TimeAxis are two instances
> of the same class: your algorithm reflects this, if I am not mistaken. I am
> sure you can complicate your algorithm to adapt, but this requires modeling
> the Data Model itself, not its representation, so that you work in a "meta
> Data Model" space. Also, in your schema there is no room for extensions,
> which is quite a hot topic. ****
>
> ** **
>
> 3. In your description, you can drop the prefix without losing any
> information. Also, let's say I have got two Data Models: they both employ a
> SpectralAxis and a TimeAxis to describe the very same information. They
> will have two different Utypes, which means that they point to different
> concepts! Unless you ignore the prefix, which, again, makes it redundant.*
> ***
>
> ** **
>
> So, I think your formalization works for building the Utype paths, but
> this is only part of the deal. We need to define a meta space in which the
> Data Models live, we need to provide mechanisms for allowing the clients to
> spot instances of known classes in the datasets, and to allow data models
> to correctly include and/or extend classes defined in other models (which
> is what Data Models already do in a non standard nor formal way).****
>
> ** **
>
> Another couple of minor concerns: we still don't include the DataTypes
> into the picture. Again, I think this is due to the fact that the document
> focuses on building the Utype path, so we need to take a step back and fit
> the path in the bigger picture of Data Model instances serialization. Also,
> there is still no room for versions. You make reference to it, but you seem
> to offload the problem.****
>
> ** **
>
> That said, I would like to send you guys the draft I have been working on
> ASAP. I'm validating it by building a reference implementation in the form
> of a java library, which helps a lot the design.****
>
> ** **
>
> Here is, very briefly, the big picture: I am trying to address the three
> main problems we have in order to make utypes *much more* useful (they are
> useful already) and to match our requirements:****
>
> 1) Data Model design specification (data modeling of the IVOA Data Model
> space, reusable components in terms of inheritance and instantiation,
> collections of objects, versioning).****
>
> ** **
>
> 2) Data Model description (utypes, automatic generation of code, etc.)****
>
> ** **
>
> 3) Standardization of abstract serialization strategies based on utypes.
> The serialization must allow clients to spot the instances of the objects
> they know and to build a tree representation of those they don't know.****
>
> ** **
>
> The prototype library looks in pretty good shape. As soon as I've got
> something useful to show I will send you my results.****
>
> ** **
>
> Cheers,****
>
> ** **
>
> Omar.****
>
> ** **
>
> ** **
>
> ** **
>
> On Mon, Dec 19, 2011 at 11:34 AM, Omar Laurino <
> olaurino at head.cfa.harvard.edu> wrote:****
>
> Hi Markus, All,****
>
> ** **
>
> I wanted to come up with a draft last week, but I didn't make it. Also I
> haven't had time to review your draft. I will work on the Utypes document
> today and provide you with some feedback.****
>
> ** **
>
> Thanks for your contribution!****
>
> ** **
>
> Cheers,****
>
> ** **
>
> Omar.****
>
> ** **
>
> On Wed, Dec 14, 2011 at 11:52 AM, Mireille Louys <
> mireille.louys at unistra.fr> wrote:****
>
> Hello, Markus, all,
>
> Thanks for pushing this effort forward.
> I 'll have a close look next week.
> I currently have deep teaching commitments.
>
> best wishes , Mireille
>
> Markus Demleitner <msdemlei at ari.uni-heidelberg.de> a écrit :****
>
> Dear colleagues,
>
> As those of you who followed my talk in Pune
> (http://docs.g-vo.org/talks/2011-pune-utypes.pdf) may have feared (or
> hoped; there were some approving gestures back at the talk), I've now
> spent some quality time rewriting the chapters 2-4 for the utype
> specification.****
>
> ...****
>
>
>
> If, on the other hand, you think I'm mad and you'll never agree to
> such extensive changes to the utypes document (or to such a
> dumbing-down of data modelling, or whatever), *please* by all means
> speak up now.  I'll not be cross.  Promised.  You'll be saving me a
> lot of work.
>
> Finally, of course, if you think only parts of what I've tried are
> dead wrong, you're of course welcome to complain (or even fix), too.
>
> Cheers,
>
>          Markus****
>
>
> --
> Mireille Louys, assistant professor at  UDS: ENSPS, Laboratoire ICube et
> CDS
> Observatoire de Strasbourg
> mail to: mireille.louys at unistra.fr
> Tel: +33 3 68 85 24 34
> Adress 1: CDS/Observatoire de Strasbourg
> 11, rue de l'Université
> 67000 STRASBOURG****
>
>
>
>
> _______________________________________________
> utypes mailing list
> utypes at ivoa.net
> http://www.ivoa.net/mailman/listinfo/utypes****
>
> ** **
>
> ** **
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dm/attachments/20120518/94e172b0/attachment-0001.html>