European Commission logo
INSPIRE Community Forum

OF Data Specification - Use of codelists

Dear colleagues,

We were discussing the use of code-lists within the OF Data Specification, specifically the BODC codelist. There are some observations and maybe inconsistencies which we would like to discuss.

1) The OF UML model uses generalization as association between the PhenomenonTypeValue on the one hand and the 2 codelists - BODC_P01ParameterUsageValue and CFStandardNamesValue - on the other hand.

  • The UML model isn't specific about that only these two lists can be applied. 
  • Both code-lists are characterized as not extensible

2) In the OF DS Technical Guidelines, the OF UML models are reused and further specified.

  • From reading the TGs a value from one of these 2 code-lists has to be applied (regardless from further more detailed description e.g. Constrain or Statistical Measure) 
  • Annex C of the same guidelines only lists the BODC_P01ParameterUsageValue (but no longer the CFStandardNamesValue) and it marks the code-list as extensible

3) The COMMISSION REGULATION (EU) No 1253/2013of 21 October 2013amending Regulation (EU) No 1089/2010 implementing Directive 2007/2/EC as regards interoperability of spatial data sets and services again leads to the following conclusions:

  • In section 7.3.3.1 regarding the phenomenon type (where the two discussed code-lists relate to) it is stated "The allowed values for this code list comprise the values of the following code lists or other code lists defined by data providers:" and only the BODC_P01ParameterUsageValue is listed. But it is clearly stated that other code-lists can be applied.
  • In section 14.2.1.1 regarding the BODC_P01ParameterUsageValue specifically it is clearly mentioned that "The allowed values for this code list comprise any values defined by data providers."

 

This leads us to the basic questions:

  1. Is the OF DS mandating the usage of values from one of the two code-lists exclusively?
  2. Is only BODC_P01ParameterUsageValue mandatory/suggested or additionally CFStandardNamesValue? 
  3. Is/are the code-lists extendible or not?

 

This questions might flag up potential inconsistencies between IR, TG and the UML model. We would like to get and discuss other opinions or experiences on these issues. 

Thank you very much in advance!


Best regards 

Christian Ansorge

  • Robert TOMAS

    Dear Christian,

    I have checked the issue and I believe that first we have to reconfirm what was the intension of the TWG-OF related to the harmonization of the phenomenon type that is being observed. Keiran Millard - is the right person to replay since he is the facilitator here + was the facilitator of the TWG-OF.

    I personally believe that the intention was:

    1)  to make the phenomenon type semantically interoperable there fore a code list "PhenomenonTypeValue" was defined (without values) with a full extensibility option ("any").

    2) To help data providers to use the code list two external code lists where identified as suitable (BODC_P01 and CFStandardNames) and they are recommended to be used.

    3) Data providers can use / extend "PhenomenonTypeValue" code list by any term/code list, but if such extensions/additions need to follow a formal procedure (e.g. the new terms have to be accessible to all INSPIRE stakeholders - placed or linked to the INSPIRE code list register. - the precise procedure was extending / adding code lists or values is still under discussion of MIG-T as well as INSPIRE CT.

    So if this "summary of the intension" is correct that we will have to follow steps to clarify it better first in the legal text (e.g. adding the CFStandardNamesValue to the Section 14.2.1. Code lists; Theme specific requirement (14.3.(3))  related to obligation to use BODC or CFStandard names only not additional terms etc.)

    The next step is also to add  CFStandardNamesValue to the Annex C of the Technical Guidelines...

    Let see what Keiran says.

    Robert

     

     

     

     

  • Keiran MILLARD

    By Keiran MILLARD

    Hi Christian / Robert,

    This issue goes beyond OF and general approach of Inspire to external code lists. 

    During Inspire drafting there was a lot of discussion about code lists managed externally to Inspire.  The problem was that Inspire could not mandate an instance of a codelist as very soon the Inspire legal act would not be in synchronisation with community practice that would evolve more quickly.  There was also a concern about the use of codelists not maintained within the EU (or had significant EU influence on its direction)  as we did not want major revisions to codelists forcing revisions to Inspire by the back door.

    Hence the approach taken was to make recommendations in the technical quidelines of codelists that were in use and that users should follow; but if users had a well managed codelist of their own they were free to use it.  It is left to the data providers to be 'sensible'.

    So, Roberts '1,2,3 synopsis' above is correct.  Specifically for OF, given the widespread use of the BODC Parameter dictionary by SeaDataNet there would need to be a strong case not to use it, and if a new parameter were needed, use the existing update procedures in SeaDataNet rather than extend within the context of Inspire.  I also think the BODC PD contains most of the CF terms, which maybe why less emphasis was placed on referring to it in the Inspire text - this I would need to check.

    Best regards

    Keiran

     

     

     

  • Christian ANSORGE

    By Christian ANSORGE

    Dear Keiran and Robert,

    Thank you very much for the prompt and helpful answers.

    May I ask about the next steps in this regard? I guess it needs some kind of further discussion what will be the reference for updates. If it is the UML updates of the legal text and more urgently the TG could be necessary.

    Have a nice evening and thanks again for the responses.

    Cheers

    Chris

  • Michael LUTZ

    Dear Christian, all,

    I think we should start from what is written in the legal act, where it is clearly written in 14.3 (Theme-specific Requirements on OF):

    (3) The observed property of an OM_Observation shall be identified by an identifier from the BODC P01 Parameter Usage or Climate and Forecast Standard Names vocabularies.

    So the IRs mandate the usage of either of these 2 code lists. The 1st is defined in OF, the 2nd in AC-MF. Both of them (together with specific code lists in other themes) are defined as sub-types (extensions) of the (abstract) PhenomenonTypeValue code list, which is used in the INSPIRE O&M model.

    The BODC P01 Parameter Usage code list is a typical example of an external code list that is not mandated but only recommended in the IRs - as explained by Keiran. Therefore it is modelled as an empty, extensible code list in IR with the addition:

    Data providers may use the values specified in the INSPIRE Technical Guidance document on Oceanographic Geographical Features

    This is all quite clearly described in the OF TG in section 5.3.1.2.12. Observed properties and OF Vocabularies. So I don't think anything really needs to happen, except probably correcting the extensibility tagged value in the UML model (from none to any). Note that the extensibility is reported correctly in the registry: http://inspire.ec.europa.eu/codelist/BODC_P01ParameterUsageValue/

  • Keiran MILLARD

    By Keiran MILLARD

    This question has come up at the Inspire Marine Pilot workshop in Copenhagen today. "Why doesn't the BODC parameter vocabulary specify units of measure?". The answer is that the parameter vocabulary does not specify the units of storage (or measure) - only the parameter term itself. Units of storage are agreed by the user community (e.g MSFD) but the BODC storage unit vocabulary (PO6) can be used as a reference. If the storage unit you require is not in this vocabulary it can be added - just request it on this forum.

This discussion is closed.

This discussion is closed and is not accepting new comments.

Marine & Atmosphere

Marine & Atmosphere

Oceanographic Geographical Features, Sea Regions, Atmospheric Conditions and Meteorological Geographical Features