Using Quantity in Char model (Was: Re: Characterization data model

[Brian Thomas]

	Francois, All,

	I just wanted to turn around comments on the Characterization schema
	as far as the implementation using Quantity.

	Looking at the schema (which I have done quickly) I see that the Q is used
	in one spot, e.g. the definition of "CharQuantityType" which is reused in
	several spots around the schema. No problem with that approach. The choice
	of Quantity, is however an issue for me. To better describe this point, lets look
	at the definition of "CharQuantityType" you have in the 0505 schema:

        <xsd:complexType name="CharQuantityType">
                <xsd:complexContent>
                        <xsd:restriction base="q:CompositeQuantityType">
                                <xsd:sequence>
                                        <xsd:choice>
                                                <!-- type 1 : scalar needs dataType + units -->
                                                <xsd:sequence>
                                                        <xsd:element ref="unit:UnitsGroup" minOccurs="0"/>
                                                        <xsd:element ref="q:ScalarDataTypeGroup" minOccurs="0"/>
                                                </xsd:sequence>
                                                <!-- type 2 : vector needs dataType only -->
                                                <xsd:element ref="q:vector"/>
                                        </xsd:choice>
                                        <xsd:element name="name" type="q:stringType"/>
                                </xsd:sequence>
                                <xsd:attributeGroup ref="q:CompositeQuantityAttribs"/>
                        </xsd:restriction>
                        <!-- Caution "q" is the Quantity.xsd in VOCatalogTest/schema_and_examples/
             not the full q -->
                </xsd:complexContent>
        </xsd:complexType>

	Here you have chosen to use a restricted composite quantity as parent 'class' for char
	quantity (no problem with that), however, your restriction chooses to include 
	"vector" type definition. I *do* have an issue with that. What you are effectively doing is
	looking for some type of "compression" mechanism to specify the min/max for limits,
	bounds and other characterization structures that inherit from it. I think this is going too far, 
	and its better to fully specify the 'min' and 'max' as quantities themselves.

	Therefore, I would rather write:

        <xsd:complexType name="CharQuantityType">
                <xsd:complexContent>
                        <xsd:restriction base="q:CompositeQuantityType">
                                <xsd:sequence>

				     <!-- *always* require that a 'min' and a 'max' Q exist -->
                                     <xsd:element name="min" type="minQuantityType" substitutionGroup="QuantityGroup"/>
                                     <xsd:element name="max" type="maxQuantityType" substitutionGroup="QuantityGroup"/>

                                     <!-- allow other Q's as meta-data -->
                                     <xsd:choice maxOccurs="unbounded">
                                          <xsd:element ref="QuantityGroup"/>
                                           <xsd:element ref="ListQuantityGroup"/>
                                   </xsd:choice>

				   <!-- allow UCD -->
                                    <xsd:element ref="ucd:UCDGroup" minOccurs="0" maxOccurs="1"/>
                                </xsd:sequence>

                                <xsd:attributeGroup ref="q:CompositeQuantityAttribs"/>
                        </xsd:restriction>
                        <!-- Caution "q" is the Quantity.xsd in VOCatalogTest/schema_and_examples/
             not the full q -->
                </xsd:complexContent>
        </xsd:complexType>

	So that the container is both more flexible (in that min/max not constrained to have the same
	units/datatype...which *can* occur) and more expressive (not relying on implicit ordering in
	a vector to know which is 'min' and which is 'max' value). Also, as tangential point, the 
	above model choice allows to have a UCD and additional meta-data added to the structure
	(which is important).

	And thats about it for now. Hope the Kyoto meeting is going well and productive.

	Best Regards,

	=b.t.

On Monday 16 May 2005 06:30 am, Francois Bonnarel wrote:
> Dear all, 
> 
> Just to inform everybody that a new version of UML schema for Characterization 
> and of the
> 
> xml schema are now available taking into accounts the results of discussion we 
> (ML+FB) 
> 
> had with Alberto Micol, Brian Thomas and Arnold Rots.
> 
> (http://alinda.u-strasbg.fr/Model/Characterisation/   DM and xhar0505.xsd)
> 
> 
> 
> The general frame has been modified in the following way:
> 
> - Levels of description have been added in Resolution and Sampling in order to 
> get a parallel
> 
> path there and in Coverage, and take into account the internal variation of 
> these properties. But the
> 
>  Names and even the internal structure of these levels are different in 
> Resolution/sampling and in Coverage. 
> 
> - The Accuracy (Stat err) property structured like Resolution and Sampling has 
> been added, because it
> 
>  seems to be really usefull to characterize the Obserbvation data, don't fit 
> elsewhere in the model and was
> 
>  actually allready included in "characterization" by the SSA proposal.
> 
> The xml schema has been heavily revised to be considered as a part of a 
> general set of VO Dm Schema
> 
> reusing Quantity and STC definitions. Actually we used the schemata 
> implementation proposed
> 
> by Brian Thomas for VO Catalog (http://archive.astro.edu/VOCatalogTest/). 
> Brian's proposal rewrites most of
> 
> STC stuff as Quantities. So that was easier for us to define our main 
> Characterization ComplexTypes
> 
> as CompositeQuantities and to reuse all the STC types we need for our basic 
> Types this way. The basic idea
> 
> we took from Brian is to consider Charcterization types as "restrictions" of 
> CompositeQuantties instead of
> 
> definig Extensions, or to simply use elements of Q or STC type inside our type 
> definitions sequences.
> 
> Brian , if you could have a look to this and comment it could be usefull for 
> our session of Thursday.
> 
> Mireille Louys and François
> 

-- 
--------------------------------------
|                                     
| Dr. Brian Thomas                    
|                                     
| Dept of Astronomy                   
| University of Maryland-College Park 
|
| Phone: (301) 405-2312               
| Fax: (301) 314-9067                 
|                                     
--------------------------------------