DraftTGMetadata v05

 

Draft version of Technical Guidelines Metadata v.0.5

Updated 2015-10-29

Draft version 0.5

The draft document is available here.

This version contains updates solved from version 0.4.
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.
 

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/
SubClause/
Annex
Page:
Line No
Type Comment__________________________ Proposed solution____________________ Response______________________________________________
1 Peter Kochmann 2.8 & 3.4.2   Ge

How has the correlation between 2.8 and 3.4.2 to be seen? In 3.4.2 an additional element (measureIdentification in DQ_Element) is flagged as mandatory (which is optional in ISO). The corresponding note says "This metadata element of ISO 19115 will contain the identifier of the conformity statement. This identifier will be used by the application to differentiate the conformance statement related to INSPIRE from others."

Does it mean we have to consider measureIdentification in 2.8 too?

 

20-11-2015 Ine: This is strange, I have read chapter 2 as the INSPIRE requirements and  chapter 3 as listing the (additional) elements needed to also fullfill also the ISO requirements. There are no requirements on what should be used as measureIdentification, i guess nobody uses this for INSPIRE.

 

2015-11-23 (Peter): Meanwhile we wonder whether the obligation just might be a mistake. Of course it could make sense to provide an identifier for a particular conformance testing, but for that a recommendation on measureIdentification as an optional element would be sufficient. It's not necessary to fulfill the directive and IR and ISO, so for my point of view there's no need to have it in chapter 2.8.

I propose to have a change in 3.4.2 from [1] to [0..1] for measureIdentification as long as nobody has a proof why it should be mandatory.


2015-11-24 (Michael Ö) I suggest also changing this from [1] to [0..1]. But should the element be kept at all  in 3.4.2 This information can mislead application developers that they can expect information in this element !

2 James Reid 1.3.3   Ge
In draft 0.3 this extended the
CI_FunctionCode code list; now (& in draft 0.4) it makes description a controlled list. This is OK in principle although some folks in UK are not sure why it would be considered better? Moreover it is now inconsistent with the use of  description  given at 2.2.4 for dataset Resource Locator's, and doesn t make allowance for TG Recommendation 8.
In the UK we encourage use of  description  to provide text that appears on the Resource Locators for third party services (data.gov.uk). So this will not only require changes to some peoples metadata records and  editors, but also to the UI code at data.gov.uk at least to convert the values into something more human readable. Not sure if that applies in other MS too?
 
More importantly:
* all the values given describe something about a service; it should be made clear if this only applies to the Resource Locator in *service* metadata. If this section remains, Recommendation 8 needs revised, and we should consider consistency between the guidance for datasets & services
* we have dropped the option  information  (between draft 0.3 and 0.4). This should be re-instated. No?
* INSPIRE allows for an INSPIRE service to be behind an eCommerce interaction; there needs to be a value for this.
 

Ine 9-11-2015: In line with the member states opinion on not extending ISO with INSPIRE elements for category or quality of service, we decided the CI_FunctionCode codelist should not be replaced with an INSPIRE codelist. The kind of service (endpoint or accesspoint) can be made clear in the element description, with a controlled list.

This is only required for SDS, so not inconsistent with 2.2.4 and recommandation 8.

 

In this version 0.5 all metadata on SDS is in chapter 2.14.

I hope that in this way its clear that those requirements are only  for SDS.

 

The ISO functioncodes can still be used in this way


2015-11-25 (Michael):
I agree with Ine and we also decided on this change in Malmö.
I admit that this makes different use of the description element for services and SDS. But this drawback was decided as acceptable compared to making an Inspire-specifc extension to ISO 19115
codelist.

3 James Reid
2.2.4.3
  Ge
Another way of looking at the eCommerce question (Directive Article 14), would be to say that no Spatial Data Service which is behind an
eCommerce portal can be considered invocable, at least until there is
workable guidance on a common eCommerce system. I don t see this in the
SDS TG though. But the Directive is quite clear that eCommerce can be
applied to a Network Service or to what it called  services allowing
spatial data services to be invoked . The new TG Requirement 5 seems to
contradict this?
 

