Task #2214

MIWP-8 (D) Integrate metadata for interoperability into the Metadata TG.

Added by Michael Östling almost 6 years ago. Updated over 5 years ago.

Status:ClosedStart date:24 Oct 2014
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Proposed change or action:

Description

This section has now been locked for editing and a draft version have been moved into the draft document.
See page:
https://ies-svn.jrc.ec.europa.eu/projects/metadata/wiki/DraftVersionsMIWP-8
Further discussions and comments should be done on the draft

 

*WIKI:* https://ies-svn.jrc.ec.europa.eu/projects/metadata/wiki/MIWP-8_(D)_Integrate_metadata_for_interoperability_into_the_Metadata_TG These elements are currently described in each dataspecifcation The task is to decide how to handle these metadata elements. These metadata elements are more related to Use instead of Discovery. Options that should be analyzed are putting these into TG Guidelines among other elements or adding them in separate section in TG or even separate document. It’s important that these elements are clearly flagged as special type of metadata mainly for machine consumption.


Subtasks

Bug #2238: Inconsistency on CRS metadataProposed

History

#1 Updated by Michael Östling over 5 years ago

  • Description updated (diff)

#2 Updated by Pawel Soczewski over 5 years ago

  • Description updated (diff)

#2: In my opinion, there is no logical inconsistency between the definitions in the IR and TG. The description of definition in IR says: "[...] a character string namespace uniquely identifying the context of the identifier code[..]". This clearly indicates that the unique resource identifier must contains a namespace and a unique identifier in it. The current definition in the TG specifies general provision of the IR take into account the requirements of the element domain (from IR). If is plan to change the implementation to MD_Metadata (only code element) in the TG need to explicitly the resource identifier consists of a namespace and identifier in it. This can be done either by leaving the current definition, or write some implementing roles in the "Comment" filed.

Sorry my mistake, I pasted into wrong topic :)

#3 Updated by Peter Kochmann over 5 years ago

I just uploaded another file. It shows the ISO19115-elements we want to consider in our maintained metadata profile für data. It's a bit difficult to read: for those who are not familiar with ISO19115 (most of our clients maintaining metadata) we resolved the structures of ISO and put all "called" elements into the place of the calling element. So everyone can see what information has to be entered finally. The most right colums N and O show the relevance of INSPIRE: the dark green coloured cells show the ones that are needed for interoperability.

#4 Updated by Peter Kochmann over 5 years ago

Concerning the Italian example: I can't read most of it, but I like it! It already looks like Technical Guidelines!

I'm not sure about the requirements with reference system info: Data specification names "186. MD_ReferenceSystem" and gives an example with code and codespace. Does that mean that we have to consider codespace as well at any time an so do we need to have it mandatory? In ISO 19115 itself codespace is optional.

 

#5 Updated by Peter Kochmann over 5 years ago

The most recently uploaded file is a draft of a mapping between metadata elements for interoperability focussed by INSPIRE (named in current release of TG metadata) and existing ISO 19115 (19157 FDIS 2011 for the last element).

I tried to have all involved elements nearby the INSPIRE metadata element to show precisely what is needed to register. Therefore I looked up the data specifications again (current release).

There are some question marks left:

  • Does a given example in data specifications mean that the mentioned elements are mandatory?
  • Which of the non-cited elements existing in ISO 19115 affected by structure shall be provided? Are we free to consider additional elements?
  • For topological consistency the data specifications do not name a required structure of ISO 19157 precisely. There are two ways: for reporting quantitative results or reporting descriptive results. I focussed on the last one. The other way would mean to consider additional elements. Did I choose the right way?

You can find my source of information in the most right column. Especially the rows with yellow marks have to be discussed.

#6 Updated by Peter Kochmann over 5 years ago

How do we deal with the following conflicts?

IR interoperability 1089/2010 clearly names the metadata for interoperability and doesn't see an exemption for particular annex themes. It's obvious that this has much more force than differences in technical guidelines (data specifications).

But we have to derive the details from data specifications! And these are different for themes of annex II and III from the ones of annex I regarding the terms for metadata for interoperability in chapter 8:

#1: spatial representation type is named mandatory in every data specification for annexes II and III, but in annex I it only can be found in theme addresses where it is named optional like the other theme specific metadata. The other themes in annex I do not mention spatial representation type at all!

