Merger of Char, STC and Quantity (Was: Re: Using Quantity in Char model (Was: Re: Characterization data model

[Brian Thomas]

	Hi all,

	In a recent email Francois mentioned a document I wrote with Ed about how
	some consolidation between data models (primarily char, stc, quantity and a 
	catalog model) may be made.

	I'm not sure this made it to the list, but certainly a few members have already
	had a look at a 'pre-draft'. Here's the link for those interested who wish to follow
	or participate in the email thread:

	http://archive.astro.umd.edu/VOCatalog/docs/VOmodel_merger.pdf 

	and now on to respond to some points that Francois recently made concerning
	this effort:
	

On Monday 23 May 2005 11:03 am, Francois Bonnarel wrote:
> 
>    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.

	YES, definitely. I put forward a draft of the stc to do this, it is not hard at all.

>       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.  
>

	YES (again!). Although I see that the existing character schema may/may not 
	reflect this point of view (I see that you have 'accuracy' in your characterization 
	schema. I would have that put in a separate namespace/schema of its own)

>      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. 

	Yes, this could be. Gathering some examples would be a good exercise to 
	discover the proper way to extend the Q data model to handle these.
 
>       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? 

	I guess Im still waiting on the prior email to understand why you would need
	to have a special class to aggregate "ucd, unit, dataType, name, and CoordSys".
	
	This type of information only makes sense (to me) in Quantities which have values
	(e.g. "AtomicQuantity, ListQuantity, and MatrixQuantity").

	So, Quantities which aggregate nothing but other Quantities (e.g. CompositeQuantity)
	should'nt have a 'datatype' or a 'unit'; the *child* quantities of a CompositeQuantity,
	if they have values, have this information.

	To give a real-life type of CompositeQuantity: "a measurement" which I define here
	(for the sake of this argument) as a value and its (Gaussian) error. This looks like (in
	XML):

	<measurementQuantity>
		<atomicQuantity>
			<units>erg cm^-1 sec^-2</units>
			<float width="5" precision="2"/>
			<value>10.34</value>
		</atomicQuantity>
		<atomicAccuracy type="GaussianError">
			<units>erg cm^-1 sec^-2</units>
			<float width="5" precision="2"/>
			<value>10.34</value>
		</atomicAccuracy>
	</measurementQuantity>

	where the measurementQuantity is a restriction on the more general compositeQuantity
	class, requiring that only 2 child quantities appear, one each for the 'value' of the measurement,
	and one for the 'error'.

	If one where to put a 'units' or 'datatype' in the measurementQuantity, it would not make
	sense (unless you are trying to say that all children obey the same units/datatype...but I
	don't like that either, although I'll not explain just now why).

> 
> __________________________________________________________________________________
> 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.

	Ugh. There is quite a bit of documentation (IVOA draft) and even software available
	now for the Quantity. This is more than for many other data models in the VO.
	What is it exactly which people are saying is "not achieved"?

	But speaking of this topic, I'd like to propose that the DM group get back to finishing
	the work on the Quantity IVOA note draft. I talked in April about this with Jonathan,
	and he gave the OK to proceed. 

	Are there any interested editors out there? Please contact me. I plan to turn around
	a new draft within the June time-frame.

	As always, Best Regards,

	=brian



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