20-11-2015 Ine: The numbering is different in this version but i gues you give this comment on whats now in chapter 2.14.1.2 resource locator:

 

An invocable spatial data service shall have at least one resource locator that is an access point

 

This is an IR requirement, so we can't change this here in the TG.

I think you can better have a look at the discussion paper on SDS version 1.0rc1 and if not suitable comment on that (before 29-11)

4 James Reid
2.2.5
  Ge
The data type remains 19115 s MD_Identifier, but the example has never conformed to that. The two parts of MD_Identifier are authority (which is a CI_Citation) and code. Use of CI_Citation makes it a bit hard to provide a simple  example, but all the more important to do so! I guess that difficulty is what lead to the published guidance encouraging the use of RS_Identifier. Now (correctly) that is discouraged   but the example doesnt show what to do instead.
MD_Identifier.authority is not designed to take a  namespace ; ISO
19115:2014 fixes this, adding a  codespace  attribute to MD_Identifier.
Perhaps INSPIRE should adopt this, or specify that codespace & code are
both encoded in the old MD_Identifier.code (a bit like a URI)
 

2015-11-23 (Peter): the comment explains why it is necessary to provide a code only and have the namespace included in it. Maybe in the example we could stress the difference between the semantically meant namespace and identifier on the one hand and the matching element code from ISO on the other hand:

 

"The Unique resource identifier semantically consisting of

namespace: https://example.org/

and identifier: ab749859

 

is provided together in element

code: https://example.org/ab749859"

 

2015-11-24 (Michael Ö):I think we have to lift this to the MIWP group on identfiers.  Can someone sum up the long dicussions on the identfiers issue. I'm not sure we have an agreement that it is acceptable to provide a single identfier (with name space included)

 

2015-12-09 (Michael Ö): We have currently a majority supporting the idea of using the code to store both the namespace and the identfier so current text in draft is ok. Namespace is though  defined as separate entity  in the IR Metadata and it is also is defined  as an important part in INSPIRE conceptual model when assigning identfiers for spatial objects. It would therefore be good if we (i'm not sure how) could clearly state that in metadata there are no need to distinguish the namespace from the identfier.
And also that we are clear on that there are no relation between namespace used for spatial obect identfiers within a dataset and a defined namespace in metadata. Just so we don't have any hidden requirements regarding the namespace.

Also  known is that the translation of the definition in IR is done different among memberstates.

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, the
data owner).

In some member states the above text is translated so that namsespace is defined as mandatory.

5 James Reid
2.2.6
  Ge
This text uses the acronym URI in its  normal  (W3C) sense   which matches the new TG Requirement. At draft 0.3 it became  the URI of the dataset , whereas in the published guidance, it is a link to the metadata. This new use seems more akin to ISO 19119 coupledResource -> identifier, because that explicitly links to  a data set    by an identifier , whereas operatesOn is explicitly typed as MD_DataIdentification. The coupldeResource identifier is even explicitly a MD_Identification.citation.identifier.code   which might help at  2.2.5/Requirement 7.
  2011-11-24 (Michael Ö): we have dicussed the use of Coupled Resource.  But coupledResource is used when we want to link to a resource for specific operations. Not a general link as we want for IR 1.6 Coupled resource.
 
6 James Reid
TG Req 8
   
 There is no reason to mention 19139 here, or perhaps say  following ISO 19139, use bibliographic three letter codes from ISO 693 . We don t like the recommendation that is now numbered 10, given that 639 has a
specific code for the situation where the resource has no linguistic
content.
  2015-11-24 (Michael Ö): The requirement are now changed to a note in the updates of requirements.
The recommendation 10 I must honestly say I have not observed.
 
7 James Reid
2.12.3
  Ge
the comment suggests that adherence to an
INSPIRE GML application schema does not belong in  Encoding ?
  2015-11-12 (Peter): Yes, we see a difference between the technical encoding of the provided file (that could be XML/GML) and the logical structure of the content. The latter can be stored in the designated structure of MD_ApplicationSchemaInformation (B.2.12 in ISO 19115) or documented via the conformance statement in 2.8 when citing a particular INSPIRE data specification.
8 James Reid
2.12.6
  Ge