--> consider the details of annex II and III data specifications for all themes of annex I as well (which means to have it mandatory and match it with ISO 19115 element No. 37)

#2: character encoding (which clearly aims at the encoding of data, not metadata!) is not mentioned in annex I theme cadastral parcels. The other annex I themes name it though they match it with ISO 19115 element No. 4, which is the character set for the metadata itself!

--> consider the details of annex II and III data specifications for all themes of annex I as well (which means to have it conditional). I furthermore propose to match it with ISO 19115 element No. 40; I examine the matching with element No.4 to be wrong.

#7 Updated by James Reid over 5 years ago

Re: the conflicts IMO the obligation given in 1089/2010 and its amendmnet should be binding - the DS errors are inconsitencies that DS themselves should address .

you are correct to distiguish encoding (metadata) and character encoding (dataset) - in the last doc I uploaded I mapped thss to 19115 element 40

 

#8 Updated by Antonio Rotundo over 5 years ago

@Peter: Unfortunately, the Italian guidelines are only in Italian. In the latest version we have used the same forms and notations for requirements, recommandations and XML examples as in the TG.

I think that we have to take in account the details derived by data specifications, but we have to propose requirements and recommendations (revisioned or eventually new) for the 6 metadata elements for interoperability also to resolve the different ways to treat them in the data specifications. Those requirements and recommendations will have to be transposed in all data specifications.

 

#9 Updated by Peter Kochmann over 5 years ago

@Antonio: Please don't worry about the Italian language! The main things can be recognised without problems. Where did you get the TG layout from? I guess we can use it here as well.

Deriving the details from DS is what I wanted to show with my latest Excel sheet: Taking all information (out of all DS), matching them with ISO and maybe in addition put some required ISO elements to it. Required means that there are mandatory elements in ISO that are not mentioned in DS. I already found such things in work for E-1.

#10 Updated by James Reid over 5 years ago

happy NY to one and all.

To reboot this discussion  I think we shoudl take Peters mapping tables and turn them into the TG style. Im not sure if we resolved how to address the ommissions/incorrect aspects of the imteroperbailiyy elements in each of the Data Specifications. My personal feeling is that the TG should have an Annex that extends what is currently there and details how to encode each of the 'core' inetroperability elements -  each DS should reference that by example. Theme specific interoperability elements should then be noted as additional to these 'core' items which are then at least cosnistent across all themes?

 

We need to move from discussion to actually producing some draft text...

#11 Updated by Peter Kochmann over 5 years ago

The information on metadata elements for interoperability is the same in all data specifications of annex II and III. Exception is "Population Distribution", there's no chapter 8 in it.

I guess this issue came up when the data specification of annex I themes was already finished, so they are not mentioned there the same way. But the content is nearly the same.

My proposal ist to look at all yellow fields in my latest Excel sheet and decide which (optional) elements are to be cut off. I think the best way is to go ahead with the mandatory or conditional elements of ISO 19115 only. That means we do not consider optional elements unless they are clearly named in the metadata chapter in data specification (implementing instructions and/or examples).

I'm still not sure how to deal with Data Quality – Logical consistency – Topological consistency: I considered only one possible way by now! In my opinion the purpose of this element is to describe topological consistency in abstract and not to have documentation of a certain measurement of this. So we don't have a quantitative result but only a descriptive one. Therefore the mentioned elements 9/67/68 of ISO 19157 would be enough!

#12 Updated by Christine Gassner over 5 years ago

Topological consistency

Colleagues in Austria especially working on meteorological data miss information on vertical resolution. In ISO19115 the vertical component can be implemented in the extent as an optional element. The INPSIRE TG on Metadata only refer to temporal extent.

This topic is mentioned here instead of E-1 because the discussion refers to Peter's statement above.

 

#13 Updated by Michael Östling over 5 years ago

Yes I think we should make sure this topic is just related to the six interoperability elements.
The others will as Christine mentions be handled in E1

 

 

#14 Updated by Peter Kochmann over 5 years ago

Christine is right to mention that in current TG metadata only coordinate and temporal matters are ruled to be documented by extent. Maybe there's a lack of regulation?

But this doesn't concern "metadata for interoperability": Coordinate and temporal references are named in IR interoperability and data specification to be documented by giving the code of a reference system. There's no way to give a code of a vertical reference system.

