Draft version of Technical Guidelines Metadata v.01

Updated 2015-03-25

The document can be reached here

This draft contains updated sections in document for

2.2.5 Unique resource identifier
2.3.6 Coupled resource
2.12  Metadata for interoperability

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.

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

ID Comment by Clause/
Line No Type Comment___________________ Proposed solution________________ Comments______________________________________________
1 Martin Seiler 2.2.6 915-1005 Te/Ge Its not very obvious what the xml-attribut 'uuidref' (it does not need to be a uuid). Actually uuids are not UIRs as they are missing the prefix.

- add a note (e.g. a footnote) to clarify that this is not necessarily a uuid, but a URI.


- choose a different example (not a uuid), but a proper URI, e.g. a URL, to demonstrate the usage of the field.

EDIT: 2015-04-16 (Martin) Sorry, I messed up here with my earlier comment. 

I'm not sure if the requirement for a URI is correct. Check my comment on ID 19 below. I have anyhow used same example for Resource Identfier as is used in section 2.2.5 /Michael Ö


2 Martin Seiler          

EDIT: 2015-04-16 (Martin) - deleted.

3 Peter Kochmann 2.12 2262 / 2282 / 2285 Ed the examples given for code and codeSpace (though it's optional!) in the table should fit to the XML snippet

take a more common reference system (e.g. 4258) and have it in the table and the XML snippet as well

2015-05-20 (Peter): done for next draft (03)
4 Peter Kochmann 2.12.2 2296 Ge

concerning the comment: As I see it the difference between referenceSystemIdentifier (187) and RS_ReferenceSystem (195) is not the specified use for temporal reference but the chance to have an extent with it. Both ways lead to RS_Identifier which can be directly used for temporal reference as well! The problem will be: Is there an identifier for temporal systems at all?

5 Peter Kochmann 2.12.2 2296 / 2327 / 2334 Ed

the examples given for code and codeSpace (and authority, though both are optional!) in the table should fit to the XML snippet.

Furthermore I assume that this example won't be helpful because "Gregorian calendar" is on of the two which are outside this condition!

no idea; what are other temporal reference systems the condition applies for? 2015-05-20 (Peter): done for next draft (03)
6 Peter Kochmann 2.12.3 2348 Ed/Ge

referred to ISO we have to consider the mandatory elements name and version. Furthermore we agreed on skipping specification (it's optional and the use documented in data specification is inappropriate). The two elements named above should be named in the table (entry "Domain").

As an alternative we can point to the INSPIRE registry for codelists and recommend a use of it (do we need a gmx:anchor-element here?)



name: free text

version: free text


alternative solution: instead of free text in element name make use of http://inspire.ec.europa.eu/media-types/

EDIT: 2015-05-06 (Peter) - done for next draft.

Maybe we can have an additional comment about the chance to put application scheme to another (designated) element?


2015-05-20 (Peter): comment added in draft 03

7 Peter Kochmann 2.12.3 2375-2381 Ed I remember we agreed on not considering the data specification in context of encoding here and skipping the element specification. So the example in the XML snippet is needless.   EDIT: 2015-05-06 (Peter) - done for next draft.
8 Peter Kochmann 2.12 2259 Ed Coordinate reference system doesn't have a classification number. 2.12.1 Coordinate reference system EDIT: 2015-05-06 (Peter) - done for next draft.
9 Peter Kochmann 2.12 2262, 2296, 2348, 2427, 2468, Ge/Ed with the exception of 2.12.4 (line 2393) INSPIRE multiplicity is always given without focussing on dataset and series. I think we need this detailed definition because the metadata for interoperability apply to dataset and series only!

INSPIRE multiplicity:

... for dataset and dataset series

EDIT: 2015-05-06 (Peter) - done for next draft.
10 Peter Kochmann 2.12.5 2427 Te/Ed

XPath for spatialRepresentationType could be adjusted to the one in 2.12.4 (line 2393). I'm not sure if the current one works.

identificationInfo[1]/*/spatialRepresentationType EDIT: 2015-05-06 (Peter) - done for next draft.
11 Peter Kochmann 2.12.3, 2.12.4 2348, 2393 Ed Commission Regulation... contains point 1 in addition. point 1 doesn't fit here.

for line 2348:

COMMISSION REGULATION (EU) No 1089/2010, article 13, point 3

for line 2393:

COMMISSION REGULATION (EU) No 1089/2010, article 13, point 4

EDIT: 2015-05-06 (Peter) - done for next draft.
12 Peter Kochmann 2.12.5 2427 Ed the citation of the amendment to 1089/2010 is difficult to understand COMMISSION REGULATION (EU) No 1089/2010, article 13, point 6 (element added by amendment 1253/2013) EDIT: 2015-05-06 (Peter) - done for next draft.
13 Peter Kochmann 2.12.6 2468 Ed in contrast to the other chapters the reference is given not that precise COMMISSION REGULATION (EU) No 1089/2010, article 13, point 5 EDIT: 2015-05-06 (Peter) - done for next draft.
14 Antonio Rotundo 2.12 2262/ 2282 Te DS TG Requirement 2 states that a URI identifier listed in the provided table shall be used for referring to the CRS. So, the domain has to refer to the list provided in TG Requirement 2. take a URI identifier by the list provided in DS TG requirement 2 and have it in the table and the XML snippet as well (e.g. code: http://www.opengis.net/def/crs/EPSG/0/4258). Besides, in the field "domain" in the table refer to the above mentioned URI identifiers list. 2015-05-20 (Peter): done for next draft (03)
15 Antonio Rotundo 2.12 2262 Ed/Te The element codeSpace is optional, but that is not clear in the table. Besides, if the code is given referring to the list provided in DS TG Requirement 2 (see previous comment 14), then the element codespace could be skipped. In the field "example" in the table specify that the element "codeSpace" is optional and that it could be skipped if the code is given referring to the list provided in DS TG Requirement 2. 2015-05-20 (Peter): done for next draft (03)
16 Antonio Rotundo 2.12 2262 / 2282 Ed the example given for codeSpace in the table should fit to the XML snippet. have in the table the same value as the XML snippet for the element codeSpace. 2015-05-20 (Peter): done for next draft (03)
17  Antonio Rotundo 2.12.2 2296 / 2299 Ed/Te Temporal reference system should be encoded similarly to the coordinate reference system. So, only the elements "code" and "codespace" (optional) should be considered and the elements "authority" and "version" should be skipped. Add a specific requirement on code property as previous TG Requirement 41 (see line 2269); in the example in the table delete the elements "authority" and "version"  and specify that the element "codespace" is optional. 2015-05-20 (Peter): done for next draft (03)
18 Peter Kochmann 2.12.6 2468 Ge Before we haven't finished the discussion on how to place the descriptive results I think it's non-practical to maintain this draft concerning 2.12.6. Antonio raised a new suggestion (measureDescription instead of lineage) in the last entry in the ticket #2214 (before it was closed) that has to be discussed.

I still prefer using lineage for descriptive results and suggest to document a reference to the lineage element in 2.7.1 that has to be filled anyway.

Using the element measureDescription raises the new problem how to fill the mandatory DQ_Result.

I'm agree with the first part of the comment. It's necessary give more details on this element after the discussion.
Concerning the lineage element, I repeat what I wrote in the ticket #2214: the element is already included in the INSPIRE metadata set; about it, the TG Requirement 26 states that there must be one lineage element and TG Recommendation 16 suggests to use it to evaluate and report the results concerning specific data quality elements and measures .
For this reason, if we'll decide to consider it, we could use that element for reporting descriptive elements of topological consistency as suggested by Peter but without adding it in the specific section of metadata for interoperability, adding only specific recommendations instead (Antonio Rotundo)


But I assume we have to flag it here. Anyone who is looking up the metadata elements for interoperability needs to know where to put the information. That's the reason why we decided to have the 2.12.x and 2.13.x chapters and not have a mixture with the elements already used before (Peter Kochmann).

19 Pawel Soczewski 2.2.6



Ed/Te According B1.5 and B1.6 Metadata IR (1205/2008) unique resource identifiers should be URI. 
In the examples of XML encoding UUID is used. It should fit to the URI.
for line 952:
"resource identifier = "http://rdsi.jrc.ec.europa.eu/id/dataset/ccm2.1/lakes"
and continue in all examples of XML encoding
In my opinion its not so clear what should be set here.
I do agree that a URL is better suited for an identifier. But I think there is confusion of terminology in the regulation for metadata. In the description of coupled resources it is referring to the UNIQUE Resource Identifier with the acronym URI.  As I understand this is just a short name for the metadata element. It's not meant to define the type to URI (UNIFORM Resource Identifier).  Actually the definition of the element Unique Resource Identifier is a mandatory character string and ( as I understand it ) an optional namespace. (Or is the word Mandatory refering to both Code and CodeSpace) The previous version of TG Metadata have interprated the codespace as optional (If a value for codeSpace is provided...).

So a UUID is I think ok accordning to regulation. There is a separate subtask related to persitant identifiers. Maybe we should wait for the outcome of that before we mandate URIs or URLs .
Can we recommend a URI but not mandate it so that a characterstring is (eg a UUID) would be ok also ?
20 Pawel Soczewski 2.2.6 947/978 Ed/Te

The examples with GetRecords request don't point to the metadata record for the dataset. In filter 'operatesOn' parameter is used and it refers to himself - the metadata record for the service.  The filtering criteria should contain 'resource id' parameter.

Additionally, in order to achieve consistency with the TG MD I propose the following request's parameter values:

for line 947 and 978 and 




CONSTRAINT_LANGUAGE_VERSION=1.1.0&CONSTRAINT=ResourceIdentifier like 'http://rdsi.jrc.ec.europa.eu/id/dataset/ccm2.1/lakes'

Correct, I have updated based on this.
I'm still though waiting to replace the character string with the URL after we have had a discussion on it on thursday.
21 Antonio Rotundo 2.12.6 2465/2548 Te

ISO Standard 19138 provides the (mandatory, optional and conditional) components defining a data quality measure and also provides a mapping of those components to ISO 19115. The mandatory and some conditional components are (in brackets the corrisponding element of ISO 19115 as mapped by ISO 19138): name (nameOfMeasure), data quality entity (DQ_Element), data quality sub element (DQ_TopologicalConsistency), definition, description (conditional, corrisponding to measureDescription), data quality value type (no corrisponding elements, but I think that we could use result elements), identifier (conditional, corrisponding to measureIdentification).
ISO 19138 also provides what are the data quality basic measures.

I think that we should use only the mandatory elements and some conditional elements required by ISO 19138, i.e.:
name (nameOfMeasure);
definition - description (measureDescription);
data quality value type (result: value and valueUnit);
identifier (measureIdentification).

After the discussion:
- complete the table with missing information and the subclause with appropriate requirements and recommendations;
- replace the XML examples with an example that fits to the metadata elements we'll decide to consider.


On the base of my proposal, the XML example could be the following (to be completed with values):





2015-05-20 (Peter): considered for next draft (03) as far as possible. But we do not make use of measureDescription (102) for the descriptive results but use lineage instead. The element measureDescription doesn't aim at the result but the measurement itself. So it's not suitable here.
22 Javier Nogueas, Alejandra Sánchez 2.12 2262 Te/Ed

In the technical guidelines of INSPIRE data specifications, there is a list of URIs to be used for default coordinate reference systems. 

This new version of technical guidelines for metadata should include also this list of URIs, or at least refer to the ones proposed in the data specification technical guidelines.

Include "Table 
2:http URIs for the default coordinate reference systems" (page 54) of technical guidelines of data specifications on addresses http://inspire.ec.europa.eu/documents/Data_Specifications/INSPIRE_DataSpecification_AD_v3.1.pdf (the same table is included in other data specifications).
2015-05-20 (Peter): done for next draft (03)
23 Javier Nogueras, Alejandra Sánchez A.12.1.1 / A.12.1.2 3137 /3145 Te/Ed The example of dataset metadata should be updated to include mandatory interoperability elements such as "Spatial representation type" Update the examples shown as INSPIRE view or as an ISO/TS 19139 XML file We suggest to move example files to an exertnal source and just put a link to a repository here as reference. See also comment #29 in v2.
24 Peter Kochmann 2.6.2, 2.6.3, 2.6.4 1435, 1480, 1520 Ed While looking up a different issue I discovered that the given element for entry "ISO 19115 number and name" must be wrong: There's no date at 392! It has to be 362 instead. 362. date shifted to new Ticket #2434