MIG temporary sub-group (MIWG-8) on update TG … · Web viewTG Requirement 6 suggests to use RS_identifier for the encoding of the resource identifier. This is a poor choice as it

INSPIREInfrastructure for Spatial Information in Europe

MIG temporary sub-group on Update of the Technical Guidelines for Metadata – Reading guidelines for draft document version 0.4

2015-08-02

1

BackgroundDuring consultation with EU member states on issues working on Implementation and maintenance of Inspire metadata, a number of issues have been identified that need to be reviewed and possible updates in the technical guidelines made.

Example of these issues are:

A number of issues has been raised for the Metadata TG (e.g. issues concerning the metadata element useLimitation) that were not been fixed with the last update of the Metadata TG1.

The guidelines for metadata for interoperability (aka metadata for evaluation and use) are currently contained in the data specifications rather than integrated in the Metadata TG.

The quality of the metadata harvested by the INSPIRE geoportal from the national discovery services is often quite poor, even if they are formally meeting the requirements of the metadata IRs.

The revised versions of the ISO standards on metadata needs to be addressed to give security in planning. Many implementations are based on the existing standards. Re-building these implementations would require an enormous amount of re-investment.

An analysis of metadata, which is created now with significant effort, should be made in order for the metadata to support additional use cases, than just the search for geodata and the allocation of information.

It has been agreed in the MIG-T meeting on 9-10/04/2014 that a sub-group should be formed to propose an update of the INSPIRE Metadata TG.

A draft of the Technical Guidelines for metadata does now exist as version 0.4TBD link

To aid in understanding the changes done in the draft this document with reading instructions is created. For some issues there are different ways to solve the defined issues and there is different opinions in the working group. For these issues we describe alternative solution and would like feedback from the MIG-t members.

References[ISO 19115] EN ISO 19115:2005, Geographic information – Metadata (ISO 19115:2003) [ISO 19119] EN ISO 19119:2005, Geographic information – Services (ISO 19119:2005)

[ISO 19139] CEN ISO/TS 19139:2009, Geographic information - Metadata – XML Schema Implementation (ISO/TS 19139:2007)

[INS SDS] Commission Regulation (EU) No 1089/2010 of 23 November 2010 ImplementingDirective 2007/2/EC of the European Parliament and of the Council as regardsinteroperability of spatial data sets and services

1 http://inspire.ec.europa.eu/documents/Metadata/MD_IR_and_ISO_20131029.pdf

2

http://inspire.ec.europa.eu/documents/Metadata/MD_IR_and_ISO_20131029.pdf

[TG SDS] Technical Guidance for INSPIRE Spatial Data Services and services allowing spatial data services to be invoked, version 3.1

[INS NS] COMMISSION REGULATION (EC) No 976/2009 of 19 October 2009 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards the Network Services

[INS MD] COMMISSION REGULATION (EC) No 1205/2008 of 3 December 2008 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards metadata

[TG MD] INSPIRE Metadata Implementing Rules: Technical Guidelines based on EN ISO 19115 and EN ISO 19119, version 1.3

[INS DIR] DIRECTIVE 2007/2/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 14 March 2007

Update of the Technical Guidelines for MetadataThe update of Technical Guildeines for metadata draft are now available in version 0.4. To be able to proceed we need feedback from member states on the work done so far on the technical decisons made. The draft is not currently not checked for editorial inaccuracies. That will be done when current technical routing are laid finally.

3

Updated issues in draft 0.4The table below shows the issues in the workprogram where updates have been done.

Issue Priority Release

A Conditions for use and Access high A

D Metadata for Interoperability High A

E-1 Integrate theme specific MD high A

I Language neutral identifiers high A

J Metadata for SDS high A

L Unique Resource Identifier high A

M Coupled resource high A

For each issues we describe a number of references . These are to make the description of the work complete. They are not needed to understand this document but is inserted in case this background is needed.

