DraftTGMetadata v04


Draft version of Technical Guidelines Metadata v.04

Updated 2015-07-20

Draft version 0.4

The document can be reached here

This version contains updates solved from version 0.3.
There are still open discussions on serveral areas so detailed editorial checkups are still not done.
Eg Requirement numbers  are not following a correct sequence.
Also a number of examples are still missing.


Reading Guideline

To aid readers in understanding the descisions taken in this draft version and what changes are done since last published version of TG Metadata
a reading guideline is available.

For comments on these sections use the table below. The Wiki and Issue-tracker for these issues are now locked for further editing.
All comments on these sections should be done here.

Please note that numbering of requirements and recommendations are not updated so these references are still to be updated once we have agreed on content.
If you are writing responses on comments start every such section with date and name like:
2015-06-15 (your name):

Type: Ed = Editorial, Te = Technical, Ge = General

ID Comment by Clause/
Line No
Type Comment__________________________ Proposed solution____________________ Response______________________________________________
1 Antonio Rotundo Draft 04 - 2.9 60 Te/Ed On the base of the comments on clause 2.9 (Constraints related to access and use) and subclauses 2.9.1, 2.9.2, 2.9.3 and 2.9.4, I tried to do a new wording; you'll find the proposal in the attached file. As you'll see, useLimitation element is no longer used and so, as it is optional, it could be used with the meaning given by ISO 19115. See attached file

2015-08-07 Agree with Antonio regarding 2.9.1 (and 2.9.3), even if I would make a recommandation to be careful when using the MD_SecurityConstraint
(see my initial inputs for the reading guidelines, attached).