Of course everyone is free to have information on a vertical extent in metadata. We considered it in our new profile optionally as well. But I don't think that this should belong to the group of elements named "metadata for interoperabilty".

#15 Updated by Peter Kochmann over 5 years ago

I tried to maintain the template from James and fill in information on element characterSet.

#16 Updated by Antonio Rotundo over 5 years ago

I agree with Peter either for the approach with which the six metadata are to be handled and for the considerations about metadata elements on vertical extent. Also in the Italian profile the metadata elements on vertical extent are considered optionally. With regard to the metadata elements in the yellow fields, I think that the optional elements 206 and 208.2 could be cut off; for the others elements I need to examine deeper.

I have revised the example of XML encoding in the template in order to not confuse with the equivalent metadata element in MD_Metadata class.

 
 

#17 Updated by Peter Kochmann over 5 years ago

I'm not sure if everyone knew about it but me: data specifications on annex I themes were revised in 2014. I guess it was the maintenance to have all parts in chapter 8 similar concerning the list of Metadata elements defined in metadata regulation (8.1) and Metadata elements for interoperability (8.2).

So we do not have the conflict of the "old" chapter 8 in annex I themes any longer.

#18 Updated by Peter Kochmann over 5 years ago

I looked up some details in the metadata chapters of data specification looking for some hints how to handle the 19157 issue for "Topological consistency". We still have the problem that no one has implemented a catalogue system considering 19157-elements by now, right?

As far as I can overlook it, the use of 19157-elements only makes sense when using 19115-1 as well. By now we just have 19115 with a lot of  elements and structures for reporting data quality. Note 2 in every chapter  8.3.2 says that the following chapters 8.3.2.1 and 8.3.2.2 (which give the details and mapping to 19157-elements) may need to be updated once the XML schemas for 19157 have been finalised. Have they by now?

So for the situation today I suggest to concentrate on existing 19115-elements only and the chances to document data quality there! I think I can do the mapping of Topological consistency in 19115 instead of 19157 as well.

Later on MIG-T Metadata (2016/2017 ?) can handle the use of 19115-1 and 19157 together.

What do you all think?

#19 Updated by Peter Kochmann over 5 years ago

Peter Kochmann schrieb:

Later on MIG-T Metadata (2016/2017 ?) can handle the use of 19115-1 and 19157 together.

What I wanted to say: I don't see an implementation of 19157-structures today without changing to 19115-1 at the same time. So when the step to 19115-1 will be made, the matching of metadata for interoperability will have to be done again for 19115-1-elements. At the same moment the data quality elements will be used from 19157 instead of 19115.

#20 Updated by Michael Östling over 5 years ago

Yes, this is also my conclusion.  We can not include ISO19117 when TG Metadat is still focuwsed on ISO 19115.
I made note on this at the wiki-page for 19115-1
https://ies-svn.jrc.ec.europa.eu/projects/metadata/wiki/MIWP-8_(F)_Relation_to_ISO19115-1_2014

I have proposed a meeting with JRC to dicuss this with the editor of Technical Guidelines.
I think maybe the editors of Dataspecifications have assumed that we should transfer the TG Metadata to be adopted for 19115-1 already now.
So this means the dataspecifications have to be editited.

#21 Updated by Michael Östling over 5 years ago

A question on the placement of the 6 elements in main document.
Should they be placed at section 2.12 in TG document ?

If so can we keep the Annex B1 with some info related these elements so we don't have to move section B.2 to B.1
Or should we completely remove the the Annex B ?
 

Some small comments on word-doc MIG-MWG-Issue8-template-all-elements-stubbed.doc

I guess there is a copy/paste error in the word-doc mentioning that Referencesystem is needed if UTF8 is not used.
Is that is a copy from the encoding section or does it exist such a requirement ?

 

#22 Updated by Peter Kochmann over 5 years ago

Michael Östling schrieb:

Some small comments on word-doc MIG-MWG-Issue8-template-all-elements-stubbed.doc I guess there is a copy/paste error in the word-doc mentioning that Referencesystem is needed if UTF8 is not used. Is that is a copy from the encoding section or does it exist such a requirement ?  

I understand it to be just a frame. We have to fill in the details for each of the six elements and correct the copied content. The UTF-condition applies to character encoding only!

#23 Updated by Peter Kochmann over 5 years ago

