The LIM introduced a new object called "Component Relationship". 

However, there is no supporting definition for this object! Jenny Linnerud has done a great job trying to track it down, but we can't find the information. 

The only relevant text to be found says: "One new object – Component Relationship -was added to LIM in the Data and Structural Metadata package. This reflects that there could be a structure within the Logical Record, for example several fields can together represent a structured field (e.g. an address), or the record can be structured as in the case of an XML file conformant to a schema. "

Eva Holm thought it might have been related to the record linking use case, but the documentation does not refer to it.

David Barraclough says "I’m wondering if the ComponentRelationship is mostly for the AttributeComponent.  AttributeComponent has an AssignmentStatus and AssignmentLevel, but I cannot see how it is stated which “group” the attribute is attached to. In SDMX, an attribute must be associated with either the dataset, series, observation, or a “group” level. The group is a key which has less components than the full series key. An example would be attaching a “Unit of Measure” attribute to a list of indicators. Another example is what the ECB calls a “sibling” group which is the full time-series without the frequency dimension. Several such groups can be defined in a Data Structure Definition, therefore is the ComponentRelationship there to optionally specify which group an attribute is associated with?

 

So what is the component relationship? Should we include it in the revised model?

 

  • No labels

5 Comments

  1. Alistair Hamilton

    We use this a lot at ABS in our more detailed implementation but that doesn't necessarily mean it belongs in GSIM. 

    We'd handle something like multiple "components" in an address a different way (grouping at the RV level and relating to a Question Block if relevant) but some other agency might choose to implement it as a component relationship?  We mainly use the component relationship for cases like - We have Measure A and Measure B.  Here is the RSE for Measure A, here is the RSE for Measure B, Here is the data quality code for Measure A, here is the data quality code for Measure B etc.  This could be covered through use of Attribute Components associated with specific Measure Component but you'd still need to know what Attribute relates to which Measure.

    The exact implementation of such relationships probably depends on how the implementer wishes to do things so I could understand it not being in GSIM.  It is probably useful in practice but pragmatic rather than conceptual in modelling?

  2. InKyung Choi

    Meeting 27 June, 2018

    • As Eva Holm said, it could be related to the record linkage, but not sure if Component Relationship is the right object to add. Given that more and more organisations are doing record linkage and data integration, however, we would need to talk about this, at structure level, variable level, conceptual level, etc.
    • Need more input from countries how they do this in their organisations. Alice Born, Alistair Hamilton, Essi Kaukonen, Mikko Saloila Rebecca Stoks - can you share your experience?

  3. Alistair Hamilton

    For ABS primary "actionable" relationships are at the Data Structure Component. 

    We aim to reuse Represented Variables (RVs) as widely across the ABS as we can.  For example, "Sex of Person (1,2)" is very widely, although many other RVs are much more "localised". 

    We can recognise a lot of relationships between RVs but particularly where one of the RVs is designed for wide reuse, the fact one RV has a conceptual relationship with another RV is moot if one or other of the RVs is absent from our current structure, or from the specific structure to which we are trying to link.

    If two RVs that do have some conceptual relationship are both present in our structure we might (by default) "inherit down" that relationship RVs to become a relationship between structure components.

    There are also, however, are relationships we want to define between structure components that may not be reflected at the RV level, eg

    • assume Sex of Person and Gender of Person are close enough for current linking purposes without declaring them equivalent universally
    • specify that "Family ID" (identifying family records) and "ID of Family to which Person Belongs" will match in a particular "curated" structure but not if we match a set of person records with a set of family records from two different studies

    As per my previous comment, however, whether GSIM should go to this level of detail is a separate question.    

  4. Guillaume Duffes

    I agree with the first Alistair's comment: this is up to the implementers and pragmatic above all. Then it doesn't belong in GSIM. The strong and high-level cases for a conceptual relationship between two information objects are almost already there (e.g the relationship an RepresentedVariable and a Variable), I think that going deeper than that would make us go beyond the scope of the conceptual model.

  5. user-8e470

    OK - I think given we can not trace why this was added, and given the views of Alistair and Guillaume, I am concluding that this should not be added to GSIM as part of this review.