I know there might have been some discussion on this in the past, but in stead of browsing through all my mails, a quick question:
No that a category option only can exist within one category why do we need the unique name constraint on catoptions?
Within one category we should have unique names for its option, but why across categories?
This constraint is making it more difficult to come up with good and consistent names for category options, e.g I have two categories
VCCT_age and PMTCT_age and they share some of the age groups, and now I need to name age differently (e.g. ‘15-49 y’ and ‘15-49 years’) in the two, which is stupid I think.
I agree. I raised the same point with Lars last week and we concluded we could probably drop that uniqueness constraint. Lars, can you think of anything which breaks as a result of doing it?
I know there might have been some discussion on this in the past, but in stead of browsing through all my mails, a quick question:
No that a category option only can exist within one category why do we need the unique name constraint on catoptions?
Within one category we should have unique names for its option, but why across categories?
This constraint is making it more difficult to come up with good and consistent names for category options, e.g I have two categories
VCCT_age and PMTCT_age and they share some of the age groups, and now I need to name age differently (e.g. ‘15-49 y’ and ‘15-49 years’) in the two, which is stupid I think.
This is exactly what I have been arguing for. Category option is more than a label - for me it is a unit of analysis and we need to reuse it !
It is a mistake to constrain our unit of analysis with only one category. In Ola’s case, even more stupid we are going to have “15-49 Years” twice and no guarantee we might even end up with 100’s of the same “label” or same unit of analysis.
···
On Fri, Dec 11, 2009 at 3:36 PM, Ola Hodne Titlestad olatitle@gmail.com wrote:
Hi,
I know there might have been some discussion on this in the past, but in stead of browsing through all my mails, a quick question:
No that a category option only can exist within one category why do we need the unique name constraint on catoptions?
Within one category we should have unique names for its option, but why across categories?
This constraint is making it more difficult to come up with good and consistent names for category options, e.g I have two categories
VCCT_age and PMTCT_age and they share some of the age groups, and now I need to name age differently (e.g. ‘15-49 y’ and ‘15-49 years’) in the two, which is stupid I think.
Yes Abyot! I found myself backtracking a bit in your direction in my mail of 9 Nov, reporting back from sdmx connectathon:
"2. There was an interesting revelation for me (somehow I had not understood it completely before) around the way SDMX
HD deals with the issue of selecting valid dimensionOptions for a dimension. It bears some resemblance to both what Abyot had originally implemented (categoryoptions for a particular category selected from a super set of all available categoryoptions) and the subsequent refinements discussed on the Zooks mail thread. What is proposed in SDMX HD is that dimensionOptions should implement a concept. For each concept
there is a list of all possible code values. Particular dimensions would implement a subset of dimensionOptions selected from that list. For example:
codelist representing the AGE concept:
{<1, >1, 0 to 5, 0 to 16, >16, <40, … } etc
A particular dimension, eg STI_AGE_GROUP might then contain the subset:
{0-16, >16}
This is an interesting twist on what we do and does seem to have some merit. It addresses Abyot’s concern that we might want to reuse category options as well as my concern that we shouldn’t mix apples with oranges. I think we are all a bit fatigued looking at datamodel refinements (I’m sure particulalrly Lars!) but this is something we might want to consider. So far as supporting SDMX HD we will at a minimum probably have to implement a concept
field to the categor/categoryoption (and Group/GroupSet) objects. The constraint to apply would be that categories of a particular concept should contain categoryoptions of the same concept. "
This hybrid approach seems to capture the best aspects of both ways of looking at category options. Obviously people were a bit fatigued because this didn’t elicit any response For the moment I am hoping that we can get away with just relaxing the uniqueness constraint.
This is exactly what I have been arguing for. Category option is more than a label - for me it is a unit of analysis and we need to reuse it !
It is a mistake to constrain our unit of analysis with only one category. In Ola’s case, even more stupid we are going to have “15-49 Years” twice and no guarantee we might even end up with 100’s of the same “label” or same unit of analysis.
On Fri, Dec 11, 2009 at 3:36 PM, Ola Hodne Titlestad olatitle@gmail.com wrote:
Hi,
I know there might have been some discussion on this in the past, but in stead of browsing through all my mails, a quick question:
No that a category option only can exist within one category why do we need the unique name constraint on catoptions?
Within one category we should have unique names for its option, but why across categories?
This constraint is making it more difficult to come up with good and consistent names for category options, e.g I have two categories
VCCT_age and PMTCT_age and they share some of the age groups, and now I need to name age differently (e.g. ‘15-49 y’ and ‘15-49 years’) in the two, which is stupid I think.
yes I also would like to remove the uniqueness constraint on category option name. The reason why we kept it is backwards compatibility for DXF. Category options appear in a single list and if the name wasn’t unique there would be no way to map them to other objects. Category options will be nested within categories in DXF 2 but until that is in place we will have to keep it (or come up with a clever solution for it).
For the moment I am hoping that we can get away with just relaxing the uniqueness constraint.