Draft version of Technical Guidelines Metadata v.01¶
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
|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.
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)|
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)|
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!||
... for dataset and dataset series
|EDIT: 2015-05-06 (Peter) - done for next draft.|
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/*/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.
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).
|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 ?
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.
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).
I think that we should use only the mandatory elements and some conditional elements required by ISO 19138, i.e.:
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.
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|