Consultation #2871

Remaining open issues in MD TG 2.0rc4

Added by Michael Lutz over 3 years ago. Updated over 3 years ago.

Status:ClosedStart date:15 Nov 2016
Priority:NormalDue date:18 Nov 2016
Assignee:Michael Lutz
Category:-

Description

There are still 5 open issues in the document:

  1. How to use unique identifiers to refer to specifications?
  2. How to use unique identifiers to refer to controlled vocabularies?
  3. Allowing the use of RS_Identifier for the unique resource identifier?
  4. How to specify the coordinate reference system for data sets with an indirect spatial reference (e.g. statistical data)?
  5. How to provide more detailed information on the service type?

These will be discussed in a MIWP-8 web-conference between 21-25 November.

Please provide your feedback and preferred options on these issues as comments to this issue

History

#1 Updated by Marie Lambois over 3 years ago

Here are some thoughts.

Have a nice weekend

Marie

------

  1. How to use unique identifiers to refer to specifications?
  2. How to use unique identifiers to refer to controlled vocabularies?

 “Anchor” option is preferred.

Both options are not to be opposed. We could imagine to have a CI-Citation fragment in a register containing an Anchor. For this reason choosing option ”anchor” does not forbid the “by-reference” option.

“By reference” option requires that we have a CI_Citation available in the register, available in all languages. Even if this is an option that can be considered nationally it could be hard to manage at a European level and too difficult to set up for some MS.

  1. Allowing the use of RS_Identifier for the unique resource identifier?

Yes it should be allowed.

Even if I agree that MD_Identifier should be preferred, I think it should stay a recommendation.

The issue with RS_Identifier is that in a lot of cases only code is used. Nevertheless, I have seen many metadata editors using RS_Identifier with only a code (which is completely allowed). I would then just suggest to warn that in  many applications only the code will be taken into account.

  1. How to specify the coordinate reference system for data sets with an indirect spatial reference (e.g. statistical data)?

Mention the name of the “spatial reference systems using geographic identifiers”

I would not say that it is not allowed in ISO 19115 as what with have to mention is the name of the reference system and this should be applicable to spatial reference systems using geographic identifiers as well. However I do not know the statistical data enough to know which system is recommended, it could be something like “EU administrative units register”…

  1. How to provide more detailed information on the service type?

Keep the inspire service type information.

Please note that in ISO 19115-1, serviceType explicitly mentions Inspire service types (view, download…)

An issue with option B is that we would not be able to distinguish between a “classic” WMS and a “inspire” WMS. What about a third way, something like view:wms ?

Otherwise we could keep current values and recommend ogc:wms as a keyword.

 

#2 Updated by Javier Nogueras Iso over 3 years ago

After discussing it with Alejandro Guinea and members of IGN-CNIG Spain, our suggestions for the open issues are the following:

1) How to use unique identifiers to refer to specifications?

2) How to use unique identifiers to refer to controlled vocabularies?

In principle, option 2) of using xlink:href (as referred in pages 28 and 35 of 2.0rc4 document) seems more sensible to avoid including again the complete citation (if already available on the INSPIRE web space). Anyway, it should be considered also if current metadata editors and catalog tools allow this possibility. It must be noted that INSPIRE has a fixed roadmap for its implementation. Every proposed change in guidelines and recommendations should be justified and its feasibility should be analysed.

3) Allowing the use of RS_Identifier for the unique resource identifier?

If the introduction of RS_Identifier introduces ambiguity for providing a unique resource identifier, which can be divided into code + codespace and be misleading later if referred in other metadata elements (e.g. coupled resource), we consider that is better to be strict and maintain MD_Identifier.

4) How to specify the coordinate reference system for data sets with an indirect spatial reference (e.g. statistical data)?

We consider that option 2) of including an RS_Identifier (as proposed in open issue of page 48 in 2.0rc4 document) is the most appropriate. If this is a mandatory element according to INSPIRE, the INSPIRE registry should be updated to include codes to refer to different Reference Systems by Geographic Identifiers. As far as reference systems for statistical units is concerned, Eurostat could be an appropriate source for proposing these codes. Apart from using the NUTS system for statistical units, Eurostat has probably compiled the different statistical unit systems used in the different member countries.

5) How to provide more detailed information on the service type?

Our suggestion is to vote for option 1), i.e. using a different metadata element (as proposed in the open issue on page 63 of 2.0rc4 document). serviceType is an attribute that allows a single occurrence and it can be completed with the codes of Part D.3.

For more specific details of the service type, we could use MD_Metadata/indentificationInfo/SV_ServiceIdentification/descriptiveKeywords. This element allows multiple instances. Additionally, we can create a thesaurus with a full taxonomy of service types. For instance, in this thesaurus INSPIRE Spatial Data Service Types could be broader terms, and OGC service types could be narrower terms.