The use (in both parts) of an explicit indication of non-conformance to the generic network model raises the question as to whether datasets that do conform to that model should explicitly say so, or whether that is implicit in conforming to a specific application schema (eg HY network, or TN network)? Personally I don't like leaving it implicit.
 

2015-11-12 (Peter): We concentrated on fulfilling the IR 1089/2010 and reproduced the condition given there. Of course everyone is free to have this metadata issue optional as well.

But I think James' suggestion makes sense. Maybe this could become a note?

9 James Reid
2.14.1
  Ge
XML Example of availability -   I'm sure theres a uom
defined somewhere for percent?
  20-11-2015 Ine: In version 0.5 in chapter 2.14.2.2, the UoM is added in the example.
10 Martin Seiler
2.2.6
27 Ge
[Table: Data type] I don't see how this data type is in line with Metadataa IR B 1.6
 

Just to quote the IR again: "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, the
data owner)." I don't see a justificaton to interpret this as "implemented by reference here".

 

2015-12-09 (Michael Östling):


The datatype for OperatesON  MD_DataIdentfication object. Since we do not store the MD_DataIdentfication objects for datsets within same metadata record as service metadata we need to add a reference to the  MD_DataIdentfication object for the dataset metadata records.
Since that object also includes the Unique Resource Identfier for the dataset the consencus in group was that we then fulfil the IR Requirements.

We have discussed this a number of times and came to an agreement on the Malmö meeting. It was there described in quite detail and accepted by group. Also memberstates feedback on this suggested to keep existing implementaion form TG metadata 1.3.  We can not change this once again. As of now the majority suggests to keep the current implementation.

11 Martin Seiler
2.2.6
27 Ge
[Table: Domain] If you want to do it this way: make it more clear that a reference to the DataIdentification object is meant and introduce URI abbreviation
A Unique Resource Identifier (URI) or locator (URL) that references the MD_DataIdentification object of a metadata record 2015-11-18 (Peter): I agree on that! It's left to the user how to reference the MD_DataIdentification object. Ideally this is the URI taken from 2.2.5!
12 Martin Seiler
2.2.6
27 Ge
[Table: Comments] This explaination is too narrow. The xpointer could be handled/added by a separate tool resolving the given URL. Important here is the reference to the DataIdentification object, not implementation variants.
Change wording to underline the reference to the data object. State the xpointer/id solution example clearly as one possible implementation.

2015-11-23 (Peter): following Martin's proposal and fixing some orthographic/semantic issues too:

 

"The implementation of this element by reference means that the xlink:href element is pointing to a metadata record that contains a MD_DataIdentification object. The reference to the MD_DataIdentification object is done by xpointer reference using the #-sign.

The URL in the first example above points directly to #lakes which is the ID of this object. Check example on xml encoding in chapter 2.2.5.

The URI in the second example has to be resolved by a separate tool producing a CSW-Command that contains an abstract pointer to the MD_DataIdentification object.

 

In both cases shown above the Unique Resource Identifier from 2.2.5 can be given additionally and using the optional uuidref attribute."

 

2015-11-24 (Michael Ö): I agree on Peters text. But as Martin also writes the use of a URL that points to a metadata record and where we use a xpointer to rereference the MD_DataIdentification object is one of many possible cases. It could also be possible to use hlink:href todirectly reference a fragment repository where MD_DataIdentfication objects are stored. So the example should be even more generic than the example above.

 

2015-12-09 (Michael Östling): In the second example described by Peter you mention that the URI has to be resolved by a separate tool. How will this work in the INSPIRE-infrastrukture. How do you handle the resolver in case the URI is not a URL.
Or is the case that it is an URI that actually is a URL pointing to a resolver?

13 Martin Seiler
2.2.6
28 Ed
[TG Requirement 6] wording. URI should be mentioned too.
Change wording to: The property shall be implemented by reference (see SC11 in 1.2). This means that the MD_DataIdentification object shall be pointed to by using an URI.

2011-11-24 (Michael Ö) : Ok

