DraftTGMetadata v03

 

Draft version of Technical Guidelines Metadata v.03

Updated 2015-06-15

The document can be reached here

This version is first draft where all sections of what's planned for Release A are included.
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.
 

To aid readers in understanding the descisions taken in this document and what changes are done since last published version of TG Metadata
we will enclose this draft with a discussion document that gives some background for the changes done.
This document will be available in July

This draft contains updated sections in document for

2.2.5   Unique resource identifier
2.3.6   Coupled resource
2.9      Contraints related to Access and use
2.11.3  Metadata Language
2.12     Metadata for interoperability
2.13     Theme specific metadata
2.14    Metadata for Spatial data services

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 (Michael Östling):


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.13.1 91: 19 Ge/Te Based on unsolved #20 of comments on draft 02 we still have to decide which elements shall be demanded within MD_MaintenanceInformation. Antonio's proposal was to concentrate on maintenanceAndUpdateFrequency (143) only which is mandatory by ISO. Michael Ö proposed to always have a corresponding maintenanceNote (148). I still see the element updateScope (146) to be useful, at least because the "INSPIRE definition" of this whole section is "Information about the scope and frequency of updating".

We still hold on to these three elements, but make a difference in multiplicity:

"should be used" for maintenanceAndUpdateFrequency (143);

"recommended to be filled" for updateScope (146) and maintenanceNote (148).

2015-06-25 (Peter): discussed with Michael Ö to

1. clearly flag 143 as mandatory (according to ISO);

2. flag 146 and 148 as optional but single occurance only;

3. recommend that multiple update scopes and maintenance notes should be expressed in multiple MD_MaintenanceInformation instances

 

2015-07-10 (Eliane) : agree. simply be careful not to introduce a confusion: maintenance information (MD_MaintenanceInformation) is optional, but if it is instanciated, then 143 is mandatory (according to ISO)

 

2015-07-13 (Peter): prepared like proposed for next draft

 

2015-07-23 (Antonio): Altough I think that updateScope is a redundant information (as in most cases it is the same as the scope to which the metadata applies), I essentially agree.

 

2015-08-19 (Peter): to be followed as #10 on draft 04

2 Peter Kochmann 2.13.11 108: 1 Ge

Based on #13 of comments on draft 02 we have to add some things to the matching table of INSPIRE annex themes and data quality issues: As Geraldine found out there are some more issues hidden in chapters 7 of several data specifications. I looked them up again and maintained the matching table.

New matching table has been prepared considering "Usability" now for themes BU, OF and SR.

2015-06-25 (Peter): table sent for next draft
2015-07-16 (Michael): Update done in draft 0.4
3 Peter Kochmann

2.14.3

2.14.4

116: 32

120: 2

Ed These headings are formatted on a too high level (same as 2.14) put them in line with 2.14.1 and 2.14.2 2015-07-16 (Michael): Update done in draft 0.4
4 Peter Kochmann 2.12.6 85: 46 Ge Based on #35 of comments on draft 02 there is still the idea of avoiding the non-matching descriptive and quantitative results for Topological consistency. I proposed to discuss the alternative of using DQ_ConformanceResult where "INSPIRE Generic Network Model" would be the specification (which is the condition to have this element in 2.12.6 at all). That would also fit with the not yet deleted example of Michael (page 88, line 11, see corresponding #21 of comments on draft 02). discuss on next meeting and give me a sign which way is preferred

2015-07-17 (Michael): I'm a bit lost regarding the actual requirements for quantitative and descriptive reports needed. Do we have some concrete examples we could exemplify this with?
If using the DQ_ConformanceResult was the intention then to use the Explanantion element to describe details or exception on the conformance?
Could we update the reading guidlines with the alternatives to get wider feedback ?

 

2015-07-23 (Antonio): Using DQ_ConformanceResult was my proposal I added in the first template made by James Reid and the XML example at page 88, line 57 in the draft 04 is derived from that proposal. In the example the value of pass tag is to be updated to "false" as proposed by Peter in the comment #35 on draft 02.  So, I agree.
As far as the explanation element is concerned, it could be used to give a description, as a free text, of the topological consistency quality sub-elements (and also the connectivity tolerance for every measures as suggested by the DS), if any, required in the DS sub-clause 7.1.6 (see e.g. Data Specification on Transport Networks or on Utility and Government Services).