At Spain Spatial Data Infrastructure (IDEE) this approach was adopted several years ago and it works. On the one hand, we created a SKOS vocabulary for the ISO 19119 taxonomy of service types, which are also included as part D.4 of INSPIRE metadata implementing rules. On the other hand a separate SKOS vocabulary was created also for a taxonomy of OGC specifications. These two vocabularies were integrated in CatMDEdit tool (metadata tool implementing IDEE recommendations) and service metadata is classified according to both vocabularies. You can see an example of service metadata at http://www.idee.es/csw-inspire-idee/srv/spa/xml.metadata.get?id=786159 . The thesaurus name for OGC service types is called WebServicesSpecification. The thesaurus name for ISO 19119 (part D4) is called INSPIRE_SpatialDataServicesClassification.

#3 Updated by Antonio Rotundo over 3 years ago

Please find below my comments and my preferred options on the open issues.

1. How to use unique identifiers to refer to specifications?

My preferred option is the second even for the reason mentioned by Javier. 

2. How to use unique identifiers to refer to controlled vocabularies?

Since many vocabularies, from which keywords are taken, could be used in addition to that one required for declaring the INSPIRE spatial data themes (GEMET - INSPIRE themes) and since it's hard to know all the possible vocabularies to be used and to manage them in INSPIRE (or eventually MS) web space, I prefer the first option (Anchor). The second option could be eventually kept only for GEMET - INSPIRE themes.

3. Allowing the use of RS_Identifier for the unique resource identifier?

I prefer to not more allow the use of RS_Identifier even for the following reasons:

  1. In ISO AP the resource identifier is only mapped with MD_Identifier.code (see table 10);
  2. The example 4.5 in TG MD is not properly correct because in the GetRecords requests the property apiso:identifier has to be matched to the fileIdentifier and not to the identifer of the resource (see table 6 in ISO AP). The correct queryable property for the identifier of the resource is ResourceIdentifier (see table 10 given in ISO AP), that has to be matched with MD_identifier.code (see point 1.).

4. How to specify the coordinate reference system for data sets with an indirect spatial reference (e.g. statistical data)?

We could follow the recommendations given in DCAT-AP specification for the geographic identifier, even taken into account in GeoDCAT-AP: using an HTTP URI for the RS_Identifier code from one of the following registers / gazetteers:

5. How to provide more detailed information on the service type?

I prefer the second option. I don't see the problem raised by Marie about the confusion between "classic" WMS and "inspire" WMS. Through that metadata element only the INSPIRE network services type can be documented and so, in case of the view service, the WMS is only the "inspire" WMS.

#4 Updated by Antonio Rotundo over 3 years ago

I changed my comments on the open issues 1 and 2, even after noticing the note on page 28.

Regards,

Antonio

#5 Updated by Michael Lutz over 3 years ago

From Peter Kochmann (I hope the translation is ok...):

3. Allowing the use of RS_Identifier for the unique resource identifier?

I could live with allowing also RS_Identifier, even though I still consider it technically/semantically wrong (resourc ids have nothing to do with Reference system ids). But there would have to be a clear preference/recommendation to use MD_Identifier; otherwise I see risks for interoperability! I'm doubting that in the GetRecords request, you can really filter based on two attributes (code and codeSpace).

5. How to provide more detailed information on the service type?

I support extending the code list. It is high time to make the unspecific terms like "view" etc. more precise or at least to extend the list.

 

#6 Updated by Michael Lutz over 3 years ago

Looking at your commenst for Issues #1 and #2, we could also use the following solution:

  • RECOMMEND the use of Anchors in the title elements, e.g. "For references to well-known INSPIRE legal acts, technical guidance documents or conformance classes, the title element of the specification SHOULD be encoded using the gmd:title/gmx:Anchor element." plus
  • OFFER the use of "pre-cooked" CI_Citation elements provided in the inspire.ec.europa.eu namespace, e.g. "For references to well-known INSPIRE legal acts, technical guidance documents or conformance classes, the specification element MAY be encoded as a reference (using the xlink:href attribute of the gmd:specification element) to an XML fragment document containing the CI_Citation element of the relevant specification."

The XML fragment should then of course include the relevant gmx:Anchor.

#7 Updated by Christine Brendle over 3 years ago

Michael Lutz wrote:

There are still 5 open issues in the document: How to use unique identifiers to refer to specifications? How to use unique identifiers to refer to controlled vocabularies? Allowing the use of RS_Identifier for the unique resource identifier? How to specify the coordinate reference system for data sets with an indirect spatial reference (e.g. statistical data)? How to provide more detailed information on the service type? These will be discussed in a MIWP-8 web-conference between 21-25 November. Please provide your feedback and preferred options on these issues as comments to this issue