2015-12-09 (Michael Ö): In case a URI is used how is the resolving to a URL handled? If eg metadata is harvested from INPIRE Geoportal into an other catalog. How can I resolve the URI that identfies the dataset. Is the idea that metadata is managed using an URI but when accessed or harvested then the URIs are resolved to URLs

14 Martin Seiler
2.2.6
29 Ge
another example should be provided showing the implementation with xlink and direct reference with a hint that the URL is redirected and xpointer is handled elsewhere.
xlink:href="https://example.org/ab749859"

2015-11-23 (Peter): And I think it is important to have it identical to the example in 2.2.5 (it is with the one given here)

 

2015-11-24 (Michael Ö): Just to be sure we have same view.
The example you show xlink:href=https://example.org/ab749859 will be resolved/redirected so that it wil actually return a MD_DataIdentification object (and that it shuld be clear the use of the request GetRecordByID is just one of many possible examples to solve this)

 

2015-11-24 (Peter): Yes, e.g. https://registry.gdi-de.org/id/de.by/125cce16-7ae1-3cf0-96e2-05a4453f3cb1  will be resolved to http://geoportal.bayern.de/csw/bvv?service=CSW&version=2.0.2&request=GetRecords&namespace=xmlns%28csw=http://www.opengis.net/cat/csw/2.0.2%29,xmlns%28gmd=http://www.isotc211.org/2005/gmd%29&resultType=results&outputFormat=application/xml&outputSchema=http://www.isotc211.org/2005/gmd&startPosition=1&maxRecords=1&typeNames=csw:Record&elementSetName=full&constraintLanguage=CQL_TEXT&constraint_language_version=1.1.0&constraint=csw:ResourceIdentifier=%27*125cce16-7ae1-3cf0-96e2-05a4453f3cb1*%27

)15 Peter Kochmann 1.3.1 18 Ge The note concerning the non-use of "invoke" gives the impression that other SDS ("invocable") are the reason to cut it off. The reason documented in the discussion paper on SDS says that every discovery service fulfills the function of invoking a spatial data service so "invoke" is needless (and I can follow this argumentation). So citing SDS for me seems to be wrong (mix-up of "invoke" and "invocable").

Re-use the text from discussion paper on SDS:

 

"NOTE: The value invoke should no longer be used within INSPIRE. Since all services can be invoked when metadata are published and accessed through a discovery service, there is no need to have a special service to invoke other services. Instead the discovery service will take the role as making it possible to invoke a service."

 

20-11-2015 Ine: The argumentation is develloped the last months, I agree the argumentation as is now in the discussion paper on SDS is clear, so we should use that as Peter proposed. 
16 Peter Kochmann 2.3.2 38 Ge

In TG_for_INSPIRE_SDS_3.2rc1 all examples contain the value "other" for the information on spatial data service type. I remember (a) a discussion on the question whether an invocable SDS that is also a view service has to be coded with "view" or "other" here (did we come clear on that?) and (b) a particular statement in this chapter (table on multiplicity, domain etc.) with information on SDS. Maybe this got lost when withdrawing the full integration of metadata on SDS into the TG metadata document.

If there was consensus on (a):

Add a comment in the table for SDS that says something like "For invocable SDS that are not network services the value "other" has to be provided."

 
17 Ine de Visser 1.3.1 18 Ge There are different interpretations on how the value of the spatial data servicetype should be used. Add a note:
•3.1-3.4 Will be used for describing type of Network services (according to IR Network service)
•3.6 Other services (even e.g. download service that do not conform to IR Network service) will be consider as “other service”
2015-11-23 (Peter): I think the particular use of spatial data service type is not in focus here. Chapter 2.3.2 provides detailled information on that. See also #16.
18 Peter Kochmann 3.6 213 Ge Since considering useConstraints and skipping useLimitation in new wording of 2.9, the detailled mapping in chapter 3 has to be maintained!

1. erase useLimitation from the box

2.add an entry for useConstraints similar to the one for accessConstraints and clear the references to 2.9.1, now also 2.9.2

2. consider useConstraints in note 1 and footnote 16 as well

2015-12-09 (Michael ö): Agree, We should update according to this. We should also remove reference to MD_SecurityConstraints
since that is no longer part of TG.