ValueType as disaggregation or attribute WAS: Re: Handover
Ola Hodne Titlestad
Hi guys,
Must say it is not that easy to follow your discussions, especially when you jump on and off the list.
Regarding the ValueType issue I must say I agree with the suggestion to remove it from disaggregation and rather use an optional attribute to distinguish between targets and values. The point of disaggregation hierarchies is to easily model how we can aggregate the data right, and as it makes no sense to add together target values and reported values this seems like a very strange approach. I also heard from the implementation of SDMX-HD in Sierra Leone that the ValueType was causing problems as it breaks with the logic of disaggregation.
I understand that your working towards a deadline for v1 here, but doesn't make sense to keep things that are wrong either. So unless this is a major effort I would suggest we make the change.
Ola Hodne Titlestad |Technical Officer|
Health Metrics Network (HMN) | World Health Organization
Avenue Appia 20 |1211 Geneva 27, Switzerland | Email: title...@who.int|Tel: +41 788216897
Website: www.healthmetricsnetwork.org
Better Information. Better Decisions. Better Health.
On 8 March 2010 15:25, Gary Patchen <gary.p...@b-i.com> wrote:
Hi Bob,
Whilst I understand you point about ValueType in the hierarchy I feel we should list this as item 1 in the feedback for SDMX-HD as otherwise we risk
delaying the release of the normative document even more.
Regards
gary patchen
From: Bob Jolliffe [mailto:bobjo...@gmail.com]
Sent: lundi 8 mars 2010 14:55
Hi Gary
On 8 March 2010 13:17, Gary Patchen <gary.p...@b-i.com> wrote:
Hi Bob,
Yes % Indicators can have targets, but the hierarchy of disaggregations implies that ValueType.Value = Sum(Gender.Male, Gender.Female) this is what I call : “Rollup”.
Percentages in CRIS / PEPFAR can’t be summed directly as you can’t really sum percentages to make the ValueType=>Value or VaueType.Target.
Sorry I don't really understand. Of course I do understand that % can't be "rolled up". And also that most indicators are in fact % or ratio. Though I'm just not sure what this has to do with value_type.
“I also understood that there is always a disaggregation specified in the the disagg hierarchy - unless it is "partially configured" with cl_disagg.”
PEPFAR have financial indicator that only have value and never target. They implement these Indicators as have no disaggregation what so ever.
All of the indicators (in fact dataelements ) we deal with generally only have value not target. I have only implemented value_type because that is what sdmx-hd was requiring. I don't really like the idea at all :-) But value_type is not a disaggregation - you can't meaningfully rollup and sum the target and the value. So the pepfar indicators, like the ones we have dealt with should have value_type either "value" or "_NA" - whichever they prefer. It isn't material whether the indicators are % or not or whether they have disaggegation nodes beneath them.
Effectively, these financial indicators have a implied root disaggregation of ValueType=>Value. It is just simply not implement that way in PEPFAR.
I would have preferred that value type as always the first disaggregation to keep the rule simple but I guess “If there is a disaggregation specified then the first one must be ValueType.“
As I said - its not a disaggregation.
is not such a complicated rule.
Given the above, explain again why we need this VALUE_TYPE node at all. After all, what is required in a dataset is to indicate whether the data values are target values or reported values. So it seems that all we need is an (optional) VALUE_TYPE attribute on the observation. So Pepfar can simply leave it out if they don't need it in a particular keyfamily. You are making our lives very complicated by putting it in a disaggregation hierarchy and then making exceptions about when to use it or not use it.
Why not just drop it in favour of an attribute?
Regards
Bob
Gary Patchen
Hi All,
We have a period of review for the first document (probably starting sometime next week) for a limited period.
During this review we will no doubt have issues and questions raise like this one and may need to make adjustments to SDMX-HD to created the final v1.0 based on this feedback.
As the ValueType question is complex and I have some case which may not work by adding an attribute, I suggested adding this as the first item to review once the SDMX-HD normative document “draft” is published.
The issue will not be forgotten, I just worry that addressing this issue now will delay the normative document even more.
regards
gary patchen
lead consultant
direct + 41.(0)58.307.7094
mobile +41.(0)79.333.1339
gary.p...@b-i.com
www.b-i.com
blue-infinity headquarters
t +41(0)58.307.7000
f +41(0)58.307.7001
INTERNATIONAL
t +800.307.70.000
f +800.307.70.001
b-i branding.technology.integration.
The information in this e-mail, and those ensuing, is confidential
and may be legally privileged. It is intended solely for the addressee. If you
are not the intended recipient, please destroy this message and notify us
immediately.
Please think of the environment before printing this email
--
You received this message because you are subscribed to the Google Groups
"SDMX-HD (Health Domain)" group.
To post to this group, send email to sdm...@googlegroups.com.
To unsubscribe from this group, send email to
sdmx_hd+u...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sdmx_hd?hl=en.
Bob Jolliffe
On 9 March 2010 09:06, Gary Patchen <gary.p...@b-i.com> wrote:
> Hi All,
>
>
>
> We have a period of review for the first document (probably starting
> sometime next week) for a limited period.
>
>
>
> During this review we will no doubt have issues and questions raise like
> this one and may need to make adjustments to SDMX-HD to created the final
> v1.0 based on this feedback.
>
> As the ValueType question is complex and I have some case which may not work
> by adding an attribute, I suggested adding this as the first item to review
> once the SDMX-HD normative document “draft” is published.
>
>
> The issue will not be forgotten, I just worry that addressing this issue now
> will delay the normative document even more.
I think the point is that we went along with your idea of having a
value_type dimension in the hierarchy and I have written the
specification as such, even though, as I have pointed out before, I
have serious misgivings about it. It is you who have suggested that
we now need to change the specification as it seems that you now have
cases with CRIS/PEPFAR indicators where this doesn't work. My point
is that is fairly obvious why it should not work - it was a strange
stretch of the imagination to consider value_type as a disaggregation
dimension in the first place.
So I am suggesting that we use good sense here, treat it as an
attribute, and if need be make it an item for review if you like. I
would be curious to know what is the use case which requires that
target value vs observed value should be treated as a dimension for
disaggregation? I can see that you would have a situation where you
want to compare observed values with target values, but to do that you
simply need an attribute on the datavalue. .
Regards
Bob
Gary Patchen
I am not against making valueType an attribute if that is the best approach that caters for all scenarios.
I am merely concerned about the timing and whether the attribute solves all scenario.
For example if I have a particially configured hierarchy for ValueType=>Value and ValueType=>Target that are NOT the same!
regards
gary patchen
lead consultant
blue-infinity headquarters
t +41(0)58.307.7000
f +41(0)58.307.7001
INTERNATIONAL
t +800.307.70.000
f +800.307.70.001
b-i branding.technology.integration.
The information in this e-mail, and those ensuing, is confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, please destroy this message and notify us immediately.
Please think of the environment before printing this email
Bob Jolliffe
> I am merely concerned about the timing and whether the attribute solves all scenario.
>
> For example if I have a particially configured hierarchy for ValueType=>Value and ValueType=>Target that are NOT the same!
Yes I can imagine that possibility. Does this only happen with
partially configured hierarchies? Do you foresee a dataset with
target values and a dataset with observed values using different
disaggregations?
I am concerned we are treating it as a disaggregation dimension in
order to satisfy this configuration requirement but that it does
eventually (the purpose of configuration) end up becoming a dimension
of data which doesn't necessarily make any sense.
In order to get on - there's a lot to get on with - I suggest
(i) we leave it in the hierarchy as it is so you can have your
dissimilar disaggregation hierarchies
(ii) applications that don't use it for configuration can simply set
it to _NA in the hierarchy
(ii) when specifying the dataset I will indicate that value_type is an
attribute. The fact that it appears in the disagg hierarchy shouldn't
necessarily require it to be a dimension. After all we also have
'indicator set' in there presumably for the same reason - you have the
same indicator in different ISETs you want to configure differently.
That doesn't mean we make ISET a dimension of data.
Ryan
Sorry for being late to the party but I also wanted to say that the value_type "dimenion" has cause me problems with the Sierra Leone implementation. Infact we opted to no use it at all for simplicity. I think it should rather be an attribute if possible as it makes mapping of external dimension to SDMX-HD dimensions a challenge as "value_type" isn't really a dimension.
So in short +1 for making "value_type" an attribute if possible.
Regards,
Ryan
Software Developer
ry...@jembi.org
http://www.jembi.org
Moore, Steven
Steven MOORE -
Database Manager
Public Health Information and Geographic Information Systems
(GIS)
Health Statistics and Informatics (HSI)
Information, Evidence and
Research (IER)
World Health Organization
20, Avenue
Appia
1211 Geneva 27
Switzerland ( +41 22 791 5504
6 +41 22 791 1584
* moo...@who.int
For information on GIS: www.who.int/health_mapping/
From: sdm...@googlegroups.com [mailto:sdm...@googlegroups.com] On Behalf Of Ryan
Sent: Tuesday, March 09, 2010 3:26 PM
Bob Jolliffe
get to the SDMX conference in Geneva but its really useful to get a
report back on what people are thinking about/discussing.
On 9 March 2010 20:35, Moore, Steven <moo...@who.int> wrote:
> I have been an observer on the sidelines for most of this discussion. I
> just wanted to say that I have been paying attention to the e-mail exchanges
> and I am assured that the work around SDMX-HD is in very capable hands. I
> spent today at an SDMX conference in Geneva and it is clear that this work
> has wide-reaching implications. We talk about interoperability but that
> really means reducing the burden on countries and gaining the benefits of a
> development community that can do wonderful things if they know what to
> expect from the datasource. Dublin Core is a great example of this, and I
> saw a number of examples at today's presentations. Here is an example:
>
> http://code.google.com/p/flex-cb/ which you can see as an application
> here: http://code.google.com/p/flex-cb/wiki/WhereIsItUsed (check out the
> ECB inflation dashboard)
Nice.
>
> Please note this as well, which is DevInfo's SDMX site:
> http://www.devinfo.info/Registry/SDMX-MDG/DataStructures/CodeLists.aspx
I have remarked before that I really like what the MDG group has done.
Its simple, doesn't stretch the use of SDMX beyond its normal purpose
and I suspect will work very well. I think what we are trying to do
with SDMX-HD is much more ambitious in that we don't have a fixed set
of indicators to define. It seems unlikely we will get this right
first time - we must continue the battle to reduce complexity - but I
am sure with the right inputs from stakeholders and more experience of
use in the field we will improve it.
>
> I would very much like to see something similar for SDMX-HD, but include a
> web services piece. Web services are really the key to making SDMX-HD
> work. I developed a whole suite of web services for both data and code
> lists, but I am now convinced that I need to change those services to be
> SDMX-HD compliant, or at least do as Bob hinted - incorporate the SDMX
> concept and value in web services/dimension tables.
>
> One final comment...there were the beginnings of discussions about SDMX vs
> RDF today. I would invite you all to review the FAO's country web services
> at http://www.fao.org/countryprofiles/webservices.asp?lang=enand also look
> at the RDF/OWL implementation here:
> http://aims.fao.org/aos/geopolitical.owl It is not really related to SDMX,
> even though the FAO is heavily-invested already in SDMX as you can see here:
> http://tinyurl.com/faosdmxswf
I would have enjoyed being part of that discussion. Augmenting
sdmx-hd with something like RDF would be an elegant way to express
some of those things for which we are maybe stretching existing SDMX
paradigms. I'm not sure if its necessarily an rdf vs sdmx thing.
SDMX provides a framework for defining datasets. RDF might be a great
way of describing some of the rich relationships between the bits and
pieces - some of what we are currently struggling with hierarchical
codelists for example. I have given notice of the fact that, in my
view, the disaggregation hierarchy should have a limited future beyond
version 1.0. Given that FAO is invested in both, was there any
discussion of how they use one to augment the other or are these two
conceptual silos within the organisation?
Cheers
Bob