After discussions with our colleagues in Austria:

1. How to use unique identifiers to refer to specifications?

We agree with Antonio's suggestions.

My preferred option would be the second even for the reason mentioned by Javier. But I wonder if that option (i.e. the use of direct xlink references in the gmd:specification element) can be considered compliant with the TG Requirement C.21.  According to that TG Req, in fact, "the gmd:title child element of the citation element with a Non-empty Free Text Element content" shall be used; moreover "For the INSPIRE Implementation Rule documents the value of the title element shall match exactly the official title of the cited document in the language of the metadata". Then, does referencing an external (in the sense of not included in the metadata) XML fragment document containing the required citation elements, although obviously XML Schema-valid, ensure that the compliance to the cited Req is achieved? If not, only the alternative form of the option 2, i.e. including both the CI_Citation fragment and the xlink references! , should be recommended. 

Generally to reference to INSPIRE websites, whenever links are stable.

2) How to use unique identifiers to refer to controlled vocabularies?

We agree with Javier's suggestions.

In principle, option 2) of using xlink:href (as referred in pages 28 and 35 of 2.0rc4 document) seems more sensible to avoid including again the complete citation (if already available on the INSPIRE web space). Anyway, it should be considered also if current metadata editors and catalog tools allow this possibility. It must be noted that INSPIRE has a fixed roadmap for its implementation. Every proposed change in guidelines and recommendations should be justified and its feasibility should be analysed.

->  the Metadataelements should always have information, which is suitable for search and give a hint for purposes of the enduser needs.

 

3) Allowing the use of RS_Identifier for the unique resource identifier?

We prefer only to use MD_identifier.

an own attribute ("namespace" is not necessary anymore) because it will be integrated into the code. Using a RS_identifier with seperated code and namespace would not be resolvable.

4. How to specify the coordinate reference system for data sets with an indirect spatial reference (e.g. statistical data)?

We agree with Antonio's suggestions.

Please be aware of the definition of the term "coordinate reference system". Here we are talking about "indirect reference system" (in German: indirekte Bezugssysteme: see Barthelme 2005 / Geoinformatik – Modelle, Strukturen, Funktionen – page 220 (Andere Arten von Bezugssystemen)

 

 

 

 

 

#8 Updated by Antonio Rotundo over 3 years ago

I agree with the solution proposed by Michael.

Concerning the vocabularies, the XML fragment could be provided with respect to 3 well-known thesauri mentioned in the example given in the section C.2.11 of the TG, i.e. besides "GEMET - INSPIRE themes", even "GEMET - Concepts" and "EUROVOC".

#9 Updated by Michael Lutz over 3 years ago

From James Reid (UK)

Apologies for the slow reply. Ahead of this afternoons discussion please find some comments from me:

 

  1. How to use unique identifiers to refer to specifications?
  2. How to use unique identifiers to refer to controlled vocabularies?

Use of Anchor is our preferred option -  but not opposed to the 'by-reference' option

  1. Allowing the use of RS_Identifier for the unique resource identifier?

Keep as a recommendation i.e do not forbid (though preference should be MD_Identifier)

  1. How to specify the coordinate reference system for data sets with an indirect spatial reference (e.g. statistical data)?

The suggested control lists that have been suggested are all acceptable. Q: should EuroGeonames be used as canonical NMCA resource list?

  1. How to provide more detailed information on the service type?

Use the INSPIRE service type . It might be possible to recommend a default such as ogc:wms but I don't think this is rich enough to allow sensible discrimination esp against INSPIRE enriched WMS/WFS..

#10 Updated by Ine de Visser over 3 years ago

1. How to use unique identifiers to refer to specifications?

2) How to use unique identifiers to refer to controlled vocabularies?

“Anchor” option is preferred, i am not sure the xlink become available in all the official languages and

could be resolved by the available tooling

3) Allowing the use of RS_Identifier for the unique resource identifier?

i prefer the recommandation

5. How to provide more detailed information on the service type?

I am not supporting the idee to extent the used codelist used in servicetype with other values, because this is based on required values in the implementing rule.

Formal reaction is that this is not an INSPIRE requirement, so no solution is nessacerry otherwise we can add a lot more.

But we see the need of more detailed information, we (and also other memberstates like sweden) use the element protocol with a codelist several years for this.

I am also not supporting the idee to use the keywords for this information, because there is a more fitting element for this and so preventing from keywords  is used for all the "öther" information

 

 

 

#11 Updated by Michael Lutz over 3 years ago

  • Status changed from Work in progress to Closed

This consultation has been completed.

Also available in: Atom PDF