sdmx:ConceptRoles

[Sarven Capadisli]

Hi all,

I was taking a closer look at sdmx:ConceptRoles, and ran into a few
question marks that I'm hoping you can help me with. First, I'd like to
know whether the following roles in sdmx-concept.ttl were derived from
SDMX-IM (or elsewhere), or if they were manually added:

sdmx-concept:freq a sdmx:FrequencyRole .
sdmx-concept:obsValue sdmx:PrimaryMeasureRole .
sdmx-concept:refPeriod a sdmx:TimeRole .
sdmx-concept:timePeriod a sdmx:TimeRole .

Following this, why aren't the rest of the concepts in sdmx-concept
typed with a corresponding or suitable role?

My last question is due to the confusion that I have with the identity
role in SDMX; is the identity role (@isIdentityDimension from SDMX
Structure / SDMX-ML) meant to cover what is commonly known as the
indicators of an observation e.g., refArea, loan type, vehicle model?
That is, of course excluding frequency, and time concepts.

In the current implementation of Linked SDMX [1], sdmx:ConceptRole is
used as a fall-back when the type of dimension is not specified in the
SDMX-ML KeyFamily. However, I'm trying to see whether an improvement can
be made by assigning something more specific i.e., sdmx:IdentityRole, if
I'm understanding this correctly.

Thanks,

[1] https://github.com/csarven/linked-sdmx

-Sarven
http://csarven.ca/#i

[A. Gregory]

Sarven:

Just working from memory here...

Some of these concept roles (most) were in the original SDMX specifications:

- Frequency (for historical reasons, because SDMX was inspired by an earlier
standard called GESMES-TS) is a priviledged concept, which is hard-coded
into the SDMX specifications. (Really, it should be an attribute in my
opinion, but it is a privileged kind of dimension).

- Primary Measure is in the SDMX specification as well, because of the need
(in a hierarchical XML syntax binding) to distinguish between the "primary
measure" and "secondary (that is, cross-sectional) measures. SDMX was very
much oriented to time-series data when first written.

- refPeriod is the "Time" concept in SDMX, and is also given a privileged
status as a dimension.

- TimePeriod is not from the SDMX per se - from a strict SDMX perspective,
it is just a concept role which is typed as being a period. There is nothing
in the SDMX spec which gives this any kind of special recognition - it is
just one representation concepts can have, in whatever role they perform.

I hope this helps!

Cheers,

Arofan

[Dave Reynolds]

Hi Sarven,

On 19/04/13 00:20, Sarven Capadisli wrote:
> Hi all,
>
> I was taking a closer look at sdmx:ConceptRoles, and ran into a few
> question marks that I'm hoping you can help me with. First, I'd like to
> know whether the following roles in sdmx-concept.ttl were derived from
> SDMX-IM (or elsewhere), or if they were manually added:
>
> sdmx-concept:freq a sdmx:FrequencyRole .
> sdmx-concept:obsValue sdmx:PrimaryMeasureRole .
> sdmx-concept:refPeriod a sdmx:TimeRole .
> sdmx-concept:timePeriod a sdmx:TimeRole .

As Arofan clarified (thanks Arofan) SDMX does have these notions of
special roles such a "Frequency". Glad to hear more of the history,
always seemed to me to be rather time-series-centric.

When we started out doing SDMX-in-RDF we therefore felt we needed to
reflect this, hence the sdmx:ConceptRoles machinery.

The specific roles that those concepts play isn't explicitly stated in
the XML for the SDMX Concepts but those instances are clear from the
specification itself so we manually added them in defining sdmx-concept.ttl.

However, caution here. When we collectively figured out out that just
the Data Cube subset would handle pretty much everything we needed then
all the attention switched to that. There's currently no activity I'm
aware of, certainly no funding, to go back to the parts of SDMX that
aren't in Data Cube and finish them off or standardise them somehow.

So we won't remove those statements from sdmx-concept.ttl but the whole
design of sdmx:ConceptRoles and what the right roles are has not been
subject to anything like the same level of review as Data Cube has.

> Following this, why aren't the rest of the concepts in sdmx-concept
> typed with a corresponding or suitable role?

See above. It's not clear there are special roles for all these things.
We were just reflecting the few distinguished roles in the SDMX specs as
we understood them.

> My last question is due to the confusion that I have with the identity
> role in SDMX; is the identity role (@isIdentityDimension from SDMX
> Structure / SDMX-ML) meant to cover what is commonly known as the
> indicators of an observation e.g., refArea, loan type, vehicle model?
> That is, of course excluding frequency, and time concepts.

I don't understand the SDMX identity role model well enough to advise on
that. Sorry.

Dave

[A. Gregory]

Dave/Sarven:

identityRole is again an SDMX thing (sorry I missed this before). It was
originally designed because sometimes you have a dimension which is an
identifier (the original example in SDMX was an account identifier for
banking transactions). However, in SDMX we also have an "entityRole"
construct which is used when the identifier is an identifier of a legal
entity (such as a company or individual), which is also an identifier, but
has this privileged semantic.

In most SDMX implementations, however, such things as loan type and vehicle
model would be handled by dedicated classifications, and would not have an
identityRole, even though that might make sense (to follow your example, a
specific loan has an identity - the type of the loan does not. Ditto for
vehicle make - each vehicle has an identity - the make of the vehicle is not
its identity). I know this seems to be a matter of interpretation, but
that's how people imple,enting SDMX would look at it.

Cheers,

Arofan

-----Original Message-----
From: publishing-st...@googlegroups.com

--
You received this message because you are subscribed to the Google Groups
"Publishing Statistical Data" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to publishing-statisti...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Sarven Capadisli]

Hi Dave, Arofan,

Thank you for the background and filling in the gaps. More clear now.

It is the interpretation that I have trouble with :) For instance,
reference area is a very common concept used for a dimension, yet, I
can't assign a suitable role for it. As I've mentioned in my earlier
email, if there is no clear information from the SDMX-ML, I assign
sdmx:ConceptRole to the concept that a component is using; after
checking for is*=true or the type of component.

I've looked at several KeyFamilies from different organisations; the
roles that appear to be widely implemented are @isFrequencyDimension,
@isTimeFormat, and @isMeasureDimension. Hence, the dimensions like
reference area, or anything else for that matter are rather out in the
open, which lead me to simply assign sdmx:ConceptRole (better than
nothing, I thought).

I'm looking for a way to automate this process such that one wouldn't
need to manually assign roles by going through each concept that's used
for a dimension component i.e., I rather not have human involved (during
the transformation phase) to decide if loan id should have IdentityRole
but not loan type. Or to a vehicle, but not its make etc.

Arofan, from the way you describe the identity role, it is quite
difficult to automate (if at all possible) this as far as I can see. Of
course, I can have some built-in name checks but, that's rather hackish.

Any further direction on this would be super great! Until then, I guess
I'm stuck with ConceptRole.

Thanks again for your valuable inputs!

-Sarven