Regarding 2.9.2 and 2.9.4, I still think that we have to use useLimitation (from MD_LegalConstraint or MD_Constraint in cas of technical constraints. (see my initial inputs for the reading guidelines, attached, for the argument). This means : suppress 2.9.4, and add in 2.9.2 the link to the registry for the default value (no condition apply)


2015-08-16 (Antonio): Regarding the use of MD_SecurityConstraints and the inputs about that posted by Eliane, I found a Wikipedia page that gives a detailed overview about the issue of classified information (see https://en.wikipedia.org/wiki/Classified_information#cite_note-13). In that page, the level "unclassified" is defined as "technically not a classification level". Actually, I noticed that in most cases the level "unclassified" is not included in the classification levels defined in the national or international laws. E.g. in the Italian legislation there are four classification levels (top secret, secret, confidential, restricted); also European Commission have the same levels (see art. 2 COUNCIL DECISION of 23 September 2013 on the security rules for protecting EU classified information - http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2013:274:0001:0050:EN:PDF). In both the classifications, the values match with those ones included in the codelist defined in ISO 19115 (MD_ClassificationCode); so, the value “unclassified” could be used in all the cases in which no level is assigned.

In the Wikipedia page cited above, also the cases of France, UK, Romania and Sweden are described; there is also a table of equivalent classification markings in various countries.

Probably, it would be useful that every WG member verify the classification defined in his own Member State and above all if the level “unclassified” is included  in that classification.

It would seem to me that only NATO includes the level “unclassified” in its own classification.

But is INSPIRE interested in NATO information? Or, is NATO required to document its (spatial) data and services, if any, following the INSPIRE rules?

So, I think that the value “unclassified” defined in ISO 19115 (MD_ClassificationCode) can be used with the meaning given in ISO 19115 (“available for general disclosure”) in all the cases in which no classification level is assigned to information.


2015-08-20 (Peter): concerning MD_SecurityConstraints: In Germany I  haven't seen any entry other than "unclassified" by now. Especially in Northrhine-Westphalia we have documented this element as to concern military issues only so the involved administrations (usually non-military) will make use of entry "unclassified" without thinking of it any further.


2015-08-24 (Peter): concerning 2.9 itself and the draft for a new wording: It looks much more easy to read than the previous text in draft 04 and I would propose to follow this attempt while having this and that improved.

Some issues that I would like to raise here (disregarding diction and spelling for now):

- first sentence in 2.9.1: it has to be Article 5(2) (e), not (f)

- TG requirements 3, 5 and 6: we already came clear that otherConstraints can't exist without chosing MD_RestrictionCode="otherRestrictions" in accessConstraints or useConstraints within the same MD_LegalConstraints (see also #9 on draft 03 and #15 on draft 02). That should be expressed in the TG requirements as well when demanding the combination of accessConstraints or useConstraints and otherConstraints.

- same issue as before for the tables on accessConstraints and otherConstraints: they also don't consider the need of MD_RestrictionCode="otherRestrictions"

- providing a codelist for the reasons following article 13 in 2.9.1: Is this a recommendation or even a requirement? The table listing otherConstraints for issue B 8.2 only allows the data type gmx:Anchor and a codelist value from INSPIRE registry. So I guess it will be a requirement! Otherwise (recommended only) the table has to be extended to consider a free text citing one of the given reasons as well. I would prefer to have the codelist value mandatory because this was one of the arguments to avoid conflicts with free text content from 2.9.2!

- tables on otherConstraints in 2.9.2:

-- the field INSPIRE obligation / condition with otherConstraints does not suit here. Looks like copied and pasted from limitations on public access.

-- Field Comments contains a recommendation for using a codelist value in case of unknown conditions or no conditions. TG requirement 8 is more binding and demands this which I consider to be right!


2015-08-26 (Antonio): I updated the draft of a new wording of clause 2.9 (see attached file) taking account of what noted and suggested by Peter.

Concerning the first response of Peter, even in Italy it's the same.


2015-08-30 (Michael Ö): The text is more clear now I think this is great step forward. TG Requirement 4 (in Antonios text) defines a specific security constraint. With this text  I think the value public access to spatial data sets and services would adversely affect  international relations, public security or national defence should be removed from table LimitationsOnPublicAccess since it should only be used as a security classification. Or could this code be used with either access MD_SecurityConstraint or MD_LegalConstraint ? The use of SecurityClassification in Sweden is quite  limited so we have very litlle expeience of using it besides the military organisations.


2015-08-30 (Antonio): In last updated version of the new wording, I had already removed the value mentioned by Michael from the codelist LimitationsOnPublicAccess.


2015-10-16 Ine: added the version off Antonio in version 0.55


2015-10-19 (Peter): fixed the 2.9.x-links in Ine's version 0.55


2 Antonio Rotundo     Te As far as the open issues in the draft, I added some responses to some comments (#1, #4, #7, #34) on draft 03.  

2015-08-19 (Peter): widely considered; #1 on draft 03 can be followed as #10 on draft 04; #4 and #34 on draft 03 can be followed as #9 on draft 04

3 Eliane Roos 2.2.6 7 (xml encoding) te The XML encoding mention the fileIdentifier metadata element. However
1) This element is not an INSPIRE metadata element,
2) Is is never mentioned elsewhere in the document

first (prefered) proposal : delete every mention to fileIdentifier in the TG


alternative proposal : add a footnote to explain that fileIdentifier is not an INSPIRE metadata element, that it comes from ISO 19115, and that some metadata editors (GeoNetwork for example) fill it automatically with an uuid.

2015-08-16 (Antonio): although the fileIdentifier is not an INSPIRE metadata element, it is mandatory for the CSW ISO Metadata Application Profile. It corresponds to a mandatory queryable element and is particularly essential for the getRecordById operation (even if that operation is not required for INSPIRE discovery services).

So, I think that it is important adding also a note to explain that, without deleting every mention to it.


2015-08-30 (Michael Ö): This is a element that is somewhow confusing I must admit. But even if it is not a mandatory INSPIRE element (in IR Metadata) it must be included as I see it. Since publishing records in a discovery service is mandatory for INSPIRE metadata anyone using a CSW as the discovery service must include it. Besides the use in the GetRecordsByID (as Antonio mentions) it is also a mandatory element in the GetRecords response even for the core returnable properties (brief). I also have problems seeing a proper infrastructure with harvesting could be created without having the fileidentifier. Could someone explain how this will work without a fileIdentifier? Even though this element is not listed in IR Metadata it is required to build the infrastructure so I think this should be mentioned in TG Metadata. As I see it now the TG Metadata is not only for implementing the requirements in IR Metadata. It is for implementing the requirements on metadata for the INSPIRE infrastructure? Correct me if I'm wrong here.

4 Eliane Roos 2.12.1   te I agree with Peter proposal on draft#3, comment 40 (We have the same XML implementation within the french guide for INSPIRE metadata). the description of the coordinate reference system could be more developped in the XML part. integrate Peter proposal in this clause? 2015-09-10 (Peter): considered in maintained draft 05 as discussed in Malmö
5 Eliane Roos 2.12.1 Table (line INSPIRE obligation) te

It is written here :

"Mandatory for dataset and dataset series;

not applicable to services
Mandatory if  relevant for interoperable spatial data services"

Are 2 last sentances unconsistent ?

modifiy to :

"Mandatory for dataset, dataset series and, if  relevant, for interoperable spatial data services"

Maybe add "not applicable for other services"


same issue for the multiplicity (next line)

2015-08-24 (Peter): In detail Eliane of course is right. In general we got the problem to have a new context for this element since integrating the metadata on SDS which I still assume not to be the best way.


2015-09-10 (Peter): considered in maintained draft 05 as discussed in Malmö (see #43), differing Network services from Other spatial data services


2015-10-16 Ine:the sds metadata is removed here to chapter 2.14 in version 0.55

6 Eliane Roos 1 (TG req 29) ed Sorry, but I do not understand the last part of the sentance ("considering a mandatory element given by ISO 19115 in addition") what is this mandatory element? in addition of what? what is the link with the beginning of the recommandation?

2015-08-19 (Peter): It means that the elements given in DataSpecs for this (aiming at ISO 19157) can be found in ISO 19115 as well (more or less well matching). But when making use of DQ_QuantitativeResult in ISO 19115 you have to fill element valueUnit (135) as well which is not mentioned concerning quantitative results of TopologicalConsistency in DataSpecs.

Proposal: we can have a separate sentence in TG Rec 29 for this special case of needing an additional element which is mandatory: "As long as being based on ISO 19115 only, the metadata elements reporting quantitative results on Topological consistency should be expressed by corresponding ISO 19115 elements of DQ_QuantitativeResult as shown in the table above. Due to ISO 19115 one mandatory element (valueUnit) is added there though not derived from matching with the foreseen ISO 19157 elements."


2015-08-25 (Peter): Considered for next draft and sent to Michael Ö

2015-08-31 (Michael Ö): Update is done based on Peters suggestion above.
Can we as a recommendation in the example file suggest the use nilReason for this element if it does not have any meaning in this context ?
e.g  <gmd:valueUnit gco:nilReason="inapplicable"/>
I see the example shows a reference to uom at OGC maybe that is better. What does this actually mean, Elaine can you describe this ?


7 Eliane Roos 7 (example of xml encoding) te example missing

I sent some time ago an example that could be used here. see  in attached file

2015-08-19 (Peter): found it! I'm going to consider it a.s.a.p.

Is it suitable that your example contains elements that are not mentioned in our table above (like measureIdentification, measureDescription)? On the other hand the content for the listed elements evaluationMethodType and evaluationMethodDescription is missing! I think I can swap the content of measureDescription to evaluationMethodDescription. But what about the remaining ones?


2015-08-25 (Peter): Considered for next draft (regardless some open issues, see above) and sent to Michael Ö

2015-08-31 (Michael Ö ): is updated wih examples

8 Eliane Roos 57 te agree with Peter comment n°11 within the doc : the conformance result is not mentionned above. supress the conformance result example

2015-08-19 (Peter): as I answered in #9 I will use this example (after maintaining it for this purpose) for the attempt in of providing the descriptive results on Topological consistency as a DQ_ConformanceResult.


2015-08-25 (Peter): Considered for next draft and sent to Michael Ö

2015-08-31 (Michael Ö ): Example with conformance report is removes as suggested

9 Eliane Roos


descriptive result te As far as the open issues in the draft, I added some responses to some comments (#34, #36) on draft 03.  

2015-08-19 (Peter): If I read the comments on draft 03 right, there's no vote for using lineage any longer.

Concerning I will build a new draft considering DQ_ConformanceResult as proposed before by Antonio (see also #4 on draft 03). The cited specification in this case will be the Generic Network Model and pass will be FALSE. This is exactly the condition when to have this statement at all (article 13 of IR 1089/2010).

Concerning this will become more difficult: There's no specification given that is violated. So what will be documented here?


2015-08-25 (Peter): Considered for next draft (regardless some open issues, see above) and sent to Michael Ö

2015-08-31 (Michael Ö ): Regarding the specification to cite for a descriptive quality report. Wouldn't the dataspecification for each theme be a relevant specification for this? For some resports like Logical consistency  it could be a reference to the Abstract Test Suite in Annex I.


2015-09-10 (Peter): considered in maintained draft 05 as discussed in Malmö: is using DQ_ConformanceResult now; is cut off (no recommendation due to no matching element)

10 Eliane Roos 2.13.1 table (line Domaine) te

Sentance : "At least the following elements should be used (the multiplicity according to ISO 19115 is shown in parentheses):"


here it is not so obvious to understand which elements are required. I thought reading at answers on Peter comment 1 in draft #3 that this has been solved?

apply here solution proposed to comment 1 in draft #1

2015-08-16 (Antonio): I think that the required elements can be derived from the ISO multiplicity. But I agree that the proposed solution can clarify better.


2015-08-18 (Peter): Sorry for causing confusion! I had already prepared that issue based on draft 03 (#1) when Ine asked me beacuse she was preparing chapter 2.14. I agreed to re-build my improvements on 2.13.1 again into draft 04 which I just have sent to Michael Ö. It contains the fact that when making use of MD_MaintenanceInformation (which is optional) only maintenanceAndUpdateFrequency is mandatory. updateScope and maintenanceNote will be flagged as optional.


2015-08-25 (Peter): Considered for next draft and sent to Michael Ö

2015-08-31 (Michael Ö): Updated clarification from Peter into draft.

11 Eliane Roos

2.13.2, 2.13.3 2.13.4


TG reco 33,
34, 35, 37, 39, 40, 41



"The metadata elements concerning xxx should be included to metadata describing a spatial dataset or spatial dataset series related to the following INSPIRE annex themes:"


Why using "should" here, since the element is optional?

in fact, this reco are useless, everything is said in the tables, isn'it?

2015-08-19 (Peter): This is the attempt to flag the several issues to particular annex themes. Of course everything of this stuff is optional! But how can we document best that some issues are foreseen for certain annex themes and for others not?

To be completely neutral we could cut this recommendations and have the list of involved annex themes only in the table (field INSPIRE obligation/condition). Is there consent on this?


2015-09-10 (Peter): considered in maintained draft 05 as discussed in Malmö: now in an abstract way without naming particular annex themes (to be done in a separate document)

12 Eliane Roos 2.14.1     missing a title : Quality of Service?   2015-10-16 Ine: updates in version 0.55 ( numbering not yet ok under 2.14)
13 Eliane Roos 2.14.1 tables te see comment 38 on draft3   2015-10-16 Ine: updated in version 0.55
14 Eliane Roos 2.14.2 XML encoding, p114 line 16 & 17 te see comment 39 on draft 3   2015-10-16 Ine: updates in version 0.55
15 Marie Lambois 2.8.3 line 59 te would it be possible that the second example deals also with the invocable conformance class?  



16 Marc Leobet 1.3.1 line 17 Ed The MIG-T agreed in April 2015 on the following interpretation of the definitions of SDS & NS. The text is : "Spatial data service (SDS) is a general term within Inspire for all services used for exchanging, sharing, access and use of spatial data. All services within Inspire shall be discoverable, both Network services and other SDS. Based on different regulations, SDS is divided into two major groups; “Network services” and “Other discoverable spatial data services”. The other discoverable SDS are then divided into three different categories depending on level of interoperability; Invocable spatial data service, Interoperable spatial data service and Harmonised spatial data service." Add that text in Line 12. Replace "Other Services (other) by "Other discoverable spatial data services"

2015-08-25 (Peter): This has become a general problem! see #43


17 Marc Leobet Normatives références line 42 Ed

Because some metadata elements are now defined in Reg 1089/2010 for datasets and invocable SDS, we should reference it.

[Regulation 1089/2010/EC] Consolitated regulation 1089/2010/EC implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data services

2015-08-20 (Peter): I agree!


2015-10-19 (Peter): added in Ine's version 0.55

18 Marc Leobet Normatives références line 43 Ed Because some metadata elements are now defined in Reg 976/2009 for invocable SDS, we should reference it. [Regulation 976/2009/EC] Consolitated regulation 976/2009/EC implementing Directive 2007/2/EC of the European Parliament and of the Council as regards network services

2015-08-20 (Peter): In contrast to #17 I think that citing 976/2009 is not necessary because 1311/2014 only touches the definition of term "metadata element" in 976/2009 (referring 1205/2008 and 1089/2010). There are no further statements or details on metadata itself in 976/2009 now!


19 Marc Leobet 1.3.2 line 17 Ed

It seems to be a bit more complicated, as Regulation 1311/2014 defines that a metadata element for a SDS can be "set out in Part B of the Annex to Regulation (EC) No 1205/2008 or in Part B of Annex V, Part B of Annex VI and Part B of Annex VII to Commission Regulation (EU) No 1089/2010". The "new" parts B do not refer to D 4 of Regulation 1205/2008/EC. So the paragraph is not true anymore.

Do not we have decided to gather recommandations about SDS in a specific part? It would simplify the text and we could keep it just changing the title.

Move this chapter in SDS part of the TG.

Change the title in "Classification of network services"

2015-09-14 (Michael Ö): In TG Metadata the requirement on "Spatial data service type" and "Spatial data service classficification" applies to all spatial data services. Accordning to our current interpretation of "Other Spatial data services" (OSDS)  they are a subset of Spatial data services. That should mean that OSDS should have both have service classification and service type.  But my notes from Malmoe on this says we left his question open. Can someone recall better on our conclusions here ?


2015-09-21 (Peter): We had a mix-up of parts D3 (serviceType) and D4 (keyword) which could be solved.

As in #21: The issue itself comes from IR Metadata itself and is sufficient for all services as we decided to read "spatial data service" as Network service and Other SDS as well! My proposal: no move and no change of the title!


2015-10-16 Ine: i agree with Peter

27 Marc Leobet 1.3.3 line 29 Ed typo? instead of  

2015-08-25 (Peter): In my opinion is right.

21 Marc Leobet 2.3.1 Table Ed Factually, topic categories are now defined in 4 Part B of various annexes in two different regulations. Following the same idea about SDS, it would be clearer for everybody (I believe) to explain in the title that the chapter focused on datasets and NS, and let the adaptation in the specific SDS part of the TG. If not, the tables would become as complex that the regulations themselves. Change the title in

"Classification of spatial data and network services"

2015-08-25 (Peter): Can't see what should be wrong here. There's no relationship in 2.3.1 between TopicCategory (for datasets only) and SDS!

2015-09-15 (Michael Ö): This is related to #19. Since whole document is related to metadata for datasets and services. Can't we just rename chapter to  "Classification"


2015-09-21 (Peter): "Part B 2.1" in the table could be more precise and be like "IR Metadata Part B 2.1". I think this should be done when updating all references and requirements. It affects nearly every chapter!

The headline on 2.3 comes from IR Metadata itself and is sufficient for other SDS too as we decided to read e.g. "INSPIRE View service" as Network service and Other SDS as well! My proposal: no change of the title!

22 Marc Leobet 2.10.1 TG Req 42 Ed

I follow Michaël comment, it is not clear that the Req 42 aims only Inter. SDS. One could easily understand it as a req. for the whole chapter "responsible organisation" of datasets and services.

Add the words on the begginning of the req. : "For interoperable spatial data services, (...)".

2015-08-25 (Peter): Can't follow this. This is an old requirement for Responsible Party at all and it's sufficient.

2015-10-16 Ine: All SDS is moved to chapter 2.14 in version 0.55

23 Marc Leobet 2.10.1 Table Ed It looks strange to have twice "mandatory" for services and inter. SDS, as the second is first a service and is under the first line. The Req. 42 applying, it seems not necessary to add the second sentence.

Remove : "Mandatory for interoperable spatial data services"

2015-08-25 (Peter): The problem is that "service" is no longer sufficient when also concerning spatial data services for the same element. Maybe better to express it like "Mandatory for datasets and all services (network services and spatial data services as well)."

2015-10-16 Ine: All SDS is moved to chapter 2.14 in version 0.55

24 Marc Leobet 2.10.2 Table Ed It looks strange to have twice "mandatory" for services and inter. SDS, as the second is first a service and is under the first line. The Req. 42 applying, it seems not necessary to add the second sentence.

Remove : "Mandatory for interoperable spatial data services"

2015-08-25 (Peter): see #23

2015-10-16 Ine: All SDS is moved to chapter 2.14 in version 0.55

25 Marc Leobet 2.12.1


& Req. 48

Ed The European Community was replaced by the European Union Change in :

The value domain for this element is limited to the official languages of the Union.

2015-08-25 (Peter): though Marc maintained the numbering, I assume it has to be 2.11.3 and Req.47, right? Concerning the content of this comment. I agree!


2015-09-10 (Peter): considered in maintained draft 05

26 Marc Leobet 2.12.1 Line 4 Ed

as noted in the Table/Reference under (IR 1089/2010 Part B3), the Metadata element for interoperability "Coordinate reference system" is only required for spatial data sets and interoperable services. So WMS is out of the scope. Besides, Invocable SDS (which are not known up to now) could have nothing as a GetCapability.


Change in :

Description of the coordinate reference system(s) used in the data set or supported in the interoperable services."

2015-08-20 (Peter): ???

Has Marc got a different document? I can't find chapter 4.x! Is he talking about 2.12.1 instead?

2015-08-25 (LBT): Sorry! We have no Microsoft sofwares and the original .docx was impossible to open under OpenOffice. The transformations I had to do change the numbers in one part :-(.

I have corrected it.

28 Marc Leobet 2.12.1 Table INSPIRE Multiplicity Ed In annex VI Part C the multiplicity of "Coordinate reference system" metadata element is [1..*]. Remove the added words :

"for dataset and dataset series"

2015-10-16 Ine: All SDS is moved to chapter 2.14 in version 0.55
29 Marc Leobet 2.12.1 Req. 50 Ed If we add the reference to Art. 13-1 we have to add too Annex VI part B3. But as they are both in 1089/2010, it seems useless. Besides, the references are just above. Remove the added words : "(see Article 13, clause 1)" 2015-10-16 Ine: All SDS is moved to chapter 2.14 in version 0.55
30 Marc Leobet 2.12.2 Req. 52 Ed

The same identifiers listed shall be used for network services (IR 976/2009 annexes III, IV & V). I have not found a legal requirement which would define coordinate reference system following Regulation 1089/2010/EC, II, 1.3, but it would be a wise recommandation.

(I have not checked the list itself).

Change the last sentence in: "The identifiers listed in the table below shall be used for referring to the coordinate reference systems used in a data set or in spatial data services".  
31 Marc Leobet 2.12.3 Req. 53 Ed The requirement mixes a comment (Temporal Reference System property is not mandated by ISO 19115) and a recommandation. The comment is yet in the table above. Please keep only the recommandation. Change the requirement in :"Temporal Reference System property is mandated only if the Temporal Reference System is other than Gregorian Calendar or the Coordinated Universal Time (see Article 13, clause 2)."  
32 Marc Leobet 2.12.4 Req. 54 Ed The requirement mixes a comment (Encoding property is not mandated by ISO 19115) and a recommandation. The comment is yet in the table above. Please keep only the recommandation. Change the requirement in :"Encoding property (in the meaning of the supported file format when providing data) is mandated (see Article 13, clause 3).  
33 Marc Leobet 2.12.5 Req. 55 Ed The requirement mixes a comment (Character Encoding property is not mandated by ISO 19115) and a recommandation. The comment is yet in the table above. Please keep only the recommandation. Change the requirement in :"Character Encoding property is mandated for conformance to the INSPIRE Regulation 1089/2010/EC only if not using UTF-8 (see Article 13, clause 5).  
34 Marc Leobet 2.12.5 Req. 56 Ed The requirement mixes a comment (Spatial representation type property is not mandated by ISO 19115) and a recommandation. The comment is yet in the table above. Please keep only the recommandation. Change the first sentence in :Spatial representation type property is mandated for conformance to the INSPIRE Regulation 1089/2010/EC only if not using UTF-8 (see Article 13, clause 6).  
35 Marc Leobet 2.12.6 Peter's comment  page 89 Ed +1 to the Peter's comment. Remove the conformance result example.  
20 Age Sild




line 5


Marc pointed to MIG-T agreement about SDS (see: https://ies-svn.jrc.ec.europa.eu/issues/2377) in comment 16. In this agreemet there is also mentioned about Spatial data service types: "(3.5)Invoke (The value (3.5) Invoke should no longer be used within Inspire, since it has no significant meaning. The last amendment to Regulation 1089/2010 describes SDS in a more useful way by the Invocable Category.)".  Is this clause sufficient reason to remove 'Invoke Spatial Data Service' from the spatial data service type list (1.3.1), adding a note, why it has removed? Invoke service is also mentioned in 2.3.2 line 5.

  LBT 12.08.15 : good point!  You are right, the MIG-T aggreed on that and we would have to remove Invoke services from the TG MD. I support your proposal to add a comment, for example the point 3.5 extracted from the C. Wasström paper :

"The value (3.5) Invoke should no longer be used within Inspire, since it has no significant meaning. The last amendment to Regulation 1089/2010 describes SDS in a more useful way by the Invocable Category."

IdV 16-10-2015 : proposed change is made in version 0.55

36 Marc Leobet


Title Ed

This chapter is focused on Interoperable service.

Change title in :

"Metadata for Interoperable Spatial data services"


2015-10-16 Ine: All SDS is moved to chapter 2.14 in version 0.55

titles and classes are made clear

37 Marc Leobet



Text Ed

Usually the regulations are referenced under the name of the first text adopted.

Change reference in :

as defined in the INSPIRE Regulation n°1089/2010 modified by Spatial data services Regulation (EU) No 1312/2014

38 Marc Leobet



Text Line 58

Ed In this chapter we are describing metadata elements from Annex V Part B1 establishing Invocable services. Change title in :

Metadata for invocable Spatial data services

Change sentence in :

The invocable SDS are divided into three different categories



2015-10-16 Ine: All SDS is moved to chapter 2.14 in version 0.55

titles and clases are made clear

39 Peter Kochmann 2.12.3 88: 27 (Field "Domain" in table) Ge

picking up #11 (and #30 implicitly) on draft 03 again, which are unsolved by now:

We already have a hint to also make use of INSPIRE registry for giving a certain format. But INSPIRE registry lists mediatypes (e.g. "image/tiff" instead of "tiff"). Will this be a problem?

Furthermore it was proposed to mention the use of an anchor-element as well and to integrate an XML example for this.

1. table: "... Content for element name could also be taken from INSPIRE registry using the codelist available here: http://inspire.ec.europa.eu/media-types/ and can be accessed via gmx:Anchor (see XML example)"

2. first (old) XML-example:  change characterString for name to "SHAPE" instead of "application/x-shapefile"

3. second (new) XML-example considering gmx:Anchor on INSPIRE registry

2015-08-25 (Peter): Considered for next draft and sent to Michael Ö
40 Peter Kochmann 2.12.1 comments by Michael and Ine Ge In Northrhine-Westphalia we already store this information in metadata on both data and services. The information deriving from service capabilities will be copied to metadata when importing them for building up service metadata.   2015-10I deleted the word services there because all sds is now in chapter 14. The IR MD has only an requirement on datasets
41 Age Sild Line 19 (Function table) Ge

To be in accordance with ISO19115 we are not describing function as OnLineFunctionCode. In draft it is described as '401. description'  and 'data type (and ISO 19115 no.)' is set as Free text. Isn't it better to use CharacterString as data type? Data type as Free text might be misleading here, because 'Function' domain is not really a free text - it is a specific codelist.

Use CharacterString as data type

2015-08-27 (Peter): a.f.a.I.k. "free text" is always coded as CharacterString in XML. Furthermore I wouldn't call it a "codelist" but a "list of values" instead (like we have in 1.3.1 for the spatial data service type). A codelist I expect to be defined and stored in an accessable schema.


2015-08-31 (Michael Ö): Using only the description text without any reference could be hard for users to understand. This  element could already contain other text so  a suggestion is to place this code list in INSPIRE registry and possibly use an Anchor to refer to this

42 Age Sild 2.8.3 Line 48 (Category table) Ge/te

Invocable SDS category and invocable SDS specification are both described in metadata using ISO19115 130. specification and ISO/TS 19139 path, nevertheless they are different INSPIRE metadata elements.

Information in this table is confusing. It is describing Category, but on Reference line there is also citation to Specification (COMMISSION REGULATION (EU) No 1089/2010, Annex V, Part B 1 and Annex V, Part D 2). If we want to describe in chapter 2.8.3 both - sds category and sds specification, it seems to me, that it is not good to put them into the same description table.

Describe in chapter 2.8.3 invocable sds specification and invocable SDS category  as different metadata elements (in different tables)


change a bit 2.8 subchapters:


'2.8.1 Degree' - describes also degree of conformity of invocable sds category


'2.8.2  Specification' - chapter describes also gmx:Anchor example for invocable SDS


'2.8.3 Invocable spatial data services category' - Chapter describes only invocable sds category metadata element.

2015-10-16 Ine: All SDS is moved to chapter 2.14 in version 0.55

it has now seperate chapters

43 Peter Kochmann all whole document Ge Marc raised a general problem in #16, #23 and #24: Since concerning spatial data services as well, the term "service" is no longer sufficient.

change old term "service" to "network service" if it aims on this only;

use "all services (network services and other discoverable spatial data services as well)" when aiming at every service

2015-09-01 (Michael Ö): According to the latest version of the document "Spatial data services - a discussion paper" (Version 0.7.1_MIG-T (26-08-2015) 
) All services shoudl be called Spatial data services.
The are split into
-Network services
-Other spatial data services
44 Angelo Quaglia (JRC) 2.2.6 (Coupled Resource) Paragraph Ge

The Metadata Regulation requires service metadata to include the metadata elements identifying the coupled datasets, if present:


1.6.  Coupled resource
If the resource is a spatial data service, this metadata element identifies, where relevant, the target spatial data set(s) of the service through their unique resource identifiers (URI).
The value domain of this metadata element is a mandatory character string code, generally assigned by the data owner, and a character string namespace uniquely identifying the context of the identifier code (for example, thedata owner).


In ISO 19139 this is done either including the MD_DataIdentification element inside each srv:operatesOn, e.g.:




or using the linking elements described in ISO 19118 - C.2.5 Linking element.


In this case we are not linking a dataset object but its metadata file.


Therefore, we have to use the href attribute, for example:


<srv:operatesOn xlink:href="http://image2000.jrc.it/metadata/file1234.xml



The link points to the MD_DataIdentification element found in the metadata of the coupled dataset:


      <gmd:MD_DataIdentification id="image2000_1_nl2_multi">


From ISO 19118 - C.2.5 Linking element:

A remote resource is identified by a text string called a locator. A locator value may contain either a Uniform Resource Identifier (URI) or a fragment identifier, or both. The syntax of a locator is first the URI,
followed by a connector ("#" or "|") and a fragment identifier. The URI describes a remote resource, and the fragment identifier describes a sub-resource within that resource. A fragment identifier pointing into an XML
document must be an Xpointer [8]. If the connector is "#", this signals that the remote resource is to be fetched as a whole, and that the XPointer processing to extract the sub-resource is to be performed on the client. If the connector is "|", no intent is signalled as to what processing model is to be used for accessing the designated resource


Once the client has extracted the sub-resource, the service metadata contains the required MD_DataIdentification element, therefore complying with ISO and INSPIRE requirements.


Note: Member States using the centralized scenario might want to ensure that href links actually point to the National Discovery Service as opposed to local Discovery Services.



The proposed approach using uuidref, potentially useful for the case when a provider is unwilling or unable to sustain the load of requests coming from clients trying to resolve the links to metadata, appears to have been conceived, in ISO 19118, to point to spatial objects inside a dataset data file rather than to fragments inside the dataset metadata:


From ISO 19118 - A.5.5.2 Object reference


The “uuidref” attribute shall be used to refer to an object within the universe of an application domain. A name server may be used to resolve “uuid” values. The “uuref” attribute shall be used to refer to objects that are located in other datasets using the syntax of the uniform resource identifier (URI) defined by [5].


However, it is syntactically allowed by the ISO 19139 schema.


In any case, the application domain needs to be explicitely defined. Object identification
Objects may be assigned identifiers that allow them to be uniquely identified within a particular context. Two different contexts should be considered.
b) The second context is an application domain. An application domain defines a universe and an identification scheme called universal unique identifiers (UUIDs). A UUID is assigned to an object when it is created and is stable over the entire life span of the object. A UUID of a deleted object cannot be used again. UUIDs are required for long-term distributed data management and for realizing update
mechanisms. These identifiers are also called persistent identifiers. A special name server may be used to resolve persistent identifiers. The identifiers are unique within a well-defined limited universe defined by
an application domain.


A client of the INSPIRE Geoportal reading a metadata file would not know, just looking inside the metadata file, from which National Discovery Service the metadata comes from.



Keep the existing xlink:href solution as mandatory while making the uuidref based one optional.

However, the intended application domain, as required by ISO 19118. STILL NEEDS TO BE DEFINED.

Then, it can be stated that if uuidref is present, clients shall not resolve the href URL, rather they shall use the uuidref value to identify the dataset metadata inside the agreed application domain.



Include the following remark:

Member States using the centralized scenario might want to ensure that href links actually point to the National Discovery Service as opposed to local Discovery Services.

45 Angelo Quaglia (JRC) (Resource Locator) + 1.3.3 Paragraph Ge

The use of the gmd:description element instead of the previously proposed gmd:function seems a bit of a stretch as gmd:description is supposed to contain a "detailed text description of what the online resource is/does".


The use of the gmd:function element should be considered also for datasets and series.



Keep gmd:function and extend the ISO codelist


For Spatial Data Services an example is needed for each function code.

2015-10-16:we have not done that because don't want to change ISO 19115 codelist

Angelo Quaglia (JRC)


2.8.3 (Conformity),

2.4 (Keywords)

All document Te

The example about expressing conformity of a SDS:


   <gmd:specification xlink:href="http://inspire.ec.europa.eu/conformanceClass/MD/1.4/SDS_Invocable">


Implies the use of ISO 19118 - C.2.5 Linking element as explained in item 44 above.

This implies that the registry (likely the codelist register) returns a predefined XML fragment, compliant with ISO 19139.

This is a good approach but the work on the registry needs to be done.

The same approach needs to be followed to specify the keyword Thesaurus, the limitations to public access.


Instead, the proposed use of gmx:Anchor for the title of a specification is not advisable:



            <gco:CharacterString>Žem?s paviršius (INSPIRE perži?ros paslauga)</gco:CharacterString>
                    <gmd:CI_DateTypeCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#

CI_DateTypeCode" codeListValue="publication" codeSpace="ISOTC211/19115">publication</gmd:CI_DateTypeCode>


The title element is nested too deep inside CI_Citation and does not comprise the citation date which is always required


Adopt linking predefined xml fragments where appropriate.


Remove the gmx:Anchor example and suggestion.

2015-08-30 (Michael Ö): Can some put some light on how documenting with a fragment like below works in practice. I have little practical experience of it.
  <gmd:specification xlink:href="http://inspire.ec.europa.eu/conformanceClass/MD/1.4/SDS_Invocable">

When will an Xlink resolver update this into the XML.
- Before it is harvested into INSPIRE Geoportal ?
- When it is harvested into INSPIRE Geoportal (by the INSPIRE Geoportal)

- When metadata is viewed in INSPIRE Geoportal.


Does the use xlink:href put any demand on members states to have a xlink resolver into their catalog? (Maybe all have this like Geonetwork ?)

Using the xlink:href like here is a way to link to XML-fragment containing the full specification.
If instead a gmx:Anchor is used I could see the possibility to have a link to a URL in registry not only storing the xml-fragment but instead describing the referenced object further.  Like for the categories for SDS  levels Invocable, Interoperable and Harmonized the URL that the Anchor points to could actually describe what each level means besides having the Citation. Just an idea.


Angelo Quaglia (JRC)


2.13 (Theme Specific Metadata elements) Parapgraph   The copy/paste of detailed theme specific information from Data Specification TGs does not look helpful and adds a maintenance burden. Replace the copied information with accurate reference to the original Technical Guidance documents.

2015-08-26 (Peter): You may be right concerning the comments in several tables only where further descriptions are taken from data specifications. All other content (reference, definition, domain etc.) can't be referenced itself because it will become unreadable or is even different from data specification where we decided to consider other elements than proposed by data specifications.


2015-08-27 (Michael Lutz): @Peter: I strongly disagree - we cannot have competing/contradicting guidelines!! If the group is proposing changes to the current guidance given in the data specifications for the "metadata elements for interoperability", these should be formulated as change requests, and it should be clearly argued why the change is deemed necessary.


Then, once a change has been agreed (or not), we need to have a discussion where to best maintain this information (in one place). Be aware that especially the theme-specific recommendations for how to fill specific MD elements (e.g. keywords or lineage) will need to be maintained by the thematic communities.


2015-08-28 (Peter): O.k., of course I'm not going to maintain the TG without documenting the changes. In some issues we came clear that the statements in data specifications are not in line with the meaning documented in ISO for a particular element or the way we understand the intention of IR for a metadata information abstractly given there. What do we have to do to initiate such a change request?


2015-08-27 (Antonio): In my opinion, requirements and recommendations on the INSPIRE metadata elements should only be described in Metadata TG, the more so because in the revised document of Metadata TG, which we are working, we are also integrating requirements and recommendations on metadata elements for interoperability and on recommended theme-specific metadata elements (so far contained in DS). That would avoid to update both documents in case of changes. So, in chapter 8 of DS only the lists of all required metadata elements with minimal information about them (like the table 4 in clause 8.1) could be kept.


2015-08-30 (Michael Ö): The way I have seen this is that we have implementation instructions on metadata on several places that currently lead to confusion. If each thematic community should define the technical details of implementations we will end up with stove-pipe like implementations of metadata that will reduce interoperability. I agree with Peter and Antonio that TG Metadata should contain the technical details of implementation.  Then each DS can specify e.g. How shall a lineage text be written, or Process sfteps what should be expressed in description and rationale. But the technical part should be kept in one place.
I have during our work raised the question that changes now suggested will influence other specifications.
This is an important task how these changes could be accepted and managed.

It would be good when new elements that are needed for the thematic areas are first discussed within the the group of metadata experts so that a common agreement on their implementation is done first before they are inserted into new releases of Data Specifications.


2015-09-10 (Peter): considered in maintained draft 05 as discussed in Malmö: now in an abstract way without naming particular annex themes (to be done in a separate document)

48 Freddy Fierens (JRC) 8:25-35 Paragraph Ed The description related to the metadata for interoperability misses some context, e.g. how are these MD to be provided or where can they be found (part of the MD for discovery, when downloading a dataset, separate from datasets, …)?    
49 Freddy Fierens (JRC) Annexes Annex Ed How to handle the ATS that are being developed, annex to the TG, referenced, ...?    
50 Freddy Fierens (JRC) 2.9 Constraints related to access and use Te AAA protected access: elements specifying for a service what AAA protocol is to be expected and used for access would be useful here.    
51 Peter Kochmann 1.3 17: 47 Ge

The more I look at this chapter the more I don't understand what it is for...

Why are the listed issues "spatial data service type" (1.3.1) and "classification of spatial data services" (1.3.2) extensions at all? Both concerned ISO elements (serviceType and keyword) are designated for free text. So there is no limited content to be extended.

We decided to avoid structural extensions to ISO when integrating metadata on SDS. When using function for the SDS resource locator function this would have been the first real extension to an existing codelist! But we're going to have a separate element (description) for this. No extension at all again.

Or does "Extensions" mean extensions on ISO core (1.1)? Then we would have to add many elements listed in 2.12 and 2.13 now ...

  2015-08-26 (Antonio): Annex C (normative) in ISO 19115, providing the rules for defining metadata extentions and profiles, lists the allowed types of extensions. Even creating a new metadata codelist to replace the domain of an existing metadata element that has "free text" as its domain value is a type of extension (see C.2(2)). So, the chapter makes sense.
52 Peter Kochmann 2.14 116: 1 Ge Didn't we discuss to have a table giving an overview of necessary elements for SDS? Especially when spreading out these elements to different issues in the document where the particular element already has been documented for another context this is very important! Otherwise a chapter 2.14 for the remaining elements doesn't make sense because the reader can come to the conclusion "that's all I have to do for SDS"!  

2015-08-26 (Antonio): I agree; it could be very useful!


2015-08-27 (Michael Lutz): I think this is raising a wider issue. Currently the TGs are structured according to the structure in the IRs, i.e. element by element, no matter whether they are applicable for data sets, services or invocable SDS. For someone having to provide metadata for either one of those categories, they would probably much prefer to have a simple list of instructions saying: for data sets, you have to do A, B, C, ...; for (network) services you have to do X, Y, Z, ... Probably, this would mean duplicating (or referencing content), but I think we should discuss how this best could be done in the document.


2015-08-27 (Peter): That's exactly the point why I still prefer to have separate chapters 2.12 for interoperability only, 2.13 for theme-specfic elements only and 2.14 for SDS only! As can be seen e.g. in we didn't integrate the requirements for metadata on SDS at all but we built up a new chapter for the additional use of this element for SDS. Why not have it in 2.14.x?. And the headline of 2.12 "Metadata elements for interoperability" doesn't suit well any longer since having integrated SDS in 2.12.1. I propose to go back to a full chapter 2.14 with specific information on the SDS purpose but also links to existing other chapters when touching an element already considered in another context!


2015-08-27 (Antonio): in Italy we have a specific metadata guidelines for each resource type (one for dataset and series and one for services). So, if somebody needs to document dataset or series, he can follow the instructions given in the metadata guidelines about those resources; in case of services, the other guidelines can be used. That could be a good solution also for our work, I think: a document for dataset and series, another one for network services and another one for SDS or, alternatively, a document with three sections, one for each category.


2015-10-16 Ine: All SDS is moved to chapter 2.14 in version 0.55

53 Michael Lutz general   Te

I think we should describe somewhere in the document a consistent approach of referring to externally defined "information items" (e.g. in the INSPIRE registry). In particular, we should clarify, when/how to use anchors and when/how to use xlink:href's.

Add a section in the beginning of the document clarifying the consistent approach for referring to externally defined information items, and use it consistently across the document.  
54 Peter Kochmann



61: 21

56: 26


I looked up the corresponding ticket but couldn't find the answer: Why did we decide to take DQ_DomainConsistency for that?

TG Requirement 30 (2.8) names Metadata Regulation Part D 5 as the source for this type of quality statement. But I can't find it in 1205/2008! Can anyone help?


2015-08-28 (Antonio): the first sentence in TG Requirement 30 seems to me being incomplete and having nothing to do with the choice of DQ_DomainConsistency for documenting the conformity to the INSPIRE specifications, since the part D.5 in Metadata Regulation only defines the values for the degree of conformity


2015-08-31 (Michael Ö): I think this DQ_Element was originally  selected as the least incorrect of all DQ_Elements that exists. And for reporting Category we just resused the same. A more pedagogic way would have been to add a new DQ_Element like DQ_SpecificationConformance but then other issues would have arised.


IdV 16-10-2015: I removed the first sentence of TG requirement 30 in version 0.55

55 Antonio Rotundo 1.3   Ed On the base of my response to the comment #51, we have to add a description of every codelist defined by the WG in the draft and not given in ISO 19115 representing some extensions (LimitationsOnPublicAccess defined in 2.9.1 for instance). Add a description of every codelist defined by WG in the draft and not given in ISO 19115. 2015-08-31 (Michael Ö) Suggest add this as Annex A 13
56 Michael Östling general   Ed The current list of Requirements in the Technical Guidelines are hard to trace to IR and makes it hard to generate ATS testcases. A suggestion from MIWP-5 is to rewrite the requirements and clearly state what is coming from IR and ISO 19115/ISO 19139 respective. Also the tables containing requirements on xpath, mutiplicity and codelist should be directly used as requirements. An inital work on this have been done by Michael L and we should dicuss these principles in Malmoe. A zipfile is attached (requirementChanges.zip) containing a Excelfile listing IR reqs and analyzing TG reqs, included in zip is also an update of the existing TG Metadata version 1.3 is also edited (Up to section Resource Identifier) with the above principles to show how it could be written. Discuss and Work futher on this Malmoe. 2015-09-03 (Michael L) I attached a PDF version of the Word document illustrating the proposed requirements changes (only the first 26 pages, I didn't make any changes after that...) to this page: MD_IR_and_ISO_20131029_proposal_cleaner_requirements_p.1-26.pdf
57 Michael Östling Annex A 12 A.12.4   Add example metadata for Other Spatial Data Services as A.12.4. Consider also in addition to place all XML-files in GIT-HUB as suggested by Martin.    
58 Michael Östling 2.12.3     The encoding section is changed in relation to how it was used in TGs.
We use this element to purely specify the format. The application-schema is not seen as an encoding.  So Application schema needs to be documented elsewhere.
It does exists a class for this in ISO 19115 that was defined as optional elements in previous versions of Dataspecifications
Add element Application Schema OR revert our modification of Encoding. To Discuss in Malmoe 2015-09-10 (Peter): considered in maintained draft 05: now there is a recommendation in 2.12.3 to document the supported data scheme either in conformity statement (2.8) or the maybe existing metadata element applicationSchemaInfo

proposal_LoPA_CAAU_md.docx (38.9 KB) Antonio Rotundo, 24 Jul 2015 05:44 pm

topoExample-quantitativeResult.doc (84 KB) Eliane Roos, 07 Aug 2015 02:47 pm

Eliane_position_constraint.docx (34.8 KB) Eliane Roos, 07 Aug 2015 04:20 pm

proposal_LoPA_CAAU_md_20150826.docx (53.3 KB) Antonio Rotundo, 26 Aug 2015 06:24 pm

TG_MD_IR_and_ISO_MIWP8_draft_v.04_maintained_PK_2015-08-20.doc - 2.12 and 2.13 maintained concerning #6 - #10 and #39 (2.34 MB) Peter Kochmann, 28 Aug 2015 10:02 am

RequirementChanges.zip - Draft discussion document on requirement changes (469 KB) Michael Östling, 31 Aug 2015 01:40 pm

MD_IR_and_ISO_20131029_proposal_cleaner_requirements_p.1-26.pdf - Illustration of how requirements could be reworded in TGs to make them more consistent with IRs (1020 KB) Michael Lutz, 03 Sep 2015 07:00 pm