I agree in updating the reading guidelines.

 

2015-08-19 (Peter): issue still open; to be followed as #9 on draft 04; I will explain the proposal there

5 Peter Kochmann 2.12.2 80: 23 Ed In the field "Comments" in the last sentence the word "version" is missing. It is flagged as deleted which is wrong. Further elements like authority, codeSpace and version are optional but may be included for completeness if required. 2015-07-16 (Michael): Update done in draft 0.4
6 Vincent Bombaerts 2.9 58:16 Ge/Ed Why delete reference to Article 13 ? It has interest to know that limitation may only occur in a set of defined cases. Restore this reference.

2015-07-09 : E.Roos : agree with Vincent

 

2015-07-14 (Peter): I guess this was the consequence of concentrating on requirements resulting from IR Metadata. Here I agree to restore this reference because the facts documented in article 13 of the directive are essential for the whole constraints chapter!
 

2015-07-16 (Michael): When we update the requirements in document it should be very clear from where each requirement is taken so we probably need a reference to this as well. I will update doc

7

Vincent Bombaerts

2.9

58:37 Ge/Te Can we really have limitations on public access and conditions applying to access and use in the same MD_Constraints element if TG 29 mandates the use of 2 different MD_constraints element ? Delete if not possible

2015-07-14 (Peter): Why not put them into separate instances of MD_LegalConstraints? We could delete the third bullet (line 37 on page 58) and make it a requirement that limitations on public access (2.9.1/2.9.3) need to be placed in an own MD_LegalConstraints. Another MD_Constraints/MD_LegalConstraints would contain conditions applying to access and use either in useLimitation (2.9.2, therefore MD_Constraints would be sufficient) or accessConstraints/useConstraints/otherConstraints (2.9.4).

I think this would also make it easier to have a connection between accessConstraints or useConstraints = "otherRestrictions" and the corresponding otherConstraints with the free text.

 

2015-07-16 (Michael): Yes I agree the current text is not clear enough on this. The intention have been to implement this a Peter describes above, as separate instances of MD_LegalConstraints, otherwise the suggested implementation will not work.

 

2015-07-24 (Antonio): I agree with Peter too, with the exception that in the istance of MD_Constraints/MD_LegalConstraints used for conditions applying to access and use I'd consider only accessConstraints/useConstraints/otherConstraints and not useLimitation. So, the useLimitation element (optional) could be used by data providers in the meaning given by ISO 19115.

 

8 Vincent Bombaerts 2.9.3 63:42 Ge Is 2.9.3 an alternative solution to 2.9.1 or is it more a recommandation on 2.9.1 ? The same ISO 19115 metadata elements are used. The difference is that in 2.9.3 we add a reference to the INSPIRE registry. Integrate 2.9.3 solution into 2.9.1

2015-07-09 : E.Roos : agree with Vincent

 

2015-07-14 (Peter): I agree too.  I think it's easier to understand when the alternatives (old 2.9.1 and new solution with INSPIRE registry from 2.9.3) are presented together. This maybe will avoid mix-ups with 2.9.2/2.9.4.

 

2015-07-15 Ine: I agree

2015-07-16 (Michael):  I don't agree here. If we don't implement Limitations on Public acess using 2.9.3 then we can't change the implementation of conditions for access and use to 2.9.4 which is the main goal for this ticket. So I don't see that 2.9.3 is optional. Can someone show an example how we can use 2.9.1 and 2.9.4 and separate the information as needed, I may miss some details in the reasoning here?

9 Vincent Bombaerts 2.9.4 66:11 Te In the ISO, the "conditional" is not clear : can we use it even if condition is not met, like an optional element ? If not, solution 2.9.4 should mandate the use of 70. accessConstraints or 71.useConstraints Clarify this point and modify document if needed

2015-07-09 : E.Roos : agree with Vincent. we have to mandate the use of the value "otherRestriction" in accessConstraint or ueConstraint in order to use the field otherConstraint. See Peter answer in comment 15 on draft 0.2.

 

2015-07-14 (Peter): I agree. Not to forget the same issue in 2.9.1 (already raised while commenting draft v02, but not yet maintained)!

 

2015-07-15 Ine: I agree

2015-07-17 (Michael): I lost the note on comment #15 at draft 0.2 That made it clear on these elements. draft 0'4 wil be updated on this.