Specification in terms of reference for the work Tickets in redmine where dicussions on the issue have been done Wiki page in redmine where discusson on the issue have been done Chapter reference in draft where the updates are done Discussion: in case there are different solution these are described here or if the draft text

needs some deeper understanding to be useful. Impact: In case the suggested solution have impacts on other technical guidelines or the

infrastructure in general we note it here. Questions. We need feedback on all changes in this draft.

But for some specific issues ask specific questions we need feedback on. These are marked as FEEDDBACK NEEDED:

4

A Constraints applying to access and useWiki page:

https://ies-svn.jrc.ec.europa.eu/projects/metadata/wiki/MIWP-8_(A)_Conditions_applying_to_access_and_use

Ticket in redmine:

https://ies-svn.jrc.ec.europa.eu/issues/2212

Chapter reference in draft:

2.9 Constraints related to Access and use

Specification in terms of reference:Conditions applying to access and use is now implemented in a way not in line with [ISO 19115]. The task is to see what actions should be taken to handle this. How can the TG be updated to create better alignment with [ISO 19115] and at the same time not create too many problems for existing metadata records.The implication if not doing this is that Inspire MD is not compatible with other [ISO 19115] implementations.

Discussion:

The main requirements that be should solve to implements are

Clauses in the Inspire Directive Explanation

Conditions applying to access to, and use

Article 5.2.bMetadata shall include information on the following: conditions applying to access to, and use of, spatial datasets and services and, where applicable, corresponding fees;

Article 11.2.fconditions applying to the access to and use of spatial datasets and services;

These could include Access or Use restrictions or both types restrictions

Limitation to public access

Article 13

By way of derogation from Article 11(1),

This is also a Access-restriction but for a specific target group "The Public"

5




Member States may limit public access to spatial data sets and services through the services referred to in points (b) to (e) of Article 11(1), or to the e-commerce services referred to in Article 14(3), where such access would adversely affect any of the following: e-commerce services referred to in Article 14(3), where such access would adversely affect any of the following:

In short the requirements from the directive is to report on access and use restrictions in general and then if there are specific access restrictions for the public. The main issue how to separate these two restrictions in metadata.

To separate these two requirements the existing Technical Guidelines have implemented the first (Conditions applying to access to, and use) using the element uselimitation which by many implementers of [ISO 19115] have been argued as being a semantically wrong element for reporting Conditions applying to access to, and use. If metadata only would have been used within the Inspire framwork it would be accepted. But when Inspire-resources will be used within other SDIs and in NSDIs it generates implications.In work group MIWP-8 there are different opinions on how this can be solved. In the text below these two technical solutions are described as A and B.Solution A is currently documented in the draft technical guidelines in chapter 2.9.3 and 2.9.4 Solution B is documented below. It is based on current technical guidelines but with minor adjustments.Feedback needed

The alternatives below describes two approaches to handle the required element Constraints applying to access and use. Feedback is needed on the suggested way forward.

Please select one of the following options:[__] Preference for approach A (but approach B would also be acceptable)[__] Strong preference for approach A (approach B should be avoided)[__] Preference for approach B (but approach A would also be acceptable)[__] Strong preference for approach B (approach A should be avoided)

Please provide comments on your choice (in particular if you think one of the options should be avoided):

……………………………………………………………………………………………..

……………………………………………………………………………………………..

Approach A.

Adding a mandatory Anchor referring to the Inspire registry.

6

This solution implements both

Conditions applying to access and useandLimitation to public access

Using the general class MD_LegalConstraints

What separates the general information on:

Conditions applying to access and use and

Limitation to public access.

Is that for Limitation to public access the element otherConstraints must point to a defined code list (LimitationsOnPublicAcess) in the Inspire registry. (This code list I still to be created)

Using this principle a metadata record can have multiple instances of MD_LegalConstraints but only one instance pointing to the specific codelist in Inspire registry “LimitationsOnPublicAccess” is Limitations on Public access. All other instances are describing general Conditions applying to access and use

For reporting Conditions applying to access and use the information shall be documented either with

MD_LegalConstraints for legal access and use constraints. MD_Constraints/useLimitation for technical access and use constraints

