Component properties differ between DSDs and data files

[cygri]

Comparing data http://eurostat.linked-statistics.org/data/med_en22.rdf

and corresponding DSD http://eurostat.linked-statistics.org/dsd/med_en22.ttl

there are a number of problems. The DSD lists the following components:

  qb:component
          [ qb:dimension property:nace_r2
          ] ;
  qb:component
          [ qb:measure property:OBS_VALUE
          ] ;
  qb:component
          [ qb:dimension property:geo
          ] ;
  qb:component
          [ qb:attribute property:OBS_STATUS
          ] ;
  qb:component
          [ qb:dimension property:FREQ
          ] ;
  qb:component
          [ qb:attribute property:TIME_FORMAT
          ] ;
  qb:component
          [ qb:dimension property:unit
          ] ;
  qb:component
          [ qb:dimension property:TIME_PERIOD
          ] ;

But a typical observation actually has the following properties:

<freq rdf:resource="/dic/freq#A"/>
<unit rdf:resource="/dic/unit#1000T"/>
<nace_r2 rdf:resource="/dic/nace_r2#B"/>
<geo rdf:resource="/dic/geo#DZ"/>
<time rdf:resource="/dic/time#2003"/>
<sdmx-measure:obsValue rdf:datatype="/dic/note#s">280238</sdmx-measure:obsValue>

These two lists should be identical in every respect (including namespaces and capitalization).

Some comments:

• name_r2, geo, unit are ok
• FREQ != freq
• TIME_PERIOD != time
• OBS_VALUE: here, using sdmx-measure:obsValue is the right thing to do (recommended by the spec), so the DSD should reflect that.
• OBS_STATUS is treated as a datatype of the measure in the data, which is nonsense. It should be treated as an attribute.
• TIME_FORMAT is completely missing in the data. That's probably ok because the time format in RDF is already pre-defined (either by use of a code list or by use of a xsd:date/xsd:dateTime literal), so it should just be skipped in the DSD.
• Where possible, pre-defined properties from the SDMX COG's should be used (sdmx-dimension, sdmx-attribute, sdmx-measure). Especially for FREQ, OBS_VALUE, OBS_STATUS, TIME_PERIOD. However, some of these come with pre-defined code lists too, and they should be used only with that code list.
• (I think that for OBS_STATUS and FREQ, sdmx-attribute:obsStatus and sdmx-dimension:freq ought to be used with their respective pre-defined code lists. For OBS_VALUE, sdmx-measure:obsValue ought to be used. For TIME_PERIOD, sdmx-dimension:refPeriod should not be used because we use a custom code list.)