10 Pawel Soczewski 1.3.3 14 Ed Does the link shouldn't point to the chapter 2.2.4?  

2015-07-10 (Peter): I guess the yellow mark flags it to be maintained. To be precise it has to be 2.2.4.2.


2015-07-17 (Michael): Reference is updated

11 Pawel Soczewski 2.12.3 32:11 Ge/Te In case the name is taken from INSPIRE Registry, it may be appropriate to encode that element using the gmx:anchor.

In line 11 Domain row add:
 - 285. name [1] / domain value: free text or 
    if the values is taken from INSPIRE Registry used then a an Anchor to the codelist in the Inspire Registry should be used.

Add the second example of XML encoding:
<gmd:MD_Metadata>
    ...
    <gmd:distributionInfo>
        <gmd:MD_Distribution>
            <gmd:distributionFormat>
                <gmd:MD_Format>
                    <gmd:name>
                        <gmx:Anchor xlink:href="http://inspire.ec.europa.eu/media-types/">application/gml+xml</gmx:Anchor>
                    </gmd:name>
                </gmd:MD_Format>
            </gmd:distributionFormat>
        </gmd:MD_Distribution>
    </gmd:distributionInfo>
    ...
</gmd:MD_Metadata>

2015-07-13 (Peter): Is there a dependency to a particular content for version in case of using INSPIRE registry? Element 286. version is mandatory and its existence has to be ensured.

Besides this I think it still would be free text only with element 285. name in field domain. I propose to add the anchor hint after the last sentence in field domain.

 

2015-07-17 (Michael):  Do you mean adding just an hint that Anchor could be an option to use ?

Are mediatypes always relevant here? Even in case a GML-file are zipped and added as an entry into a Atom file?
It would be more relevant to use the format GML and not media types or is the opinion that media-types always is best mapped to this element?

 

2015-08-19 (Peter): issue still open; to be followed as #39 on draft 04

12 Pawel Soczewski 2.12.1 19:1 Te Encoding of Coordinate reference system at 2.12.2 isn't consistent with Coordinate Reference System Identifier at 2.14.2.5. In second case a an Anchor is used. Changing encoding in the chapter 2.12.2 to use an Anchor element.

2015-07-13 (Peter): I'm not sure whether this is the right conclusion. Chapters 6 of Data specification demand an identifier for the used reference system. Is this the same as a gmx:Anchor? In my opinion a gmx:Anchor would have to be filled with a link to the EPSG-registry and not with the identifiers itself taken from the given table.

 

2015-07-15 Ine: see comment #40

13 Eliane Roos 1.3.3 18:9-18 Te

If it is possible to avoid existing ISO codelist extension, I think we should try to avoid it.

Here, instead of extending or replacing the existing codelist, it is possible to provide the information using the "description" attribute of CI_OnlineResource.

 

Use the metadata element onlineResource.description (which is a free text) to provide the information. The codelist can be kept to specialize it with a restricted domain of value as what has been done for the service type for example.

This would enable to be compatible with all ISO-based applications, whitout having to modify them to take into account the extension.

Thanks for this suggestion, i have made the change in the next draft.

 

2015-07-17 (Michael): Agree. The codelist used here. Are we certain that we need all types?

14 Eliane Roos 2.2.4.1

TG Req 3

25:5

ed missing word "a link to a web with further instructions" either "link to the web" or "link to a web page" 2015-07-17 (Michael): Updated with "web page"
15 Eliane Roos 2.2.4.1 TG Req 3 te

TG req 3 is exactly the same than TG Req 4. However, one is for data, the other is for services. Is it a willing? I am not sure that the 3rd bullet is applicable to data, for example.

If both paragraph regarding resource locator for services and resource locator for data are exactly the same, I do not see the point to have 2 paragraph. But I do not think they should be the same.

think of deleting the third bullet.

4th bullet should read "a link to a client application that directly accesses the data"

2015-07-17 (Michael): Updated 4th bullet text.

I think this is an interesting question. Would it be valid to have a link to service that gives access to a dataset from the dataset metadata itself?
I'm not sure if Inspire denies to have such links.