Michael Östling schrieb:

Yes, this is also my conclusion.  We can not include ISO19117 when TG Metadat is still focuwsed on ISO 19115. ... So this means the dataspecifications have to be editited.

This will be thrilling! I already did some reserach to build up a mapping for element "Topological consistency" with 19115 instead of 19157 and found a problem: Only one of the two given ways for documenting data quality (quantitative results or descriptive results) can be done in 19115 as well (the quantitative one). There's no matching structure or element for the descriptive way!

Maybe we can consider the quantitative results only as long as data quality will be mapped to 19115?

 

#24 Updated by Peter Kochmann over 5 years ago

Michael Östling schrieb:

A question on the placement of the 6 elements in main document. Should they be placed at section 2.12 in TG document ? If so can we keep the Annex B1 with some info related these elements so we don't have to move section B.2 to B.1 Or should we completely remove the the Annex B ?

I think they should be placed in chapter 2 in addition to the already documented elements from IR metadata. Section 2.12 sounds good. But will we have 2.12 up to 2.17 for the six elements or 2.12.1 up to 2.12.6?

We have to consider the furthermore elements from E-1 (theme specific metadata) to be documented in chapter 2 as well!

#25 Updated by Antonio Rotundo over 5 years ago

I'm agree with Peter too:  the use of 19157 metadata elements only makes sense when using 19115-1 as well. In fact in the introduction of 19115-1 standard one of the major change is just " Data quality was moved to ISO 19157 (to be published)". If we consider 19115 (as we are doing now) we have to consider the metadata elements in the Data Quality Information package.

I think that Annex B1 could become section 3 (Metadata elements for Interoperability) and we remove annex B2.

I uploaded a new file in which I have inserted revisions, comments and proposals (also for data quality elements). As required by Peter, we have to decide on the optional metadata elements (yellow fields in Excel file posted by Peter) in order to complete requirements and recommendations.

 

#26 Updated by Peter Kochmann over 5 years ago

I updated (and uploaded) my Excel sheet for the six elements and considered ISO 19115 now instead of 19157 for Topological consistency. But this works for quantitative results only! Descriptive ones can't be matched with 19115.

#27 Updated by Antonio Rotundo over 5 years ago

As I have shown in the XML examples in the updated template, the only two alternatives for the topological consistency (using 19115) are: DQ_QuantitativeResult and DQ_ConformanceResult (already used for the conformity with the implementing rules). In this last class there is the element "explanation" (free text) that could be used for the description. If so, we need to consider whether in case of topological consistency speaking of specifications makes sense (which INSPIRE specifications? external specifications?)

#28 Updated by Peter Kochmann over 5 years ago

Antonio Rotundo schrieb:

I added a new file in which I have inserted revisions, comments and proposals (also for data quality elements). As required by Peter, we have to decide on the optional metadata elements (yellow fields in Excel file posted by Peter) in order to complete requirements and recommendations.  

Using DQ_ConformanceResult and giving the Generic Network Model as a specification (as Antonio did in his Word draft) could be a possible way. We would have the mandatory element explanation in addition to give descriptive information as well.

#29 Updated by Ine de Visser over 5 years ago

Another issue, in the tabel for the Spatial Representation Type the MD_SpatialRepresentation  class is used.

This is in my opinion not correct, the spatialRepresentationType (ISO nr 37) element is part of the MD_DataIdentification class. We use this element tu fullfill this requirement.Much easier in use!

#30 Updated by Peter Kochmann over 5 years ago

Ine de Visser schrieb:

Another issue, in the tabel for the Spatial Representation Type the MD_SpatialRepresentation  class is used. This is in my opinion not correct, the spatialRepresentationType (ISO nr 37) element is part of the MD_DataIdentification class. We use this element tu fullfill this requirement.Much easier in use!

Which table did you look up? I think it's clear that we use spatialRepresentationType (37).

The MD_SpatialRepresentation class will be used in theme specific metadata in E-1 for explicitly named information on theme elevation only.

#31 Updated by Ine de Visser over 5 years ago

ah I see it, it's the theme specific table but it has a tab metadata interoperability

#32 Updated by Peter Kochmann over 5 years ago

Oh yes, due to history ...

I'll fix it for the next version!

#33 Updated by Peter Kochmann over 5 years ago

