UTYPEs and UFIs

[Pedro Osuna]

Hi Jonathan,

nice piece of work. I send you here what we had already compiled and  
showed in Beijing. We would obviously like to be part of the  
definition of UFIs, as they are of the utmost importance for  
discovery (ADQL) purposes, from which the issue was raised the first  
time.

The attached (see below) summary was compiled in April this year by  
Aurelien Stebe from our work here (Aurelien, Inaki, Alberto, Jesus  
and myself) after discussions with you and others prior to Beijing. I  
have changed unique UTYpes for UFIs to follow your new naming...

I also attach our possible answer to your open questions.

I am not sure I will be able to allocate much on our discussion for  
UTypes in our -single- VOQL session. In Beijing we agreed that you  
and myself would initiate this work, but there has not been much  
coordination and I am afraid that just a small bit on the last part  
of our single VOQL session might not be enough...

Maybe we have the chance to try to allocate more time if we meet  
during ADASS....

We keep in touch.
Cheers,
P.

On Unique UTYpes (====> UFIs in the new nomenclature)
------------------------------------------------------------------------ 
------

UFIs should be *unique* identifiers for elements in a DM.

They could respect the following BNF (from Alberto) :
<alpha> ::=  a|b|c|d|e|f|g|h|i|j|k|l|m|n|o|p|q|r|s|t|u|v|w|x|y|z
            |A|B|C|D|E|F|G|H|I|J|K|L|M|N|O|P|Q|R|S|T|U|V|W|X|Y|Z
<digit> ::=  0|1|2|3|4|5|6|7|8|9
<char>  ::= <alpha>|<digit>|-|_
<period> ::== .
<colon> ::== :
<word-component> ::= <alpha>|<digit>|<word-component><char>
<namespace-ref> ::= <word-component>
<word> ::= <word-component>|<word><period><word-component>
<UFI> :: = <namespace-ref><colon><word>|<word>

that is for ex:         char:Axis.Time.start

By uniquely pointing at an element in a DM both the type and the  
usage of that element is known (should be clear in the DM).
UFIs could be constructed by reading the DM UML diagram from the root  
and writing in sequence the names of the entities separated by single  
dots until reaching the desired information to describe. Hence, the  
UML is the normative info and the UFis should stem from it  
automatically.

A convention might be to write UFIs following OO names case :  
"classes" first letter uppercase, following words first letter  
uppercase, all the rest lowercase.
The namespace prefix to use should be fixed by the DM doc. (it is the  
case more or less with "spec" "char" or "ssa")

New UFIs for attribute specification (filtering)
==================================
It is hard for the moment to express "the RA coord value of the  
center of the image in FK5".
It is possible to filter on it in a query writing something like :  
WHERE char:Axis.Spatial.coordSys = "FK5" AND  
char:Axis.Spatial.Center.ra < 42 AND NECESSARY_JOINS
But it is not possible to give a unique name to this value if  
returned in table format.

The proposal :   write it like this    =>      char:Axis.Spatial 
[coordSys="FK5"].Center.ra

A few things to discuss: use square brackets or curly brackets ? I  
would avoid parenthesis and XML type tags because already present in  
an ADQL syntax.
    force quotes around string type values ? or just write    
[coordSys=FK5]
    allow multiple conditional filters ?  like   [coordSys="FK5" and  
epoch="J200"]
          or even     char:Axis.Spatial[coordSys="FK5"].Center 
[unit="deg"].ra

If we want Registry people to use this also, they will want it to be  
fully compatible with XPath (especially AstroGrid). That is, square  
brackets, with quotes and "@" identifier for attributes (ex:   
char:Axis.Spatial[@coordSys="FK5"].Center.ra) .... they might even  
want slashes instead of dots. .... and meaningful namespaces => no  
"char:" if it is not declared and is the actual NS in the schema.
------------------------------------------------------------------------ 
------------------------------------------------------------------------ 
-
Possible answers to the questions on your document follow:
===============================================
** Spectrum.Target.Name  OR  spec:Target.Name    ->  Advantages and  
disadvantages on both side. Easier if we can avoid actual XML  
namespace declarations.
** Top Level Scope : yes, identify clearly in the IVOA, which DM are  
Top Level and which ones are only meant to be used by other DMs.
** Combining DMs : no, do not use the UCD system (UCD1;UCD2). If  
UType is too long, maybe the DM is wrong or the DM is just very complex.
** UFIs : token1.token2[attr1=valA].token3   That's our (only) idea/ 
solution, and it is the solution from the W3C also (XPath). But let's  
do it like in the Registry WG, use what we need from XPath and only  
what we really need.
** U = U.Value : no, a single element to map is much simpler than  
optional possibilities.  "value" should not exist in a DM anyway.
** Base UTypes on UML or XSD ? Should be rather identical, but I  
think XSD-based would allow actual XPath like usage of the UType.
** VOTable and UTypes : no, do not inherit the root of the UType from  
the GROUP, makes for too much parsing.

Cheers,
P.



On Sep 18, 2007, at 2:38 PM, Jonathan McDowell wrote:

>
> Dear DM team,
>  I have prepared a note on my view of the role and syntax of UTYPEs
> (data model field labels) and their relationship to what I call UFIs
> (ways to describe/locate uniquely a piece of information in a DM  
> instance),
> to set things up for discussion in Cambridge.
>  The doc is
>   http://hea-www.harvard.edu/~jcm/vo/docs/utype/ut2.pdf
>
> See you in the UK
>  Jonathan McDowell



_________________________________________
Pedro Osuna Alcalaya

European Space Agency (ESA)
European Space Astronomy Centre (ESAC)
Science Operations Department (SCI-O)
Science Archives and Computer Support Engineering Unit (SCI-OE)
e-mail: Pedro.Osuna at esa.int
Tel + 34 91 813 13 14    Fax: +34 91 813 11 72
_________________________________________
European Space Astronomy Centre (ESAC)
P.O. Box 50727
E-28080 Villafranca del Castillo
MADRID - SPAIN





================================================================================================
This message and any attachments are intended for the use of the addressee or addressees only. The
unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content
is prohibited. If you received this message in error, please delete it from your system and notify
the sender. E-mails can be altered and their integrity cannot be guaranteed. ESA shall not be liable
for any e-mail if modified.
=================================================================================================

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dm/attachments/20070919/e4b2f882/attachment-0001.html>