European Commission logo
INSPIRE Community Forum

Inspire registry. External code list. NACE values.

Pedro MONTEIRO
By Pedro MONTEIRO Replies (11)

Hello.

Sorry for the foreword (just to frame the subject), but there is a practical question (in the end).

A. Inspire UML Consolidated Model (Annex III Themes)

a) Activity Complex and Agricultural and Aquaculture Facilities models include a «code list» EconomicActivityNACEValue with a vocabulary that points to Inspire Registry http://inspire.ec.europa.eu/codeList/EconomicActivityNACEValue (valid, yet with no values, one has to look for them in Eurostat’s NACE code list; in my case, the value is A.03.22);

b)  Production and Industrial Facilities (extension) and Population Distribution – Demography models include a «code list» NACECodeValue with a vocabulary that, in first theme, points to Inspire Registry http://inspire.ec.europa.eu/codelist/NACECodeValue (also valid, yet with no values), and, in second theme, points directly to the aforementioned Eurostat’s code list, with its values: http://ec.europa.eu/eurostat/ramon/nomenclatures/index.cfm?TargetUrl=LST_NOM_DTL&StrNom=CL_NACE2

My correspondent value A.03.22 can then be resolved and reached with http://ec.europa.eu/eurostat/ramon/nomenclatures/index.cfm?TargetUrl=DSP_NOM_DTL_VIEW&StrNom=NACE_REV2&StrLanguageCode=EN&IntPcKey=&IntKey=18495374&IntCurrentPage=2&linear=yes

B. Rules for code list values