Use of an anchor for the fixed cases defined for Conditions applying to access and use

We also recommend the use of an anchor for the fixed cases defined in implementing rules like

no conditions apply

7

conditions unknown.

These are currently free text, which makes this value hard to query in the Inspire Geoportal since each national translation to other languages can differ.

E.g. the Finnish value for "no conditions apply" is translated to “No restrictions”.The Swedish value is translated to “No applicable conditions”

A possible registration of no conditions apply could then refer to the inspire registry.For a record with metadata in English<gmx:Anchor xlink:href="http://inspire.jrc.ec.europa.eu/metadata-codelist/ConditionsAccessAndUse/noConditionsApply"> no conditions apply </gmx:Anchor>

For a record with metadata in Swedish<gmx:Anchor xlink:href="http://inspire.jrc.ec.europa.eu/metadata-codelist/ConditionsAccessAndUse/noConditionsApply">inga tillämpliga villkor</gmx:Anchor>

The above solutions using an Anchor could instead be solved with fixed code lists to use for the free text fields. However, with this solution we will still have problems with the multilingual queries since each member state will use their own national translation.

The advantage with the solution A is that the implementation will use the elements defined by [ISO 19115] and will avoid the semantic conflict of the elements used in current implementation.The Anchor element will make multilingual queries for the fixed values easier.

The drawback is that metadata have to be rewritten for many records.Catalogue services have to separate the two types of restrictions that can be handled in otherRestrictions element. The Technical Guidelines for Discovery services have to be updated to handle this.

Approach B

Solution B describes an alternate approach for implementing Constraints applying to access and use

This solution is what currently is implemented in the [TG MD] “conditions applying to access and use”

Arguments for this solution:

We keep all information in free text fields This is what organisations already have implemented within the Inspire community It could be argued that element useLimitation could also be used for reporting fees on data

since a fee could also limit the use of data. It could be argued that instead of using the element MD_Constraint/useLimitation a

recommendation should be to use MD_LegalConstraint/useLimitation making it a legal

8

useLimitation. This is technically correct according to ISO 19139 and some also suggest it is semantically correct.

In some cases the Constraints applying to access and use could be a technical constraint (for example in case of a service : only 500 access simulaneously) so there are occasions where the useLimitation should be used.

Arguments against this solution

Some argue that the interpretation of the element useLimitation is that this should only be used for describing “limitation affecting the fitness for use of the resource or metadata” and that the existing Inspire-implementation is semanticaly wrong. This was the reason for adding this issue into the ToR.

It is according to the UML for ISO 19115 tecnically correct to report a useLimitation using MD_LegalConstraint/useLimitation. But not all agree that this would change definition of element useLimitation to also include legal aspects of restrictions. Instead it is agreed that the element is semantically wrong if used so.

D Integrate metadata for interoperability into the Metadata TG.Wiki page:

https://ies-svn.jrc.ec.europa.eu/projects/metadata/wiki/MIWP-8_(D)_Integrate_metadata_for_interoperability_into_the_Metadata_TG

Ticket in redmine:









2.12 Metadata for interoperability

Specification in terms of reference:

The task is to describe in the TG how to handle these metadata elements.

It is important that these elements are clearly flagged as special type of metadata mainly for machine consumption.

9








Discussion:

These elements have previously been documented in each instance of data specifications guidelines.

Now these elements have been merged into the text of Technical guidelines. Below are elements listed that are changed in relation to how they where specified in the data specifications.

2.12.1 Coordinate reference system

Because of TG Requirement 2 in chapter 6 of every data specification, we decided to have a new domain and example considering the list given in context of the above-mentioned requirement.

2.12.2 Temporal reference system

The example in data specifications was not suiting well because “Gregorian Calendar” is exactly the condition for not needing this metadata element. Therefore, we decided to have a divergent example.

2.12.3 Encoding

