Relationship between Q and STC - Frames & Mapping

[Martin Hill]

Brian Thomas wrote:

> 	I think there is a strong need for some way to create Q's 
> 	that get their values from mappings (mappings are particularly nice for 
> 	compact description of large quantities like axes). But you don't want to
> 	just allow the user of the Q to change (or mix!) how the values are created
> 	in any given Q (it would be a nightmare to implement..). This is why I suggested the 
> 	constructor as a likely place (once made, how Q interoperates with its values
> 	is set).  

>       I'd also favor having a boolean method to determine the nature of how 
> 	the values are generated in a Q also. This is nice because you can't (shouldn't) do 
> 	"q.setValue(Obj, Location);" method call on a Q that has a mapping
> 	behind it. The method thus allows the user to pre-determine whether its
> 	OK to make the setValue call rather than having to always catch an error.

I don't think this is a sufficient check; if values shouldn't be set 
then we shouldn't have a method to do so...  If we can map values out 
can we normally expect to reverse them back in?  But then I'm not in 
favour of changing values anyway!

> 
> 	It's also important to reinforce that the current mapping prescription is
> 	for *values* (V-mappings if you will). 

I understand (now) this is the intention but not why.  If you have a set 
of values in a frame then the values should be in that Frame; if the 
values need to be mapped to something in order to appear in that frame 
then that should be done when the Quantity is created. If the values 
have some use in their 'raw' form, ie presumably in some other Frame, 
then they should be presented with that other Frame. I'm just going to 
read Dave's examples though...


>       There are *no* mappings for 
> 	generation of Q's (this is a point that took me some time to grok). There may 
> 	be a need for mapping Q's into other Q's (I think so, particularly for use in 
> 	tandem with UCD3/ontologies)  but currently that isn't the case, and there 
> 	are no plans at this time to make Q-mapping interface/serialization.
>  


-- 
Martin Hill
www.mchill.net
07901 55 24 66