(my comments below maybe a bit besides the discussion)
The concept of ISO 19115 is to have separate metadata records for data and services.
With current architecture you will, after finding data have to be redirected to a service where you actually can download the data.
For users this is somewhat confusing. As an example for eg Protected sites the user here finds three records, one for the data, one for the view service and a third for the download service. From a user prespective it would be easier to find one (1) record describing data and then various access possibilities for this dataset as online links. Eg links to view-services, atom-feeds or WFS services. using these links each accesstype can be evaluated and if the user needs more details about the services, metadata for thoose  can be opened.
This is in limited way implemented in the Swedish National SDI. Some portals only make the dataset-metadata queryable. But all Services metadata can be access by direct calls but they are not part of standard query-results.
16 Eliane Roos 2.2.5 table te if the usage of the code only is recommanded, then the reference to ISO standards in the table should be modified

change the ISO 19115 number and name to "207. code"

change the 19139 path to identificationInfo[1]/*/citation/*/identifier/*/code

change the data type to "characterString"

 

2015-07-10 (Peter): Why? XPath to 365.identifier an Data type 205.MD_Identifier are sufficient and accurate

 

2015-07-17 (Michael): i think the current implementation is inline with how we document eg format with domain MD_format and reference date with domain CI_Date.
So I think the way we have done it now is ok.

17 Eliane Roos 2.2.5 table, line domain te should we precise that we want "http URI"?   2015-07-10 (Peter): we had this disussion before, see #5 and #6 in draft 02 and ticket #2220
18 Eliane Roos 2.2.5 table, line commment te the sentance "The use of RS_Identifier (with a separate element codeSpace) is not suitable here" is not correct, since it is possible to use RS_Identifier whitout instanciate the element codeSpace. change to " The use of the codeSpace metadata element (of RS_Identifier) is not suitable here".

2015-07-10 (Peter): the sentence isn't incorrect at all because RS_Identifier aims at Reference Systems. That's still not suiting here. We have to avoid a separate codeSpace element beacuse of 2.2.6 so it's the safe way to focus on MD_Identifier

 

E.Roos : in ISo 19115-1, the codespace property has been moved to MD_Identifier... because people wanted to be able to use it for other thing than referenceSystem. So I think it would safer to say that we do not want the codespace property, instead of saying that we do not want the RS_Identifier.

 

2015-07-17 (Michael): Isn't the problem here that we think the RS_Identifier is semantically wrong. It is suited for Reference Systems as Peter mentions.
Angelo also shows a suggestion on ticket  how current version of ISO 19115 can handle  a namespace within the  MD-Identfier

 

 

19 Eliane Roos 2.2.3 and 1.2 TG Req 1 Ge/Te This is not a requirement from the TG. It is a requirement from the Metadata Regulation itself.

suppress this req and replace it by a general requirement in clause 1.2 (specific constraint) telling "In order to conform to the INSPIRE Regulations, a compliant ISO 19115 metadata set shall follow the specific constraints listed above."

 

and by the way, clause 1.2 should be updated according with the new elements in clause 2.12.X

2015-07-13 (Peter): this is a basic question: are we going to maintain anything that we find in current TG independent from tasks in ToR?

Concerning this issue: As I understood, chapter 1.2 defines the initial and abstract constraints for metadata in focus of INSPIRE regulation. I think it's better to read when every certain constraint oder rule concerning a particular element is listed with this.

 

2015-07-17 (Michael): The issue on the clear identification of IR and TG requirements are currently raised from the sub-group MIWP-5. So the requirements should undergo a complete revision clarifying if the requirement are originating from the ISO or interoperability resons or from any IR.
The requirements on xpath, mandatory or not, multiplicity  and datatyoe should be defined in the tables them selves instead of having separate Requirements clauses that just repeates the information So I think the comment is relevant, we shall just a wait awhile before handling these. 

But it is correct as Peter mentions, we shall not directly do changes in the TG that are not within scope of ToR. But if we find issues in the TG that we think are wrong and should be handled we should list them and see if we can manage them anyhow in case they are small. In case there are larger issues we should seek advice from MIG-t.

20 Eliane Roos 2.2.3 TG Req 2 Te This is not a requirement from the TG. It is a requirement from the Metadata Regulation itself. Delete this req, and enter the possible values directly in the domain column (as it is done for the language)

2015-07-13 (Peter): see #19, in fact the domain row could be more explicit here and list the allowed values dataset, series and service only.

21 Eliane Roos 2.2.7

table

line comment

te/ge this comment is valid for all metadata element using a list of values from a codeList, not only for the language. either put this discussion in A.11, or precise in 2.2.7 that this discussion is valid for all metadata elements using codelists.

 

2015-07-17 (Michael): see comment on #19

22 Eliane Roos 2.2.7 TG req 7 te req 7 should be clarified

change to "Even if the Resource Language is conditional in INSPIRE metadata regulation, it is mandated by ISO 19115 and by the way shall be provided".

 

add the TG recommendation 12 just after.

 

Moreover, one generic TG requirement should be added in the document (maybe in clause 1.1) to say : "INSPIRE metadata should be provided within a ISO 19115 compliant metadata set"

2015-07-17 (Michael): see comment on #19
23 Eliane Roos 2.2.7 TG req 8 te this is already said in the table above. suppress it

 

2015-07-17 (Michael): see comment on #19

24 Eliane Roos 2.3.1 TG req 9 te this is already said in the table above. suppress it

 

2015-07-17 (Michael): see comment on #19

25 Eliane Roos 2.3.1 TG req 10 te/ge this is true for all metadata element using ISO 19115 codelists or enumeration either put this discussion in A.11, or precise here that this discussion is valid for all metadata elements using codelists.

 

2015-07-17 (Michael): Agree to put it in A11

26 Eliane Roos 2.3.2 TG req 11 te/ge same comment than 24 and 25.   2015-07-17 (Michael): see comment on #19
27 Eliane Roos 2.12.1 TG req 42 te same comment than 19. This is not a requirement from the TG. It is a requirement from the INSPIRE Regulation itself.

suppress req 42, as it is already specified in table above. Add SC19 in 1.2 : For datasets and series MD_Metadata.referenceSystemInfo.MD_ReferenceSystem.referenceSystemIdentifier is mandatory.

 

2015-07-13 (Peter): see #19 also;

concerning this issue: I raised this question before: I don't think that this is a basic constraint today, because no one is bound to follow IR 1089/2010 before 2017, right? So all metadata for interoperability in 2.12 are sort of "optional" until 2017 (Annex I) and 2020 (Annex II/III). Am I completely wrong with this?

2015-07-17 (Michael): see comment on #19

28 Eliane Roos 2.12.2 TG Req 45 te This is not a requirement from the TG. It is a requirement from the INSPIRE Regulation itself. And it is already said in the table above.

delete the requirement.

 

By the way, this is a condition difficult to check automatically (mandated if the gregorian calendar is not used).

In France, we decided to always mandate to provide it, with the default value = gregorian calendar. let's think about it...

2015-07-13 (Peter): see #27

2015-07-17 (Michael): see comment on #19

29 Eliane Roos 2.12.3 TG Req 46 te This is not a requirement from the TG. It is a requirement from the INSPIRE Regulation itself. And it is already said in the table above. delete the requirement.

2015-07-13 (Peter): see #27

2015-07-17 (Michael): see comment on #19

30 Eliane Roos 2.12.3   ge If I am correct, the INSPIRE regulation provide requirement regarding the encoding of the data (GML 3.2.1?).

Think about providing here a standardised way of entering the INSPIRE format within the Metadata.

For example :

Format name = GML

Format version = 3.2.1

 

moreover, it could be provided here a standardised proposal for other common format. For example :

 

name : SHP
version : 1.0
 
name : MIF/MID
version : 4.5
 
name : DXF
version : 2010
 
name : DWG
version : 8
 
name : GeoTIFF
version : 1.0

 

2015-07-13 (Peter): Do you mean that explicitely GML 3.2.1 is demanded by INSPIRE?

The way how to document the used format isn't given. And as I see it there's no technical reason to have a regulation for this. But a recommendation could be useful. The shown way (name=GML, version=3.2.1) is the most popular one I guess. Does anyone use it in a differing way?

 

2015-07-17 (Michael): How do we handle the relation between Media types and Formats see #11 I would prefer this list of formats instead of using media types.

Do we need to handle the combination of formats and versions in our TG? I would expect this to be part of a tool. But a validating service could check for possible versions that could be allowed for single format.

 

2015-08-19 (Peter): issue still open; implicitly to be followed as #39 on draft 04

31 Eliane Roos 2.12.4 TG req 47 te This is not a requirement from the TG. It is a requirement from the INSPIRE Regulation itself. And it is already said in the table above. delete the requirement. 2015-07-13 (Peter): see #27
2015-07-17 (Michael): see comment on #19
32 Eliane Roos 2.12.5 TG req 48 te same comment   2015-07-13 (Peter): see #27
2015-07-17 (Michael): see comment on #19
33 Eliane Roos 2.12.5 TG req 49 te

 

Is this restriction proposed by the TG? or is it written in the regulation?

I think the values should go in the domain line of the table.

2015-07-13 (Peter): this restriction comes from the chapters 8.2.5 of data specifications, where the elements concerning metadata for interoperability have been defined the first time;

yes, an addition in row domain would be useful.

2015-07-17 (Michael): see comment on #19

 

2015-09-10 (Peter): additional statement in maintained draft 05 (table -> domain)

34 Eliane Roos 2.12.6 descriptive results te I disagree with the idea to provide the descriptive result in the lineage. Semantically speaking it is not correct, and lineage is already used to provide other information within INSPIRE.

It would be better to use the quantitative result, and provide the descriptive statement in the "value" element of DQ_QuantitativeResult.

the "valueType" element of  DQ_QuantitativeResult should be fixed to "characterString"

 

Example :

 

<gmd:MD_Metadata …

   <gmd:dataQualityInfo>
     <gmd:DQ_DataQuality>
         …
         <gmd:report>
           <gmd:DQ_TopologicalConsistency>
               …
               <gmd:result>
                   <gmd:DQ_QuantitativeResult>
                      <gmd:valueType>
                          <gco:RecordType xlink:href="http://www.w3.org/2001/XMLSchema.xsd#string">String</gco:RecordType>
                      </gmd:valueType>
                      <gmd:valueUnit xlink:href="http://www.opengis.net/def/uom/OGC/1.0/unity"/>
                      <gmd:value>
                          <gco:Record xsi:type="xs:string">My descriptive result as a free text statement.</gco:Record>
                      </gmd:value>
                   </gmd:DQ_QuantitativeResult>
               </gmd:result>
           </gmd:DQ_TopologicalConsistency>
         </gmd:report>

     </gmd:DQ_DataQuality>
   </gmd:dataQualityInfo>

</gmd:MD_Metadata>

2015-07-13 (Peter): see #4: I already raised the question concerning an alternative there, but I thought of a DQ_ConformanceResult instead. I don't see a problem with DQ_QuantitativeResult if you got quantitative results at all. Have you? What will the mandatory valueUnit be when putting a descriptive result in element value?

=========> 2015-08-07 (Eliane). The probleme with the ConformanceResult is that you may not have any specification to mention. Regarding the valueUnit in the QuantitativeResult, you can use the standardised defaut value "unity" (as in my example, pointing on the OGC register of UoM) to say that no UoM is applicable here. (You may also have the case with a "real" QuantitativeResult)

 

2015-07-17 (Michael): I agree that Lineage is not the best place for descriptive results. But Lineage is anyhow currently defined in our technical guidlines as

a statement on process history and/or overall quality of the spatial data set
so I would think it's not completely wrong.
On the other hand, the use of a gmd:DQ_QuantitativeResult to describe descriptive results seems also to be an extention of the semantics which seems to be possible technically but semantically I have doubts.

from ISO 19115 value is defined as:

quantitative value or values, content determined by the evaluation procedure used

=========> 2015-08-07 (Eliane). Both descriptive result and quantitative results are quality results. So it is closer semantically speaking than the lineage (which may already be filled with a lot of other content).

 

2015-07-24 (Antonio): I agree with Eliane (see also my comment #18 on draft 01) and I agree with Peter that documenting quantitative results could be not easy. So, the explanation element in DQ_ConformanceResult could be used instead of lineage element.

 

 

2015-08-19 (Peter): issue still open; to be followed as #9 on draft 04; I will explain the proposal there

35 Eliane Roos 2.13.4 and 2.13.5 TG reco 36 and TG reco 38 te difficult to understand. rephrase for more clarity

proposal : "One instance of LI_Lineage is already used for documenting the lineage of the resource (see 2.7.1). Therefore the addition of these information into the same instance of LI_Lineage may be useful."

 

this is true only if the scope of the DQ_DataQuality instance is the same for the 3 information (processStep, source and lineage)

 
36 Eliane Roos 2.13.11 descrptive results te same comment than 34.  

2015-07-13 (Peter): this is somehow different from #34 because my alternative of DQ_ConformanceResult instead doesn't work here (there's no "specification" to be followed or violated). But the same question again: What will the mandatory valueUnit be when putting a descriptive result in element value?

=========> 2015-08-07 (Eliane). Regarding the valueUnit in the QuantitativeResult, you can use the standardised defaut value "unity" (as in my example, pointing on the OGC register of UoM) to say that no UoM is applicable here. (You may also have the case with a "real" QuantitativeResult)

 

 

2015-08-19 (Peter): issue still open; to be followed as #9 on draft 04

37 Eliane Roos 2.14   ge

I think metadata element that are already covered previously in the document (eg : resource locator, specification, degreee) should not be repeated here for SDS.

 

add a clause for SDS in existing paragraph Resource Locator, Specification, Degree, Reference Systems, conditions for access and use, responsible party

2015-07-13 (Peter): we had this discussion before and decided to have an own chapter for these people who are looking up information especially on SDS (the same with 2.12 and 2.13).

2015-07-17 (Michael): Ine and I discussed this and the overall document would be harder to understand  with all SDS as separate elements as separate elements. In draft 0.4 some of th descriptions as therefore now moved to existing sections.

38 Eliane Roos 2.14.3   ge a standardised measure, formalised as described in ISO 19138 (or 19157) could be provided for the 3 measures (

Availability

Performance

 
Capacity)
 

I think its usefull to do that, but i need some help in realizing that

 

2015-08-07 (Eliane) : I will try to provide some inputs before the physical meeting in Malmo

39 Eliane Roos 2.14.4 XML example te/ed the value for the codelist DCPList (httpGet) is not a value from the ISO codelist correct the example with one the value of the ISO codelist

what is the correct ISO codelist, there is discussion, see http://lab.usgin.org/groups/csw-debug-blog/iso-19139-service-metadata-record-srvdcplist-codelist-confusion

 

2015-08-07 (Eliane) As we want to be compliant with ISO 19115:2003 and ISO 19119, the correct ISo codelist is the one that you can find in ISO 19119 Amdt 1, (ie the values that are listed in the table just above the XML example).
(but I agree that there is an issue with this codelist since there is no official schema for them. This issue has been solved for ISO 19115-1, and ISo 19115-3)

 

40 Peter Kochmann 2.14.2.5 115: 18 Te I'm not sure whether gmx:Anchor is the right way here: Chapters 6 of Data specification demand an identifier for the used reference system. Is this the same as a gmx:Anchor? In my opinion a gmx:Anchor would have to be filled with a link to the EPSG-registry and not with the identifiers itself taken from the given table.  

I think a combination is possible, also the identifier is included;

<gmd:referenceSystemInfo>
<gmd:MD_ReferenceSystem>
<gmd:referenceSystemIdentifier>
<gmd:RS_Identifier>
<gmd:code>
<gmx:Anchor xlink:href="http://www.opengis.net/def/crs/EPSG/0/4258" xlink:title="ETRS89">4258</gmx:Anchor>
</gmd:code>
<gmd:codeSpace>
<gco:CharacterString>EPSG</gco:CharacterString>
</gmd:codeSpace>
</gmd:RS_Identifier>
</gmd:referenceSystemIdentifier>
</gmd:MD_ReferenceSystem>
</gmd:referenceSystemInfo>

 

 

2015-07-17 (Michael): This is a very complete (and useful)  way to document this. Should all be mandatory? Having all information set would be the most compliant.
But I may see a solution where xlink:href is mandatory but the rest of the elements are recommended optional elements (since they all can be extracted from the information at the xlink:href  url)

 

2015-08-07 (Eliane) : In France, we have the same XML implementation than proposed above.

 

2015-09-10 (Peter): considered in maintained draft 05 (see also #4 on draft 04)

41 Michael Östling 2.2.5   ge Are there any relation between the definitions of the namespace that should be used for spatial object identfication within data as it is defined in the Generic Model and the namespace defined in IR metadata ?
Question is: are there any need to explicitly document a namespace ? I just want to be assured we have not such requirements.