The focus of this element is the “technical” encoding of the file, not the “logical” structure of the content. Therefore, we did not follow the data specification and skipped the given example for the specification element. The information given there (citing the corresponding data specification) is bound to be documented in the conformity statement instead.

2.12.6 Topological Consistency

--- See 2.13.11, the system of mapping is the same ---

Impact:

Questions:

E-1 Integrate Theme specific metadataTicket in redmine:


Wiki page:

https://ies-svn.jrc.ec.europa.eu/projects/metadata/wiki/MIWP-8_(E-1)_Integrate_Theme_specific_metadata


2.13 Theme specific metadata

10





Right now there are number of optional metadata elements spread out over a number of INSPIRE Data Specifications.

The metadata TG will be updated to include those “optional” metadata elements within and updated TG because some data providers are producing theme specific data services already. This will allow those organizations that wish to use the optional elements to have appropriate 19115 elements in the metadata for this purpose.

Discussion:

The sections below describe some sections that needs clarifications on decisions made when describing the elements.

Maintenance information

To keep it simple we decided to concentrate on ISO where only maintenanceAndUpdateFrequency (143) is mandatory (“should be used”). The accompanying elements updateScope (146) and maintenanceNote (148) are flagged as optional.

2.13.7 Image description

ISO demands two mandatory elements in MD_ImageDescription: 240. attributeDescription and 241. contentType. Both have not been mentioned in data specifications by now but have been considered in draft TG now.

2.13.8 Content information

ISO demands two mandatory elements in MD_FeatureCatalogueDescription: 236. includedWithDataset and 238. featureCatalogueCitation. Both have not been mentioned in data specifications by now but have been considered in draft TG now.

2.13.9 Digital transfer options information

Data specifications on INSPIRE themes Elevation, Orthoimagery and Hydrography recommend different elements (optional in ISO) to be considered within MD_DigitalTransferOptions. All of them are merged together in TG but flagged concerning their source in data specifications.

2.13.11 Data Quality – several issues

There are different issues of data quality named in chapters 8.3.2 of INSPIRE Data specifications. The description of “Metadata elements for reporting data Quality” there is based on ISO 19157, which provides different ways to report data quality information. INSPIRE Data specifications make use of two ways: reporting quantitative results and reporting descriptive results. ISO 19157 itself works along with metadata structures according to ISO 19115-1.

As long as being based on ISO 19115 only a mapping of the metadata elements designated in ISO 19157 to metadata elements existing in ISO 19115 is necessary:

- For quantitative results there is an equivalent structure in ISO 19115, so the mapping is obvious. Following ISO 19115 there is an element to be considered as well because it is flagged as mandatory in DQ_QuantitativeResult subset.

11

- For descriptive results there is no matching element in ISO 19115 that seems likely. The attempt here is to store the data quality statements in the existing Lineage statement and flag them as a turnout from data quality.

ISO 19115 lists several elements which build LI_Lineage. For the purpose of theme-specific metadata according to the INSPIRE Data specifications the element 83. statement is sufficient. Note that the path for dataQualityInfo/DQ_DataQuality/lineage/ will already exist in metadata because of being used for carrying information about lineage itself (see TG 2.7.1). Therefore an addition of these information into the same entity of LI_Lineage may be useful but has to be flagged by using the name of the corresponding DQ_xxx subelement concerning the particular data quality issue (e.g. ConceptualConsistency) as a prefix or topic in the lineage element.

Impact:

Questions:

I Language neutral identifiersWiki page: https://ies-svn.jrc.ec.europa.eu/projects/metadata/wiki/MIWP-8_(I)_Language_neutral_identifiers

Ticket in redmine:



2.9.3 Limitations on public access – Alternative solution


I Clarify where texts in metadata is only an identifier using English text like Topic Category Codes (e.g. health) or Spatial Data Service type (e.g. view) or where they should actually be translated to the metadata language (e.g. values for UseLimitation) This is not clearly documented in TG metadata right now.

Discussion:

In existing Technical guidelines for Metadata the element

2.9.2 Conditions applying to access and use

Describes the condition for how values should be entered when there are no conditions.

