Letractively / publishing-statistical-data

Automatically exported from code.google.com/p/publishing-statistical-data
0 stars 0 forks source link

Are ComponentProperty instances re-usable across DSDs? #20

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Several aspects of a DSD are re-usable between many DSDs and thus could be 
standardised 
easily, especially sdmx:ConceptSchemes and sdmx:CodeLists.

However it is not clear wether the sdmx:ComponentProperties are to be always 
defined for use in 
a single DSD, or wether they can be re-used across multiple DSDs.

Either way, this should be clearly stated in the documentation.

Advantages of re-use: Reduces the cost of creating new DSDs; allows the 
definition of properties 
for the most commonly used concepts, such as sdmx:obsValue or perhaps sdmx:time 
and the 
other concepts in the COG.

Disadvantages: If this kind of re-use is not allowed, then it becomes easier to 
navigate between 
the dataset and data structure definition, because every ComponentProperty is 
attached to exactly 
one DSD. It also reduces the risk of confused users re-defining things in an 
illegal way, e.g., by 
re-defining an AttributeProperty from the COG as a DimensionProperty.

Finally, the ConceptScheme in SDMX seems to be designed exactly to allow re-use 
of semantics 
across DSDs, and it appears by re-using properties we are introducing a 
redundant, confusing 
and muddled alternative. If properties can be re-used, then why would concepts 
be needed at all?  
Taking this train of thoughts to its conclusion leads to Issue 19, which 
proposes to translate 
SDMX's concepts into re-usable rdf:Properties.

Original issue reported on code.google.com by richard....@gmail.com on 30 Mar 2010 at 2:13

GoogleCodeExporter commented 9 years ago
Proposal: Recommend that if you define concepts, consider making a re-usable 
property for each, like we did 
for the COGs. Otherwise, don't re-use ComponentProperties across DSDs. If one 
of the re-usable prop doesn't 
work for you, e.g., because you want to define a range, then define a new 
ComponentProperty and connect it to 
the concept. Do not make it a subproperty, because that would be redundant and 
it would lead to extra 
attrbiutes/dimensions on observations after reasoning.

Original comment by richard....@gmail.com on 22 Apr 2010 at 10:31

GoogleCodeExporter commented 9 years ago

Original comment by i.j.dick...@gmail.com on 7 May 2010 at 9:08

GoogleCodeExporter commented 9 years ago
We resolved this a while ago by allowing reuse of properties, marking the issue 
closed now we have documented this.

Original comment by Dave.e.R...@gmail.com on 16 Aug 2010 at 11:23