search

Letractively / publishing-statistical-data

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

Consider property hierarchies in places of concept link for classification of ComponentProperty? #39

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
The RDF properties that carry dimension/attribute/etc values combine a concept 
(denoted by the sdmx:concept link), a type and role (denoted by rdf:type 
statements on the property) and a value representation (denoted by the 
rdfs:range of the property).

At ODaF 2010 Arofan commented on the fact that SDMX-RDF chose to use the 
sdmx:concept link rather than RDF native machinery for this. 

While we are in the process of factoring out a core Data Cube vocabulary do we 
want to reconsider this?

The alternative would be to represent the COG concepts directly as abstract 
ComponentProperties and use rdfs:subPropertyOf to indicate specializations of 
those concepts to particular roles or ranges.

Reasons to not change:
   * clearer compatibility with SDMX model
   * we already have material that assumes this approach
   * can use SKOS machinery for representing concept lists, including scope notes, related terms etc.

Reasons to change:
   * simpler vocabulary from an RDF viewpoint
   * slightly better support from existing tools (since property hierarchies are a core part of existing RDFS usage)

I'm sticking to the current approach for the draft a the moment but wanted to 
flag the issue so we definitely close it down one way or the other now while 
things are being reshuffled.

Original issue reported on code.google.com by Dave.e.R...@gmail.com on 13 Jul 2010 at 10:42

GoogleCodeExporter commented 8 years ago 
We discussed this and felt that the separate concept approach has enough 
advantages to retain it. 

From the point of view of an SDMX user this is the natural approach. In many 
cases we do see an argument for publishing and documenting concepts such as the 
indicators being measured, separate from their use to quality a property in a 
dataset. From an RDF point of view then it should still be possible to mint 
ComponentProperties and not mandate that there *always* be a separate 
associated skos:Concept.

The documentation around the use of qb:concept will need to give clear guidance.

Original comment by Dave.e.R...@gmail.com on 23 Jul 2010 at 10:38