Assigning a value to an INSPIRE nilReason

Added by Helen Eriksson over 3 years ago

Hi,
When we are mapping data to INSPIRE schemas, the wrong code list values is shown when we want to assign a value to a nilReason even though the VoidReasonValue code list has been imported. Values from the GML nil value list (inapplicable, missing, template, unknown, withheld) is shown instead of the VoidReasonValue code list from INSPIRE (unpopulated, unknown, withheld).
Can this be changed? Getting other values than expected is a bit confusing and the value “unpopulated” is also missing in the list.

Kind regards,
Helen Eriksson


Replies (7)

RE: Assigning a value to an INSPIRE nilReason - Added by Simon Templer over 3 years ago

Hi Helen,

I can understand your confusion with that. The reason that these values are offered is that the INSPIRE schemas make use of the NilReasonType defined in GML which proposes the values you mentioned, but allows any other values as well. HALE just uses the information from the schema - in an ideal case the INSPIRE schemas would specify what values actually should be used and HALE would support that automatically.
As that is not the case (and the schemas will probably not be adapted in that way), I suppose we could try to detect nilReason attributes in INSPIRE properties and override the attribute type to fake this. We will discuss internally if it makes sense to include this kind of INSPIRE specific "hack".

Thanks for sharing your idea, I think this could be very convenient for users when mapping to INSPIRE schemas.

Best regards,
Simon

RE: Assigning a value to an INSPIRE nilReason - Added by Helen Eriksson over 3 years ago

Hi Simon,
Thanks a lot for your quick reply.
INSPIRE has a code list for void reasons, VoidReasonValue, but is using that on an already defined data type, NilReasonType, that has its own code list. That I guess is what is causing the problem. What would be convenient is that if you actively choose the code list VoidReasonValue for a nilReason these values will be shown instead of the ones from the GML nil value list. As it is today the GML-values are shown even if you try to choose another list.
Kind regards,
Helen

RE: Assigning a value to an INSPIRE nilReason - Added by Simon Templer over 3 years ago

Hi Helen,

I see, so in that case the code list assignment and the schema defined enumeration concur and the enumeration takes precedence. At least for enumerations that allow other values we could probably switch to the code list instead, for fixed enumerations the option to assign a code list should be disabled.

In case of the nilReason using the code list from the registry would not help. At least how I understand how the values for nilReason should be represented (as the values unknown, unpopulated, and withheld). This is the only way I've seen so far (e.g. in presentations by the JRC) and what I find also as example in the latest version of the 'INSPIRE Generic Conceptual Model' (D2.5 v3.4) document.
The code lists in the INSPIRE registry have URIs as values, so if assigning a value from the code list, it would for instance be http://inspire.ec.europa.eu/codelist/VoidReasonValue/Unknown instead of simply unknown. The URIs are definitely to be used at other places in the INSPIRE models, but about the nilReason I am not sure. So far I am not aware that this changed to using URIs as well.

What is your state of knowledge? How should the nilReason be represented?

Best regards,
Simon

RE: Assigning a value to an INSPIRE nilReason - Added by Helen Eriksson over 3 years ago

Hi Simon,
Yes, for code lists that allow other values it would be convenient to be able to switch to another code list.

As for your question about about how the values should be represented, I have also only seen examples of e.g. "unknown" and not the whole URI, but I do not know for certain how it should be represented.

Kind regards,
Helen

RE: Assigning a value to an INSPIRE nilReason - Added by Simon Templer over 3 years ago

Hi Helen,

what we did now is that for nilReason attributes that we detect as "INSPIRE nilReasons" we offer the values unknown, unpopulated and withheld (assuming those are the right ones to use). I think for the user this is the most convenient option.

Additionally, if there is a property with an enumeration that allows other values than those included in the enumeration, you can now assign a code list and choose from the code list values as well.

Best regards,
Simon

RE: Assigning a value to an INSPIRE nilReason - Added by Helen Eriksson over 3 years ago

Hi Simon,
Thank you for coming up with a solution so quickly! This will make it much more understandable for users mapping to INSPIRE schemas.

By the way, I saw in a revision note that "resource bundles" had been updated with the INSPIRE 4.0 schemas, does this meen that it will be possible to choose them from preset when importing a Target schema in the next version of Hale?

Kind regards,
Helen

RE: Assigning a value to an INSPIRE nilReason - Added by Simon Templer over 3 years ago

Hi Helen,

Thank you for coming up with a solution so quickly! This will make it much more understandable for users mapping to INSPIRE schemas.

Thanks to you for providing feedback - it is very important to us that users tell us about their experiences and problems.

By the way, I saw in a revision note that "resource bundles" had been updated with the INSPIRE 4.0 schemas, does this meen that it will be possible to choose them from preset when importing a Target schema in the next version of Hale?

Exactly. The resource bundles include the presets as well as copies of the schemas to speed up loading and allowing to use them offline.

If you are interested, you can test the current development version that has both these things already included:
http://hale.igd.fraunhofer.de/jenkins/view/HALE/job/hale-master-production-stage/

Best regards,
Simon

(1-7/7)