As we discussed at last meeting I tried to take ISO 19115 elements only for matching the Topological Consistency element given in Data specifications designated for ISO 19157.

I already mentioned: For quantitative results there is no problem. All required structures and elements can also be found in existing ISO 19115.

For reporting descriptive results the situation is as follows: There is no DQ_DescriptiveResult in ISO 19115. This will be new in ISO 19157. I see a chance when looking at the condition for this metadata-for-interoperability element at all: It is required when not having centreline topology as given in Generic Network Model (if I understood that right, please tell me if not!). Therefore one option could be to see the "Generic Network Model" as a kind of specification and take DQ_ConformanceResult for that to have the explanation element for free text. To give a specification and the pass-statement is mandatory when using DQ_ConformanceResult but that could be filled with "Generic Network Model" itself and the Boolean-value "no".

The alternative could be to ignore the descriptive way at all and for now focus on quantitative results only. Considering the coming use of ISO 19157 and 19115-1 the damage cannot be that big.

I uploaded a new Excel file which includes the DQ_ConformanceResult for descriptive results.

#34 Updated by Marc Leobet over 5 years ago

Dear all, as asked I share with you the content of the FR recommandations for Topological consistency.

INSPIRE requirements in Regulation n°1089/2010: 

  1. Topological Consistency: Correctness of the explicitly encoded topological characteristics of the data set as described by the scope.

    This element is mandatory only if the data set includes types from the Generic Network Model and does not assure centreline topology (connectivity of centrelines) for the network. 

Comments

Practically, are concerned the data compliant with the requirements of INSPIRE and under the network model (hydrography, transportation, utilities). The technical guidelines for INSPIRE themes define the measures to be applied according to the themes. For example:
- invalid number of overlays,

- number of pending nodes (undershoot, overshoot)
- number of self-instersections,
- number of self-overlays.
Most datasets will not be affected.

Example :

For example, for a dataset of theme Hydrography, the result of the quality measure "Number of faulty connections point curve" will be expressed as follows (according to the first table in clause 7.2.3 of Technical Guide Hydrography theme):
Measure name: number of faulty connections point curve
Measure identifier: 21 (ISO 19138)
Measure Description: A point-curve connection exists where different curves touch. These curves have an intrinsic topological relationship that shall reflect the true constellation. If the point-curve connection contradicts the universe of discourse, the point-curve connection is faulty with respect to this data quality measure. The data quality measure counts the number of errors of this kind.
Result:
Value Type: Integer
Unit of measure: unity
value: 12

urve connection is faulty with respect to this data quality measure. The data quality measure counts the number of errors of this kind.
Result:
Value Type: Integer
Unit of measure: unity
value: 12

Technical reference

Xpath ISO 19115