That is specified in

TG Requirement 33

12


https://ies-svn.jrc.ec.europa.eu/projects/metadata/wiki/MIWP-8_(I)_Language_neutral_identifiers

If no conditions apply to the access and use of the resource, ‘no conditions apply’ shall be used. If conditions are unknown, ‘conditions unknown’ shall be used

In national translations of Implementation rules these values are translated.

It is though not fully clear in Technical guidelines that these values should be translated to same language as Metadata language.

There is also a problem querying the catalogue for all records where e.g. "no conditions apply" since there exist no code list for this and it will be the translation engine that males the translation.

It is therefore not possible to currently query Inspire Geoportal for all datasets with "no conditions apply"

Since each national translation to English can differ.E.g. the Finnish value for this when it is translated in the Geoportal is: No restrictions.

the Swedish values are translated toNo applicable conditions

Therefore, it will be a problem to make machine-readable filter based on this keyword.

The proposed solution (in chapter 2.9.4) is to use an Anchor elements for these code lists and let this element reference the Inspire registry where the code lists for these values can be managed in a multilingual structure and where there will be easier to filter these elements.

Impact:

Existing metadata have to be updated.Tool that lack support for Anchor elements have to be updated.

Feedback needed:

The above solution suggest referencing a code list in the Inspire with an Anchor element.An alternative to this change could be to keep existing metadata guidelines and handle this element as free text.

(__) We strongly suggest using an Anchor element

(__) We prefer using an Anchor element but could also accept current implementation using a free text field

(__) We prefer to keep current implementation but could also accept the change to a Anchor element

(__) We strongly suggest keeping the element as a free text field


……………………………………………………………………………………………..

13

……………………………………………………………………………………………..

J Metadata for Spatial data servicesTicket in redmine:https://ies-svn.jrc.ec.europa.eu/issues/2219https://ies-svn.jrc.ec.europa.eu/issues/2304https://ies-svn.jrc.ec.europa.eu/issues/2305https://ies-svn.jrc.ec.europa.eu/issues/2306https://ies-svn.jrc.ec.europa.eu/issues/2307https://ies-svn.jrc.ec.europa.eu/issues/2308https://ies-svn.jrc.ec.europa.eu/issues/2309https://ies-svn.jrc.ec.europa.eu/issues/2310

Wiki page: https://ies-svn.jrc.ec.europa.eu/projects/metadata/wiki/MIWP-8_(J)_Metadata_for_SDS


2.14 Metadata for Spatial data services


Update TG Metadata with the extended elements defined for Spatial Data Services

The extended elements for SDS are now defined and it is suggested that an implementation of these is defined in the TG using an extension to ISO19115/19

Discussion:

Updates regarding Spatial data services are done in the following places:Chapters1.1.31.3.32.2.42.82.8.12.9.42.10.12.10.22.14 (new chapter)

Impact:

Questions:

14

https://ies-svn.jrc.ec.europa.eu/projects/metadata/wiki/MIWP-8_(J)_Metadata_for_SDS









15

L Unique Resource Identifier:Wiki page:

https://ies-svn.jrc.ec.europa.eu/projects/metadata/wiki/MIWP-8_(L)_Unique_Resource_Identifier

Ticket in redmine:



2.2.5 Unique resource identifier


TG Requirement 6 suggests to use RS_identifier for the encoding of the resource identifier. This is a poor choice as it is (a) against the foreseen semantic in the ISO standard, which defines it as an “identifier used for reference systems” and (b) because it is not a CSW-queryable. As foreseen by the ISO-Standard the MD_Identifier (a “value uniquely identifying an object within a namespace”) should be suggested, which is also CSW-queryable. The task will be to recommend an “MD_Identifier” (a “value uniquely identifying an object within a namespace”)

Discussion:

The Implementation Regulation for metadata (EC 1205/2008) define the unique resource identifier as “A value uniquely identifying the resource.”. And state that “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 …”.

Therefor the unique resource identifier has to consist of both a namespace and a code in order to fulfill the legal requirements.

