Using Quantity in Char model (Was: Re: Characterization data model
Francois Bonnarel
bonnarel at alinda.u-strasbg.fr
Mon May 23 08:03:03 PDT 2005
Dear Brian,
We have no objection in using Quantity for Min and Max. Look, We allready did it in
that version! -see our LimitsType -(Actually we put TrivialQuantity, but it should be
AtomicQuantity if we want to have independant units as you say)
However There has been some misunderstanding of what we did (or tried to do).
By defining CharQuantity we wanted to have a container common to all the main
types of Characterisation and providing:
units, ucd, datatype, a name, and maybe the CoordSys.
(You probably remember my (FB) brain is VOTable wired, and we want to use a quantity
which allow us the same than a FIELD or PARAM does).
SO we BORROWED your CompositeQuantity, but the one we found in :
<!-- Caution "q" is the Quantity.xsd in VOCatalogTest/schema_and_examples/
not the full q -->
which is actually allready a restriction of the main CompositeQuantity
available at www.datamodel.net. This type allready had UCD and coordSys: We added
the unit and storageType. For this we reused a block you defined - again in
VOCatalogTest/schema_and_examples/ - in the Frame TYPE. This block had the
vector as a choice, we let that although we are not using it. It can be removed
I Think.
My conclusion here is that CharQuantity should probably be better defined
by directly using the full CompositeQuantity (the one at www.datamodel.net) and
restrict it like this:
<xsd:complexType name="CharQuantityType">
<xsd:complexContent>
<xsd:restriction base="q:CompositeQuantityType">
<xsd:sequence>
<!-- allow insertion of other q's here as meta-data -->
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="QuantityGroup"/>
<xsd:element ref="ListQuantityGroup"/>
</xsd:choice>
<!-- special named meta-data : the ucd and coordSystem. We
have restricted these to no more than one instance allowed -->
<xsd:element ref="unit:UnitsGroup" minOccurs="0"/>
<xsd:element ref="q:ScalarDataTypeGroup" minOccurs="0"/>
<xsd:element ref="ucd:UCDGroup" minOccurs="0"/>
<xsd:choice minOccurs="0">
<xsd:element ref="stc:CoordSystemType"/>
<xsd:element ref="stc:CoordSystemRef"/>
</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>
__________________________________________________________________________________
Now more about this merging attempt.
Using this CharQuantity type allowed us to unify all our types in a nice way
and to integrate YOUR definition of the STC elements in the same way.
But although accepting this is the only way we found to build everything in Charac-
terization as Quantities it requires a good agreement between STC and Quantity to be
accepted. The main issues I see are the following:
a ) Are the ucd, unit, dataType, name of an STC element defined like in
Quantity: that would be nice to have this unified eventually.
b )The error, sampling and Resolution quantities have to exist independantly.
Because these are quantities which characterize the Observation as a whole. This
doesn't prevent us to put an error on each of the Stc quantities we are using.
To achieve the char/q also had to integrate Strings and even anyURI
as specialized Quantity types which be seen as strange by some people.
Last but not least we really would like to be able to use the same (ucd, unit,
dataType, name, and maybe CoordSys) subset at all the different levels of
characterization without redifining it totally. You dislike the use of "Quantity frame"
which was usefull for that because you do not want "Quantities without a value". OK.
WE discarded the use of this "Frames" (used in Septembre 2004 and March 2005 versions,
with a fid/ref mechanism in the latter case) but how can we put these features in common,
now? By redefining "frame" locally? And refering to these locally defined structures?
__________________________________________________________________________________
In the discussion in Kyoto, some people wandered if it was a good idea to make
characterization rely too heavily on a Quantity data model which is not achieved.
The idea is that we can rely if we can identify a rather stable interface.
Regards
François
<From brian.thomas at gsfc.nasa.gov Wed May 18 18:30:29 2005
<From: Brian Thomas <brian.thomas at gsfc.nasa.gov>
<To: Francois Bonnarel <bonnarel at newb6.u-strasbg.fr>
<Subject: Using Quantity in Char model (Was: Re: Characterization data model
<Date: Wed, 18 May 2005 12:43:26 -0400
<User-Agent: KMail/1.7.1
<Cc: dm at ivoa.net
<MIME-Version: 1.0
<Content-Transfer-Encoding: 8bit
<Content-Disposition: inline
<X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (mailhost.u-strasbg.fr [130.79.200.158]); Wed, 18 May 2005 18:40:56 +0200 (CEST)
<X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (mailhost.u-strasbg.fr [130.79.200.158]); Wed, 18 May 2005 18:40:55 +0200 (CEST)
<X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-1.6 (mailhost.u-strasbg.fr [130.79.200.154]); Wed, 18 May 2005 18:40:50 +0200 (CEST)
<X-Antivirus: scanned by sophos at u-strasbg.fr
<X-Antivirus: scanned by sophos at u-strasbg.fr
<X-Antivirus: scanned by sophos at u-strasbg.fr
<X-MailScanner-Astro: Message analyse non infecte par sophos sur astro.u-strasbg.fr
<X-Spam-Status: No, hits=-6.9 required=5.0
< tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,HTML_10_20,IN_REP_TO,
< QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES,
< SIGNATURE_LONG_DENSE,USER_AGENT_KMAIL
< version=2.55
<X-Spam-Level:
<X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
<
<
< 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.
<
=====================================================================
Francois Bonnarel Observatoire Astronomique de Strasbourg
CDS (Centre de donnees 11, rue de l'Universite
astronomiques de Strasbourg) F--67000 Strasbourg (France)
Tel: +33-(0)3 90 24 24 11 WWW: http://cdsweb.u-strasbg.fr/people/fb.html
Fax: +33-(0)3 90 24 24 25 E-mail: bonnarel at astro.u-strasbg.fr
---------------------------------------------------------------------
More information about the dm
mailing list