dataQualityInfo/*/report

XML example

<gmd:MD_Metadata …

<gmd:dataQualityInfo>
<gmd:DQ_DataQuality>
<gmd:scope>
<gmd:DQ_Scope>
<gmd:level>
<gmd:MD_ScopeCode codeListValue="dataset" codeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/Codelist/gmxCodelists.xml#MD_ScopeCode">dataset</gmd:MD_ScopeCode>
</gmd:level>
</gmd:DQ_Scope>
</gmd:scope>
<gmd:report>
<gmd:DQ_TopologicalConsistency>
<gmd:nameOfMeasure>
<gco:CharacterString>number of faulty point-curve connections</gco:CharacterString>
</gmd:nameOfMeasure>
<gmd:measureIdentification>
<gmd:MD_Identifier>
<gmd:code>
<gco:CharacterString>21 (ISO 19138)</gco:CharacterString>

</gmd:code>
</gmd:MD_Identifier>
</gmd:measureIdentification>
<gmd: measureDescription >
<gco:CharacterString>A point-curve connection exists where different curves touch. These curves have an intrinsic topological relationship that shall reflect the true constellation. If the point-curve connection contradicts the universe of discourse, the point-curve connection is faulty with respect to this data quality measure. The data quality measure counts the number of errors of this kind. </gco:CharacterString>
</gmd:measureDescription>
<gmd:result>
<gmd:DQ_QuantitativeResult>
<gmd:valueType>
<gco:RecordType xlink:href="http://www.w3.org/2001/XMLSchema.xsd#integer">Integer</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:integer">12</gco:Record>
</gmd:value>
</gmd:DQ_QuantitativeResult>
</gmd:result>
</gmd:DQ_TopologicalConsistency>
</gmd:report>

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

</
gmd:MD_Metadata>

Implementing instructions

When the result type does not use an unit of measurement, the value of 'unity' can be used by default for this metadata element, as in the example above.


 

#35 Updated by Marc Leobet over 5 years ago

 The chapter of FR TG about Temporal reference is too long to be copy here, but I think that the XML is well-known and shared. Otherwise, please look at French_Technical_Guidelines_for_INSPIRE_Metadata_v1.1.doc, pages 31 to 36.

Abstract:

"After a general paragraph explaining the INSPIRE requirements for the Temporal Reference field, this chapter details the metadata element Temporal extent (VI.1), then the reference dates (date of publication (VI.2.1) Date of creation (VI.2.2) and Date of last revision (VI.2.3)), and finally the temporal reference system (VI.3)."

We give an Example 1, data updated continuously as it was asked for monitoring water or air quality.

To be compliant with ISO 19115, we have separated Date of creation, of last revision, of publication, which are mandatory for one of them, from Temporal extent, which is optionnal.

Recommandations are :

 

  1. It is recommended to provide at least one reference date (date of creation, last revision or publication). (see VI.2 Reference dates)

  2. The temporal extent (see VI.1) is an optional element.

 and :

  1. Do not enter date of last revision if the resource has just been created and therefore it has not been revised.

  2. At least, enter the date of creation of the data.

 

Best regards 

#36 Updated by Michael Östling over 5 years ago

Peter Kochmann wrote:

As we discussed at last meeting I tried to take ISO 19115 elements only for matching the Topological Consistency element given in Data specifications designated for ISO 19157. I already mentioned: For quantitative results there is no problem. All required structures and elements can also be found in existing ISO 19115. For reporting descriptive results the situation is as follows: There is no DQ_DescriptiveResult in ISO 19115. This will be new in ISO 19157. I see a chance when looking at the condition for this metadata-for-interoperability element at all: It is required when not having centreline topology as given in Generic Network Model (if I understood that right, please tell me if not!). Therefore one option could be to see the "Generic Network Model" as a kind of specification and take DQ_ConformanceResult for that to have the explanation element for free text. To give a specification and the pass-statement is mandatory when using DQ_ConformanceResult but that could be filled with "Generic Network Model" itself and the Boolean-value "no". The alternative could be to ignore the descriptive way at all and for now focus on quantitative results only. Considering the coming use of ISO 19157 and 19115-1 the damage cannot be that big. I uploaded a new Excel file which includes the DQ_ConformanceResult for descriptive results.

I think the use of explanantion-element could be useful. We have to find an alternate solution for ISO19157 constructs for this year. Using the explanantion field for DQ_ConformanceResult is I think the best way if we don't want to make an extension to ISO19115 qualityreports. I think your solution in the Excelfile could work.

#37 Updated by Peter Kochmann over 5 years ago

Maybe there's another chance for handling the descriptive results: In MIWP-8 (E-1) Ine de Visser wrote:

I found this recommandation in the dataspec on elevation; Recommendation 39 Following the ISO/DIS 19157 Quality principles, if a data provider has a procedure for the quality management of their spatial data sets then the appropriate data quality elements and measures defined in ISO/DIS 19157 should be used to evaluate and report (in the metadata) the results. If not, the Lineage metadata element (defined in Regulation 1205/2008/EC) should be used to describe the overall quality of a spatial data set. So the discriptive quality results should be placed in the lineage element

I checked it and saw that this recommendation can be found in every data specification in chapter "8.1.2 Lineage". It's a kind of reverse conclusion for our problem to match the quantitative and measured elements (designated in ISO 19157) to the existing ISO 19115 elements and put the descriptive ones (not matching ISO 19115 exactly) to the more general lineage element.

So this could be a possible way for Topological consistency too.

#38 Updated by Michael Östling over 5 years ago

I wonder about the interoperability element Encoding. This is mapped against MD_Format.
When checking examples in existing data specifications the examples show eg:
gmd:MD_Format>
---<gmd:name>
------<gco:CharacterString>SomeApplicationSchema GML application schema</gco:CharacterString>
---</gmd:name>
---<gmd:version>
------<gco:CharacterString>3.2rc1 </gco:CharacterString>
---</gmd:version>
---<gmd:specification>
------<gco:CharacterString>D2.8.I.9 Data Specification on Protected sites – Technical Guidelines</gco:CharacterString>
---</gmd:specification>
</gmd:MD_Format>

 

We handle here mainly the application schema and indirectly the format GML.
My opinion is that it is not sematically correct to use this element for defining the application shema.
I would think the above info should go into Applicationshame info and Format shuold be eg: name:GML version:3.2
Please correct me if you think I'm wrong here.
The above instructions are now included in all data specifications so it is maybe to late to change anything on this right now.

#39 Updated by Michael Östling over 5 years ago

Peter Kochmann wrote:

Maybe there's another chance for handling the descriptive results: In MIWP-8 (E-1) Ine de Visser wrote: I found this recommandation in the dataspec on elevation; Recommendation 39 Following the ISO/DIS 19157 Quality principles, if a data provider has a procedure for the quality management of their spatial data sets then the appropriate data quality elements and measures defined in ISO/DIS 19157 should be used to evaluate and report (in the metadata) the results. If not, the Lineage metadata element (defined in Regulation 1205/2008/EC) should be used to describe the overall quality of a spatial data set. So the discriptive quality results should be placed in the lineage element I checked it and saw that this recommendation can be found in every data specification in chapter "8.1.2 Lineage". It's a kind of reverse conclusion for our problem to match the quantitative and measured elements (designated in ISO 19157) to the existing ISO 19115 elements and put the descriptive ones (not matching ISO 19115 exactly) to the more general lineage element. So this could be a possible way for Topological consistency too.

I had a discussion yesterday (2015-02-04) with Michael Lutz and Robert Tomas on the problems with the references to ISO 191157 in data specifications.
We there discussed that we needed a way to map descriptive qualityreports to ISO 19115. Robert was quite clear that putting the information only in lineage
should not be sufficient.  I have not completely grasped the type of descriptive quality reports to handle so if we could generate some examples we could see if using
lineage could be used. I could guess that we would need multiple descriptive reports for a resource. Then we maybe need multiple DQ_DataQuality elements ?

#40 Updated by Peter Kochmann over 5 years ago

Michael Östling schrieb:

I wonder about the interoperability element Encoding. This is mapped against MD_Format. When checking examples in existing data specifications the examples show eg: gmd:MD_Format> ---<gmd:name> ------<gco:CharacterString>SomeApplicationSchema GML application schema</gco:CharacterString> ---</gmd:name> ---<gmd:version> ------<gco:CharacterString>3.2rc1 </gco:CharacterString> ---</gmd:version> ---<gmd:specification> ------<gco:CharacterString>D2.8.I.9 Data Specification on Protected sites – Technical Guidelines</gco:CharacterString> ---</gmd:specification> </gmd:MD_Format>   We handle here mainly the application schema and indirectly the format GML. My opinion is that it is not sematically correct to use this element for defining the application shema. I would think the above info should go into Applicationshame info and Format shuold be eg: name:GML version:3.2 Please correct me if you think I'm wrong here. The above instructions are now included in all data specifications so it is maybe to late to change anything on this right now.

I think you're right: We also have MD-Format in general for documenting the technical language the data are given in. And we do not use specification in this context by now.

<gmd:distributionFormat>
  <gmd:MD_Format>
    <gmd:name>
      <gco:CharacterString>GML</gco:CharacterString>
    </gmd:name>
    <gmd:version>
      <gco:CharacterString>3.2.1</gco:CharacterString>
    </gmd:version>
  </gmd:MD_Format>
</gmd:distributionFormat>
 

The definition of this element in IR 1089/2010 says the same: "Description of the computer language ..." though the focus for interoperability may be a bit different: I assume the intention was to document the schema of the data in addition. But this can be given in conformity statement. And there's a whole structure in ISO 19115 called MD_ApplicationSchemaInformation for that purpose as well.

#41 Updated by Peter Kochmann over 5 years ago

Michael Östling schrieb:

I had a discussion yesterday (2015-02-04) with Michael Lutz and Robert Tomas on the problems with the references to ISO 191157 in data specifications. We there discussed that we needed a way to map descriptive qualityreports to ISO 19115. Robert was quite clear that putting the information only in lineage should not be sufficient.  I have not completely grasped the type of descriptive quality reports to handle so if we could generate some examples we could see if using lineage could be used. I could guess that we would need multiple descriptive reports for a resource. Then we maybe need multiple DQ_DataQuality elements ?

Yes, this could be a problem. The designated way for data quality reports using ISO 19157 allows multiple results in one DQ_DataQuality/DQ_Element though each DQ_DescriptiveResult has only one statement which is not multiple. Using ISO 19115 we would have to call DQ_DataQuality itself multiple, because the following call on LI_Lineage is not multiple and in LI_Lineage itself the statement is not multiple too.

By the way: Using lineage for the descriptive results would also mean losing the type of quality statement! The differences whether it is e.g. DQ_DomainConsistency or DQ_TopologicalConsistency can be expressed in DQ_Element only. It would have to be considered as free text in the lineage statement then!

#42 Updated by Michael Östling over 5 years ago

Some comments on queries in Excel-file from 2015-01-29

Encoding.Specification
As the technical guidlines have mapped encoing to MD_Format I think this  has to be mandatory

Data quality - logical consistency:
For the elements

- nameOfMeasure
- measureIdentification
- measureDescription

From my understanding if nameOfMeasure is taken from ISO 19138 then the ID and description will exist in ISO19138.
But if NameOfMeasure is outside ISO19138 then I would expect that  measureIdentification and measureDescription also have content.
But these quality reports are very little used as I have seen so it would be great if we could consult some with wider experience of quality-reporting.

Coordinate reference system
I added a comment on the the Coordinate Reference system for SDS that would  be great if we could clarify

When it comes to the code we say it can either he handled as text or Anchor in code element.
But should we mandate that the code should  be a referenceable identifier like specified in SDS TG 3.1

<gmd:code>
   <gco:CharacterString>http://www.opengis.net/def/crs/EPSG/0/28992</gco:CharacterString>
</gmd:code>

and not only the epsg-code eg; EPSG:28992?


 

#43 Updated by Peter Kochmann over 5 years ago

As discussed before I finished the Excel sheet and considered the mandatory and conditional elements of ISO 19115 only and in addition the elements given by implementing instructions or examples in chapter 8 in data specifications.

I'm still not sure how to show the content of the Excel sheet in a suitable style for the TG draft. At least we could have a describing text and name the XPaths explicitly.

See Wiki page to find the uploaded file.

#44 Updated by Peter Kochmann over 5 years ago

Any ideas how to deal with the specification element in MD_Format finally? I skipped it in the latest Excel sheet due to concentrating on explicitly named elements.

I do not think we should have it mandatory because there is no implementing instruction that says it. The example in data specification has been discussed before: an application schema should be given using the designated MD_ApplicationSchemaInformation element instead.

Is it argument enough that it is given in an (inappropriate) example? Of course we can consider it optional like ISO itself does.

#45 Updated by Antonio Rotundo over 5 years ago

I'm agree with not considering at all the specification element and considering only the mandatory elements of ISO 19115 for that class (MD_Format) name and version. 

#46 Updated by Ine de Visser over 5 years ago

I also agree to that solution

#47 Updated by Peter Kochmann over 5 years ago

Due to the latest discussion I removed specification from MD_Format (metadata element "encoding") and I tried to integrate the XPaths. I uploaded a maintained Excel file on the wiki page above. Please have a look and tell me if it wasn't successful.

#48 Updated by Antonio Rotundo over 5 years ago

I think that, given the meaning of the lineage element (as a process history) by ISO 19115 and by INSPIRE IR for Metadata, it is not suitable to report the descriptive elements of topological consistency.
Or rather, the element is already included in the INSPIRE metadata set; about it, the TG Requirement 26 states that there must be one lineage element and TG Recommendation 16 suggests to use it to evaluate and report the results concerning specific data quality elements and measures .

For this reason, I think that:

1) we could use that element for reporting descriptive elements of topological consistency as suggested by Peter but without adding it in the specific section of metadata for interoperability, adding only specific recommendations instead
OR
2) we could use another more specific element in the same class (DQ_Element), measureDescription (free text).
I revised and uploaded the Excel file on the wiki page above with the second option (look at the yellow field).

 

#49 Updated by Michael Östling over 5 years ago

  • Description updated (diff)

#50 Updated by Michael Östling over 5 years ago

  • Status changed from Submitted to Closed

Also available in: Atom PDF