The separation of code and namespace into two different metadata elements (as suggested by the current TG document, using RS_Identifier for the namespace) is problematic as only MD_Identifier is queryable by the CSW inferfaces and the INSPIRED iscovery Services. However the overall architectural paradigm followed by INSPIRE foresees to realize the data-service-coupling by reference to the unique resource identifier (of a data set) in the metadata record describing a service. To support related queries the INSPIRE discovery service needs to be queryable for the complete identifier of the data sets.

While the precise design of identifiers is out of scope of this TG (another MIWP group will work on recommendations) examples for identifier are given as URLs. This simplifies the management of namespaces and is good practice in the general web (linked data approach).

Impact:

Existing metadata records might need to be updated. Existing applications, resolving the data-service-coupling, might need adjustment.

16

https://ies-svn.jrc.ec.europa.eu/projects/metadata/wiki/MIWP-8_(L)_Unique_Resource_Identifier

Questions:

M Coupled resourcesWiki page:

https://ies-svn.jrc.ec.europa.eu/projects/metadata/wiki/MIWP-8_(M)_Coupled_resources

Ticket in redmine:



2.3.6 Coupled resource


The “data-service-coupling” part of the TGs need clarification urgently. The suggested solution is inconsistent and examples are confusing, making use of XML object IDs without any hints/explanation. Suggesting that both, URI or URLs to DataIdentification objects are allowed create a significant confusion for implementers and no justification is given.

The task of this group is to provide more context for the purpose of the coupled resource and to provide justification for the coupled resource as well as an outline of the related use cases (as in other parts of the document).

Discussion:

The Implementing rules for metadata defines Coupled Resourse as

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 existing technical guidelines implements Coupled Resource using the element operatesOn.

The definition for the element operatesOn is

Provides information on the datasets that the service operates on.

The datatype for the element is defined as MD_DataIdentification.

So there is a missmatch in what the Implementation Rules specifies and how the technical Guidelines have implemented this.

There are multiple opinions on how to handle this situation. We will here describe these to get feedback.

Approach A

Change the specification of the implementation of operatesOn and change the requirement so that a Unique Resource identifier is required. A URL to the MD_DataIdentification object is optional.

17


https://ies-svn.jrc.ec.europa.eu/projects/metadata/wiki/MIWP-8_(M)_Coupled_resources

This is the current suggestion in the current draft of the TG Metadata.

Arguments for this solution

We get technical guidelines that is mapped directly to what is specified in Implementing rules This is what the design of the architecture for Inspire have originally have in mind.

Arguments against this alternative

This will be an implementation of operatesOn that is not according to the specification of ISO 19119

All existing service-metadata records will have to be updated based on these new rules. If the metadata record for the service Is harvested to an other catalogue it is not guaranteed

that datasets could be found (if these are not harvested also)

Approach B

Keep existing implementation where it possible to register either a unique resource identifier or locator (URL) of the MD_DataIdentification object

Arguments for this solution

This solution is used by existing data owners and therefore existing metadata will not need to be updated.

It can be argued that the existing technical guidelines v 3.1 is fulfilling the requirements of the IR. When using the URL to the MD_DataIdentification object any system can automatically retrieve the Unique Resource Identifier from this object.

Arguments against this alternative

This solution will not directly implement the requirements of the Implementing Rules.

Impact:

Questions:

(__) We strongly suggest make only the Unique Resource Identifier as mandatory

(__) We prefer setting the Unique Resource Identifier as mandatory but could also accept the solution in existing technical guidelines.

(__) We prefer to keep solution in existing technical guidelines but could also accept the change to make the Unique Resource Identifier as mandatory

(__) We strongly suggest keeping the solution in existing technical guidelines


18

……………………………………………………………………………………………..

……………………………………………………………………………………………..

19

Documents

MIG temporary sub-group (MIWG-8) on update TG … · Web viewTG Requirement 6 suggests to use RS_identifier for the encoding of the resource identifier. This is a poor choice as it