Section 4.2.5.3. of D2.10.3: Generic Activity Complex, Version 1.0rc3 (http://inspire.ec.europa.eu/documents/Data_Specifications/D2.10.3_Activity_Complex_v1.0rc3.pdf#page=19)

Section 5.4.3.3. of D2.8.III.8 INSPIRE Data Specification on Production and Industrial Facilities – Technical Guidelines (http://inspire.ec.europa.eu/documents/Data_Specifications/INSPIRE_DataSpecification_PF_v3.0.pdf#page=65)

and, less precise, Section 5.4.3.3. of D2.8.III.9 INSPIRE Data Specification on Agricultural and Aquaculture Facilities – Technical Guidelines (http://inspire.ec.europa.eu/documents/Data_Specifications/INSPIRE_DataSpecification_AF_v3.0.pdf#page=60)

Those rules tell me that I ought to write my correspondent value identifier like this: http://inspire.ec.europa.eu/codeList/EconomicActivityNACEValue/A.03.22

[or, eventually, http://inspire.ec.europa.eu/codeList/NACECodeValue/A.03.22]

This is not resolvable, in the sense that the value cannot be reached. By the way, HALE can import the “code list” from Inspire registry, but - as expected - cannot show the values (eg. in Assign function).

C. However, Section C.5.2 of D2.7: Guidelines for the encoding of spatial data, Version 3.3 (http://inspire.ec.europa.eu/documents/Data_Specifications/D2.7_v3.3rc3.pdf#page=35) has a Recommendation 19 that - besides similar and precise general rules - includes:

“Other URIs may be used, too, for items managed in external registers. For registers with stable URIs as identifiers, these URIs may be used instead. For external registers that do not provide stable URIs, the inspire URIs will be used.”

Also, Section 9.4.5.3 of D2.5: Generic Conceptual Model, Version 3.4 (http://inspire.ec.europa.eu/documents/Data_Specifications/D2.5_v3.4rc3.pdf=page=51) includes:

“Ideally, an externally managed code list should meet the following requirements: 1. It should be managed by a competent international organisation. 2. It should be well maintained, i.e. all its values must remain available forever, even if they have been deprecated, retired or superseded. 3. The code list and each of its values should be identifiable through a persistent URI in the „http‟ scheme. 4. The code list should be available in HTML plus at least one of the following machine-readable representations: GML dictionary |SKOS. However, not all external code lists will meet these requirements. If an external code list is used in an INSPIRE application schema, but does not meet the requirements, the values will be made available through the common INSPIRE code list registry. NOTE This representation has to be maintained and updated if the reference in the INSPIRE application schema is updated to a new version of the external code list. A workflow for this should be defined as part of the terms of reference for maintenance and implementation.”

D. Then, considering Eurostat’s NACE code list “externally governed” (not “governed” by Inspire, or Inspire registry), it would be regrettable to conclude that it is not stable and/or does not meet the above requirements (odd, for an EU organization, that manages geographical related classifiers such as NUTS, and maintains “standard” “code lists” such as NACE, as “standard cross-domain code lists used in Eurostat's reference database, recommended for production databases and data transmission”), Nevertheless if that would be case, then Inspire registry should, at least, contain, or harvest, or link to, NACE values, in order to generate their correspondent resolvable URIs, for us to write in xlink:href  (warning: I’m trying to harmonize my data, but I know little or nothing about programming, scripting, xml, gml, etc).

So, even after reading discussions https://themes.jrc.ec.europa.eu/discussion/view/87314/external-code-list-values-natura2000andemeraldbio-geographicalregionclassificationvalue and https://themes.jrc.ec.europa.eu/discussion/view/87314/external-code-list-values-natura2000andemeraldbio-geographicalregionclassificationvalue?offset=10 , my practical following question still remains.

E. Question

What is – or will be  – 100% “Inspire compliant” (conformant, no issues) in Agricultural and Aquaculture Facilities theme (Activity Complex < Holding / function; and Site / activity) for Freshwater aquaculture:

1.

xlink:href="http://inspire.ec.europa.eu/codeList/EconomicActivityNACEValue/A.03.22"

or

xlink:href="http://ec.europa.eu/eurostat/ramon/nomenclatures/index.cfm?TargetUrl=DSP_NOM_DTL_VIEW&StrNom=NACE_REV2&StrLanguageCode=EN&IntPcKey=&IntKey=18495374&IntCurrentPage=2&linear=yes"

or something else?

2 [aditionally].

xlink:title="Freshwater aquaculture"

or

xlink:title="A0322 Freshwater aquaculture"

or

xlink:title="A.03.22 Freshwater aquaculture"

or something else?

 

Thank you

Pedro Monteiro

  • Iurie MAXIM

    Dear All,

    As Kathi pointed me this topic, I will try to provide some usefull information.

    Extensive discutions about externaly managed codelists were held as you mentioned as well, here:

     
    and here:
     

     

    Summarising:

    According to the provisions of D2.5 for externaly managed codelists at page 51 of the D2.5 PDF (page 46 printed on header) http://inspire.ec.europa.eu/documents/Data_Specifications/D2.5_v3.4.pdf#page=51 , that mention that if the externaly managed codelists do not meet the requirments stated in section 9.4.5.3. "the values will be made available through the common INSPIRE code list registry" and "a workflow for this should be defined as part of the terms of reference for maintenance and implementation".
    This is exacly what is writen in the D2.5 for the externaly managed codelists:
    However, not all external code lists will meet these requirements. If an external code list is used in an INSPIRE application schema, but does not meet the requirements, the values will be made available through the common INSPIRE code list registry
    NOTE This representation has to be maintained and updated if the reference in the INSPIRE application schema is updated to a new version of the external code list. A workflow for this should be defined as part of the terms of reference for maintenance and implementation. „
    It is clear that this is not a task for the Member States to be done.
    I wrote officialy to inspire-registry-dev@jrc.ec.europa.eu and I asked to solve this issue for several externaly managed codelists (related to biodiversity conservation) by the end of this year (2016), in order to allow us to finish the datasets that we are obliged to deliver within the 2017 deadline, because the existing externaly managed codelists (EEA) do not meet the requirements set in section 9.4.5.3. of the D2.5 T.G. I asked as well to be informed regulary about the actions that were made in this sense.
    I sugest you to to the same either by writing an official email at inspire-registry-dev@jrc.ec.europa.eu, or by writing an official letter trough the National Representative.
    If we have 2017 deadlines, some thinks must hapen in order to allow us to respect these deadlines.
    There are many other issues and things that must be done for ensuring compliancy, starting from having access to compliant tools, but this is what is necessary to be done in relation with the codelists (externaly managed, or not)
    Best regards,
    Iurie Maxim
  • Iurie MAXIM

    Here are some examples of externaly managed codelists for which the values were provided. They are only for Environmental Monitoring Facilities and it proves that this is what the INSPIRE registry should contain for all Data Themes. 

    1) http://inspire.ec.europa.eu/codelist/MediaValue

                  with values such as for example http://inspire.ec.europa.eu/codelist/MediaValue/air and Label ”air”

    2) http://inspire.ec.europa.eu/codelist/MeasurementRegimeValue

                  with values such as for example http://inspire.ec.europa.eu/codelist/MeasurementRegimeValue/continuousDataCollection and Label ”continuous data collection”

    3) http://inspire.ec.europa.eu/codelist/ProcessTypeValue

                  with values such as for example http://inspire.ec.europa.eu/codelist/ProcessTypeValue/process and Label ”Process” (not clear why this label is with first letter uppercase)

    4) http://inspire.ec.europa.eu/codelist/ResultAcquisitionSourceValue

                  with values such as for example http://inspire.ec.europa.eu/codelist/ResultAcquisitionSourceValue/exSitu and label ”ex-situ”

    5) http://inspire.ec.europa.eu/codelist/ResultNatureValue 

                  with values such as for example http://inspire.ec.europa.eu/codelist/ResultNatureValue/primary and label ”primary”

    Why only these externaly managed codelists are here? Most probably somebody struggeled to have them here.

    Therefore we shoud wait to appear the values for all those externaly managed codelists that do not meet the requirments stated in section 9.4.5.3. of the D2.5 to be provided in the EC Registry as it was possible to be done with the ones from Environmental Monitoring Facilities, mentioned above.

    Till then we can use the examples above from the Environmental Monitoring Facilities that gave as an indication on how it may look like.

    Personaly I would go with xlink:title="Freshwater aquaculture" without any code and with 

    either xlink:href="http://inspire.ec.europa.eu/codeList/EconomicActivityNACEValue/freshwaterAquaculture

    or with xlink:href="http://inspire.ec.europa.eu/codeList/EconomicActivityNACEValue/A.03.22" (prefered)

    Here it is starting a complicated discution if for example the ”freshwater aquaculture” had a definition and a meaning in a certain period (i.e.: 1990-2010) and another definition and meaning in another period (i.e.: 2010 - present) and if data is not comparable even if the value is the same.

    Such examples are for species, where a certain species name was given in 1800 and widely used for example till 2000 when the scientific comunity decided that there are actualy two different species ar they are from a different fammily or genus, In this case better is to use the codes and not the names as a name might refer to a certain code for a certain period and to another code for another period and have completly different meaning, Therefore at least for living organisms such as species and habitats better is to use codes as xlink:href and their names inluding the author and year for the xlink:title.

    Personaly I always prefer codes, more precisely integer numbers as they are easily stored and managed in a database as a primary key. If the codelists are not numbers, then the programmers need to transform anyhow all those values into numbers to store them in database.

    Another topic that will need to be further discused about codelists that are provided as xlinks, is that xlink:href MUST BE RESOLVABLE and it must return the LABEL to be shown in the attribute table.

    Currently there is no WFS capable of resolving external xlinks, but as the WFS 2.0 standard is indicating that capacity, it means that in the future we will have WFS capable of resolving those external xlinks. Currently the WFS are capable only to resolve internal xlinks, namely those that are refered in the same GML This means that when a value will be provided as xlink, for example as xlink:href="http://inspire.ec.europa.eu/codeList/EconomicActivityNACEValue/freshwaterAquaculture”, the WFS will know to go to that link and wait for the response. The response from that xlink will be the value that he will then shown to the user. I am expecting that value to be ”freshawater aquaculture”. I am not expecting that the link to provide me a http page with a lot of information. If more information would be needed to be provided, then I expect that that instead of a http page the xlink to provide me with a GML 3.2.1 to be included in the existing GML. At least this is how it is functioning a request it you want to provide for example the upper or lower level administrative units. It is an external xlink that is resolved by returning a GML.

    Therefore I do not think that the current INSPIRE Registry is prepared for resolving external xlinks.

    In the WFS 2.0 standard http://portal.opengeospatial.org/files/?artifact_id=39967 at page 248 it is writen 

    ”F.6.4.3.2
    Reference resolution
    Resolve: (Feature+, resolutionDepth) → Feature+
    The feature collection associated with a WFS may contain resources whose properties reference other resources within the collection or externally to resources in collections not managed by the WFS. This function takes each feature and applies the valueOf() function to each and every property. Since the Value of a Property may also contain further references, this process is repeated (i.e. valueOf() function is then applied to all properties of all resources in the Value of the Property) until the resolutionDepth is reached.„

    And at page 246 of the same WFS 2.0 standard it is writen:

    ”F.5 valueOf() function
    The valueOf() accessor function provides resolution of any references that may be encountered in determining the value of the Property. For example, in GML, a Property may have a Property Value specified by means of an xlink:href which points at the Value in question. In such a case the valueOf function must effectively traverse and resolve all such references.

    Therefore the INSPIRE registry will need to be redesigned in orded to resolve those xlink:href in order to alow the WFS 2.0 services to comply with the WFS 2.0 standard. This means that the request http://inspire.ec.europa.eu/codelist/MediaValue/air should return a GML having at least one element with the value "air".

    Similar the request http://inspire.ec.europa.eu/codeList/EconomicActivityNACEValue/A.03.22 should return a GML that can have more elements, for example the name of the activity "freshwater aquaculture", the code "A.03.22", the date from when the code is valid (beginLifespan), the endLifespan completed if the element is not anymore valid, etc. All these xlinks should return a GML in order to alow the WFS to resolve these xlinks.

    Quite a lot of thinks need to be done in the EC INSPIRE Registry in order to ensure that our services are compliant with the WFS 2.0 standard, isn't it?

    Best regards,

    Iurie Maxim

  • Iurie MAXIM

    In D2.5 Inspire Generic Conceptual Model at page 51 http://inspire.ec.europa.eu/documents/Data_Specifications/D2.5_v3.4.pdf#page=51 in section 9.4.5.3. External code lists it is writen 
    "Ideally, an externally managed code list should meet the following requirements: 
    ....
    4. The code list should be available in HTML plus at least one of the following machine-readable representations: 
    o GML dictionary 
    o SKOS 
    However, not all external code lists will meet these requirements. If an external code list is used in an INSPIRE application schema, but does not meet the requirements, the values will be made available through the common INSPIRE code list registry."
    I am asking myself, then the INSPIRE codelist registry should not satisfy all these requirements as well ?
    Indeed the INSPIRE codelist registry is available in HTML.
    But is INSPIRE codelist registry available as a GML Dictionary ? 
    It seems that the answer is not, Such a dictionary should provide a GML as a response to a request. This is necesary for the WFS 2.0 the resolve xlinks. Here is an example on how a response to a GML dictionary looks like : The http://www.opengis.net/def/crs/EPSG/0/3035 request provide the folowing response that can be used to resolve xlinks:
    <gml:ProjectedCRS xmlns:epsg="urn:x-ogp:spec:schema-xsd:EPSG:1.0:dataset" xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:gco="http://www.isotc211.org/2005/gco" xmlns:gmd="http://www.isotc211.org/2005/gmd" gml:id="ogp-crs-3035">
    <gml:metaDataProperty>
    <epsg:CommonMetaData>
    <epsg:type>projected</epsg:type>
    <epsg:alias code="2828" codeSpace="http://www.opengis.net/def/naming-system/EPSG/0/7307" alias="ETRS - LAEA">
    <epsg:remarks>
    This identifier is as used by the information source but has been superseded by the INSPIRE identifier.
    </epsg:remarks>
    </epsg:alias>
    <epsg:alias code="3659" codeSpace="http://www.opengis.net/def/naming-system/EPSG/0/7301" alias="ETRF89 / LAEA"/>
    .....
     
    Similar  results are for the request http://spatialreference.org/ref/epsg/3035/gml/
     
    Therefore we do not have the values inside the EC INSPIRE Registry and we do not have as well the services to provide us the values as GML in order to alow them to be resolved in WFS 2.0.
     
    We have the values only as XML, JSON, ATOM serving XML and CSV, even if the WFS 2.0 need them as GML.
     
    As now in the EC INSPIRE Registry the values can be acceseed as XML trough links such as http://inspire.ec.europa.eu/codelist/MeasurementRegimeValue/continuousDataCollection/continuousDataCollection.en.iso19135xml (most probably there is a bug in the EC Registrythat made the text doubled), we must wait until we will have the values provided at a link such as http://inspire.ec.europa.eu/codelist/MeasurementRegimeValue/continuousDataCollection.gml
     
    Threfore my sugestion for Pedro would be to use the xlink:href="http://inspire.ec.europa.eu/codeList/EconomicActivityNACEValue/A.03.22.gmlwith .gml at the end. This will allow to be compliant to WFS 2.0 standard, as othervise the xlinks will not be resolvable
    with request such as those provided in examples of WFS 2.0 standard, as for example the one at page 202 of the standard, section B.8.4.12, Example 12:
     
    http://www.someserver.com/wfs.cgi?

    SERVICE=WFS&

    VERSION=2.0.0&

    REQUEST=GetFeature&

    PROPERTYNAME=uk:Town/gml:name,uk:Town/gml:directedNode&
    RESOLVEDEPTH=1&

    RESOLVETIMEOUT=1&

    TYPENAMES=uk:Town&

    RESOURCEID=t1
     
    We will change all our xlink:href accordingly to add .gml at the end of the existing links and will wait for the EC INSPIRE Geoportal to provide the values in a GML Dictionary as indicated in the D2.5.
     
    Any comments would be highly apreciated.
     
    Best regards,
    Iurie Maxim
  • Michael LUTZ

    Dear Pablo, Iurie,

    as discussed with Iurie at the INSPIRE Conference last week, we are aware of the issues and questions around externally managed code lists and will have a discussion about this at the next MIG-T meeting. We will are also working on an implementation for the external values in the INSPIRE registry service.

    Finally, I have contacted the RAMON team at ESTAT to see if they have any plans to implement resolvable persistent IDs (i.e. http URIs) for the NACE classification in the near future. If not, we should implement them in the INSPIRE registry (as discussed in D2.7).

    We will keep you posted.

    Michael

  • Pedro MONTEIRO

    By Pedro MONTEIRO

    Thank you very much for the explanations.

    Now, the only thing needed is answering my practical question (just 1; 2 is not so important, and I will simply use xlink:title="Freshwater aquaculture", like Iurie recommends) and conclude. Hope I got it right and clear:

    F. Answer

    1. None of the solutions a) and b) is - or will be - 100% “Inspire compliant”:

    a) xlink:href="http://inspire.ec.europa.eu/codeList/EconomicActivityNACEValue/A.03.22&quot;, is not resolvable in a concrete value, also written in a GML [or SKOS] file, for compliance with actual and future WFS services; so rules or recommendations about NACE value identifiers, like those included in Section 4.2.5.3 of D2.10.3, Section 5.4.3.3. of D2.8.III.8, and Section 5.4.3.3. of D2.8.III.9, are out of date;

    b) xlink:href=”http://ec.europa.eu/eurostat/ramon/nomenclatures/index.cfm?TargetUrl=DSP_NOM_DTL_VIEW&StrNom=NACE_REV2&StrLanguageCode=EN&IntPcKey=&IntKey=18495374&IntCurrentPage=2&linear=yes&rdquo;, tough resolvable and leading to a fairly complete set of elements about NACE values (case A0322), is not persistent (stable) and (so) doesn’t meet all the requirements for external code lists, like those stated by Section 9.4.5.3.1 of D2.5_v3.4rc3 and by Section C.5.2 of D2.7 (Recommendation 19); and doesn’t retrieve any GML [or SKOS] file either;

    c) another solution, xlink:href=”http://inspire.ec.europa.eu/codeList/EconomicActivityNACEValue/A.03.22.gml&rdquo; could be possible in case of a future implementation of NACE classification onto Inspire registry, if  that implementation would consider naming the GML files strictly after the rules and recommendations mentioned in a) above (that, in NACE case, would yield a filename with 3 dots);

    d) another alternative solution is to wait for RAMON team to implement resolvable persistent IDs (i.e. http URIs) for the NACE classification in the near future…if they have plans to do so, and if  they also provide a GML file retrievable by those URIs.

    G. Conclusions

    EU Member States are obliged and have deadlines to implement Inspire, but – amazingly – at least some EU organizations like Eurostat / Ramon are not obliged to publish and maintain their standard code lists (“standard cross-domain code lists used in Eurostat's reference database, recommended for production databases and data transmission”) in order to make them retrievable by Inspire datasets and services, accordingly to Inspire rules and requirements.

    Accordingly, if Eurostat / Ramon doesn’t want to ensure those conditions for NACE code list, that work has to be done inside Inspire registry (perhaps with duplicate or increased efforts of implementation and future updating), leading to solutions similar to c) above, but in exact terms and within deadlines that we don’t know (yet).

    So, at least for now, and besides “many other issues and things that must be done" for ensuring compliance within Inspire (like Iurie said), there is no guarantee of a 100% “Inspire compliant” solution to express NACE values in xlink:href.

    My best regards

    Pedro

  • Michael LUTZ

    Dear Pedro,

    I agree that the current situation regarding externally governed code lists is unclear and understand that this is a problem for implementation.

    This is why we will discuss this issue at the MIG-T meeting on 25-26 October. After that discussion, we should have an agreement on which identifiers to use in cases where they are already managed in registers meeting the INSPIRE requirements and in cases where they are not.

    We will then start the implementation of the agreed way forward in the INSPIRE registry. As far as we can see now, the necessary changes shouldn't be too difficult to include.

    In the meantime, we have contacted the colleagues in the RAMON team to understand their implementation plans. You need to appreciate that, while INSPIRE has tried to adopt existing vocabularies and classifications where they are available (in order not to reinvent the wheel), these are usually created for other purposes and following other technical and policy requirements. So we cannot force them to follow our technical approaches (INSPIRE is not the centre of the world, unfortunately, but many of our colleagues "just another policy"). But we can voice our requirements and needs (which is what we are doing). And if they cannot meet those requirements, we need to find a different solution for INSPIRE. In practical terms, this would probably mean minting INSPIRE identifiers for all the terms in the NACE classification, much the same way the EEA have already done it in the EIONET data dictionary (http://dd.eionet.europa.eu/vocabulary/eurostat/nace_r2/view). But we would much prefer if ESTAT (as the owners of the classification) published PIDs for their terms themselves.

    Hope this helps. We will keep you posted.

    Michael

  • Pedro MONTEIRO

    By Pedro MONTEIRO

    Thank you Michael.

    I agree with your reply, except for Estat independence, regarding Inspire, being kind of – let’s say – acceptable. Each EU Member State also has his own policy for datasets and services, yet it must harmonize them according to Inspire; so I really think Estat should do the same with their “standard code lists” (precisely because of the previous cited definition); I’m not sure if this is up to Estat / Ramon to decide, perhaps someone higher should assume that those lists are also part of the desired data interoperability, in the context of integration and cooperation among EU services (e.g. recital 15 and article 6.3 of http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32012D0504).

    And yes, it should be much more efficient and cost effective that the owners of the classifications deploy and update this external compliant code lists themselves. Let´s hope so.

    My best regards

     

  • Iurie MAXIM

    I think that first step for codelists is to define an XSD schema for an INSPIRE registry. Even if a European institution or a MS would like to maintain an INSPIRE registry, it should know what kind of data it should provide and according to what schema. Otherwise the registries will not be interoperable.

    Because the IR is listing the following requirements:

    1. It should be managed by a competent international organisation. 
    2. It should be well maintained, i.e. all its values must remain available forever, even if they have been deprecated, retired or superseded.
    3. The code list and each of its values should be identifiable through a persistent URI6 in the „http‟ scheme. 
    4. The code list should be available in HTML plus at least one of the following machine-readable representations: 
    o GML dictionary 
    o SKOS 

     

    This means that at least the following information must be delivered through the GML dictionary:

    - the name of the competent organisation and all other necessary details to be able to contact that authority, similar like in the metadata point of contact, namely at least the email.
    - Lifecycle information for each value (beginLifespan and endLifespan)
    - Status: valid/deprecated/retired/superseded
    - Predecessor (the link to the predecessor value in the registry, if the predecessor was deprecated or superseded)
    - Successor (the link to the successor value in the registry if the status of the value is deprecated or superseded)
    - the shortened persistent  link to the codelist that is listing all the values (as GML)
    - the shortened persistent link that is allowing the download of all the values in the codelist (probably trough a WFS and a storedQuerry)
    - the persistent URI of the value (the link that provides the value as a GML file - this is necessary in order for a WFS service to be able to resolve the external xlink:href)
    - the link to the http page that is providing information about the value
    - the link to the http page that is providing information about the codelist in wich the value is listed
    - ... (for me it is not clear with SKOS at all)
    - ... (most probably many other elements)

    That's why I said that the current INSPIRE Registry must be redesigned.

    EU Institutions and MS must have clear rules in order to know how to build an INSPIRE Registry.

    Even if EEA or EUROSTAT would start to build INSPIRE registries, they will not have rules to make them interoperable with the the EC INSPIRE Registry.

    Unfortunately even the current INSPIRE Registry is not even made according to the existing Generic Conceptual Model IR and because of this it does not allow WFS services to connect to it in order to resolve the xlink:hrefs (The EC INSPIRE Registry is not a GML registry).

     

    I really hope that it will be done compliant in due time for allowing MS to meet the 2017 deadlines,

    Iurie Maxim

    PS: Same applies for the EC INSPIRE Metadata Editor that is not compliant with the current Metadata IR. And this is the main reason why in the EC Geoportal is not able to find the coupled resources and that's why we can’t find almost no network service in the EC Geoportal. There are only 49 services that are passing the EC Validation tests and this represent 0,05%.

     

  • Iurie MAXIM

    Dear Michael,

    I was just surprised to see this sentence regarding the involvement of the EU Institutions in INSPIRE: 

    <<So we cannot force them to follow our technical approaches (INSPIRE is not the centre of the world, unfortunately, but [for] many of our colleagues "just another policy").>>

    But what is happening at the Member States level ? 

    The Directive is forcing ALL public authorities at national, regional and local level in all EU Member States to follow INSPIRE technical approaches, putting INSPIRE in the centre of the world, because INSPIRE is "an EU policy".

    And therefore Member States are obliged to force all public authorities at national, regional and local level to follow INSPIRE technical approaches, putting INSPIRE in the centre of the world, because INSPIRE is "an EU policy".

    Therefore is quite strange that exactly the EU Institutions "cannot be forced", even if the INSPIRE Directive is listing EU Institutions as primary beneficiaries and even if the INSPIRE Directive can’t be implemented without the serious and proper involvement from the EU Institutions.

    I would like to thank to Pedro for mentioning the article 6.3 from the Commission Decision of 17 September 2012 on Eurostat (2012/504/EU), that is stating:

    “Eurostat shall ensure cooperation and regular constructive dialogue with other services of the Commission and, where necessary, with data providers with a view to taking into account user needs, relevant policy developments and other initiatives. To this end, those Commission services that are potential users of specific European statistics shall be informed and involved from an early stage in the development of new or changed statistics, among other things in order to understand the potential policy implications of new or changed statistical methods, standards and definitions.”

    I am quite sure that similar articles exist for other Pan European Institutions and for other services of the Commission as well.

    Just to provide an example, similar articles and similar scope exist for the European Environmental Agency as well, in the EC Regulation no 401/2009 on the European Environment Agency and the European Environment Information and Observation Network http://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32009R0401&from=EN

    Therefore, JRC must be encouraged to involve all these EU institutions in order to properly implement the INSPIRE Directive and to make them act as locomotives in order to provide the necessary support for the establishment of the INfrastructure for SPatial InfoRmation in the European Community (INSPIRE).

    Otherwise, Member States can see this INSPIRE Directive "just as another EU policy" that is not really needed by European Community and that is just a burden.

    And this is not the case and this is not what is expected from the INfrastructure for SPatial InfoRmation in the European Community, established "for the purposes of Community environmental policies and policies or activities which may have an impact on the environment".

    Any comment would be highly appreciated.

    Best regards,

    Iurie Maxim

  • Michael LUTZ

    Dear Pedro,

    I think you may have misunderstood my comment. As I said, we are discussing the issue with the colleagues from ESTAT and looking for a solution. We do the same with other colleagues in the Commission and agencies whenever needed.

    I just wanted to point out that we all, and especially cross-cutting DGs like ESTAT, have to meet many requirements from different domains, and that INSPIRE is just one of them. So, even if we may not like it, we have to look for solutions that work for everyone. And that sometimes these may take some time.

    So please be patient - we will keep you posted. Thanks for your understanding.

    Michael

This discussion is closed.

This discussion is closed and is not accepting new comments.

Facilities & Utilities, Public Services

Facilities & Utilities, Public Services

Covers a broad set of facilities, installations, networks and constructions supporting economic activities and public services