DraftTGMetadata v02

 

Draft version of Technical Guidelines Metadata v.02

Updated 2015-05-06

The document can be reached here
Note 1
(we have made  some last moment updates in chapter 2.12 so use the latest added document) 

Note 2
There also exist an alternative solution for implementation of chapter 2.2.6 Coupled resources
This alternative approach is documented in a separate document

Note 3

Update 20-5-2015

 2.14 Metadata for interoperable spatial data services is here seperate available

 

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.12     Metadata for interoperability

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.


Type: Ed = Editorial, Te = Technical, Ge = General

ID Comment by Clause/
SubClause/
Annex
Page:
Line No
Type Comment______________________________ Proposed solution____________________ Comments______________________________________________
1 Peter Kochmann 2.11.3 74: 20 Ed/Ge As the list of ISO 639-2 has been limited by INSPIRE to official languages only, I propose to avoid the statement "Regional languages also are included in this list".

The list of all the codes isThese values are part of the list defined at http://www.loc.gov/standards/iso639-2/.

2015-05-20 (Peter): done for next draft (03). I also added a TG Requirement box for this.

 

Ther are 2 variants of  639-2 - 'bibliographic' (/B) and terminologidcal (/T). While most languages are given one code by the standard, twenty of the languages described have two three-letter codes, a "bibliographic" code (ISO 639-2/B), which is derived from the English name for the language and was a necessary legacy feature, and a "terminological" code (ISO 639-2/T), which is derived from the native name for the language. 

In general the T codes are favored; ISO 639-3 uses ISO 639-2/T.

I suggest therefore we be explicit and stipluate that we are referring to ISO 639-2/T.

 

Ive done some more invetsigation into this - 

The other EC countries that should care/be aware is the Czech Republic, because Czech has different B & T codes, and Germany, Netherlands (dut/nld), Greece (gre/ell), France (fre/fra), Iceland (ice/isl), Slovakia (slo/slk)
The Slovakian national discovery service uses 'slo'. The German ones I've found use 'ger'.
 
Other language communities (countries?) that should care (because their B/T codes differ) are Albanian, Armenian, Basque, Georgia, Chinese, Georgian.
(Oddly, the whole thing contradicts the EC's own list of language codes - http://publications.europa.eu/code/en/en-5000800.htm - which uses the two letter codes)
 
CONCLUSION - given that in practise we have a mix of B & T codes in use I'd suggest we allow either but recommned that the variant used be made explicit.
 
2015-06-10 (Martin): As in the current TGs the B-variant is explicitly mentioned we should not change this to ensure backwards compatibility.
 
2015-06-14 (Michael Ö) When inspecting the current use of B- or T-codes, I see that France, Germany and Netherlands all use B-codes in their national recommendations. So i think the use of B-codes is valid. But as Peter notes above ISO 639-3 uses ISO 639-2/T.
I see also in ISO 19139 when examples of using PT_Locale is examplified that ISO 639-2/T are used. So we have in future to take care of this some way.
ISO 19115-1 recommends using ISO 639-2 without and reference to B or T
 
2015-06-15 (Peter): I agree on keeping /B as it has been in TG before and what still is content of draft 03 as far as I edited it. The statement "But as Peter notes above ISO 639-3 uses ISO 639-2/T." isn't right because it wasn't my comment! I guees I remember it was James?
 
2 Peter Kochmann 2.2.5 25: 13 Ed/Ge

The field comment is empty by now.

Because of the necessary strategy to have a queryable information for coupled ressource and the relation to 2.2.6 we should have a comment on this here. It's also the reason why we do not use RS_Identifier here any longer.

"The unique resource identifier is needed to provide a queryable information when following data-service-coupling (see also 2.2.6). Therefore it is necessary to have the identifier itself together with the namespace in element code. The use of RS_Identifier (with a separate element codeSpace) is not suitable here." 2015-05-28 (Michael Ö) Added to document.
3 Peter Kochmann 2.2.5 27: 6 Ed In the XML example the MD_DataIdentification-object carries an id "lakes". I guess this follows a former example and is no longer suitable. remove id="lakes" 2015-05-28 (Michael Ö) Changed in document
4 Martin Seiler 2.9 56:20 Ed The correct iso 19139 spellling of the element names should be used consistently 'useLimitation' instead of 'Uselimitation' 2015-05-28 (Michael Ö) Changed in document
5 Martin Seiler 2.2.5 25:13 Ge The domain in the table is referencing part of the ISO 19115. That is already referenced in the line above and not a domain. In all (?) other sections a domain is specified explicitly. Change the domain to 'URI (IETF RFC 3986)' 2015-05-07 (Peter): While adding chapters 2.12 and 2.13 we started to mention the depending elements in complex structures more detailled here. I propose to underline that only element code is needed (with the designated content of type URI).

2015-05-28 (Michael Ö) Changed in document
 
6 Martin Seiler 2.2.5 25:16 Ed Change wording. 'The code property is required. It is a URI that consists of a namespace and an identifier that is unique within the context of the namespace'
2015-05-28 (Michael Ö) Changed in document
7 Martin Seiler 2.2.6 27:39 Ed Change wording to be more precise. '... by reference, providing the URI (see 2.2.5) for the datasets...'


2015-05-28 (Michael Ö) I expect this is updated already ?

2015-06-10 (Martin): Integrated in draft for v03
 

8 Martin Seiler 2.2.6 27:41 Ge The recommendation to also provide a URL is misleading. We have to provide the URI here. The URI can be a URL. The IRs are quite clear about this in section B 1.6. Delete the sentence 'Recommended is also...'

2015-05-28 (Michael Ö) I expect this is updated already ?

2015-06-10 (Martin): Integrated in draft for v03

2015-06-14 (Michael Ö) This is a section where it exists different opinions. The IR do indeed  request a Unique Resource Identifier but the domain for OperatesOn is a reference to a MD_DataIdentification object. It can be argued that having a reference to a MD_DataIdentification object it can then be used to resolve the identifier. But let's keep the suggested changes here and create a separate doc where the options can be discussed and the alternatives can be described in more detail.

9 Martin Seiler 2.2.6 27ff.: Ge/Te

The whole section still seems to be confusing to the reader. We should have a focus on a technical implementation of the requirements from the IR here and not try to cover all cases in existing implementations.

Discovery services will need to be able to evaluate both operatesOn attributes. Hence we should give a clear guidance on possible implementations of the IRs. Providing a GetRecordById request here is != providing the URI of the dataset!

If the URI is a URL it should be provided in @xlink, as a system would expect a resolvable Link here.

- Describe the (equally) possible implementation both through @uuidref and @xlink.

- in both cases the URI of the dateset has to be provided

- Recommendation: If the URI is a (resolvable) URL it should be provided in @xlink otherwise it should be provided in @uuidref

- explain that @uuidref has a misleading name. This can be any URI, and not just uuids.

2015-05-28 (Michael Ö) I think we still have a situation where the IR specifying different than then OperatesOn is aimed for.

I think we need to take the current solutions discussed to a wider group for response.

 

2015-06-14 (Michael Ö) This is a section where it exists different opinions. The IR do indeed  request a Unique Resource Identifier but the domain for OperatesOn is a reference to a MD_DataIdentification object. It can be argued that having a reference to a MD_DataIdentification object it can then be used to resolve the identifier. But let's keep the suggested changes here and create a separate doc where the options can be discussed and the alternatives can be described in more detail.

10 Kristian Senkler 2.2.6 25ff Te

The way we use the attribute "uuidref" is not compliant with ISO 19118. 

Either explain the semantics and why we break it or make the usage compliant with ISO 19118. 

As per ISO 19118, A.5.5.2, “[…] The “uuidref” attribute shall be used to refer to an object within the universe of an application domain. […]”. By example, this means that an elements defined as:

<first id="i05" uuid="dce:F6A120B3"> … </first>

can be referenced elsewhere by a new element like this:

<second uuidref="dce:F6A120B3"/>

2015-05-28 (Michael Ö) Yes I think the way OperatesOn on have been implemented in ISO 19119 was done when it was assumed that dataset metadata for tightly coupled services could/should ? be included in same metadata record as the service metadata.  That is not the case now when dataset metadata is published as a separated record.
11 Kristian Senkler 2.2.6 26ff Te If we recommend to use GetRecords, this operation shall be mandatory on the part of INSPIRE Disvovery Services Make a recommendation to INSPIRE Disvovery Services Team to update the spec accordingly.

2015-05-28 (Michael Ö) This is yet a change in TG that will influence other TG. We should add this to list.

2015-06-14 (Michael Ö)

12 Ine de Visser 2.12.1 75/76 Ge In the SDS metadata discussion on CRS other domain and example are proposed see https://ies-svn.jrc.ec.europa.eu/issues/2307 integrate this to one solution fitting both

2015-05-19 (Peter): There are comments on draft 01 aiming at the same issue. For metadata for interoperability we have to consider the list of reference system URI's given in Data specifications anyway. So I propose to have it finished here and take it into the coming SDS chapter similarly.

 

2015-05-20 (Peter): I finished new content for 2.12.1 that can be seen in the next draft (03).

13 Geraldine Nolf whole document   Ed / Te / Ge Comments in document: Remarks.docx  

All my comments in one doc, since I'm not good yet in this tool and its layout, sorry for that.

 

2015-05-20 (Peter): DQ_Usability is hidden in chapter 7 of Data specifications on Buildings, Oceanographic geographical features and Sea Regions, but indirectly given in chapters 8.3 because it's named "Other DQ element from chapter 7" there. The problem here again is that it focusses on ISO 19157 structures we don't have in ISO 19115. If really needed today we could use the same way (using lineage for the descriptive results) as we already do in 2.12.6 and 2.13.11.

Are there some more issues hidden in chapter 7? Is anyone willing to go through the Data specifications looking for this?

 

2015-06-15 (Peter): my latest research on Data specifications raised a new question: How do we deal with differences between chapters 8.3 (theme-specific metadata --> data quality) and chapters 7.1 (Data quality elements)? There are some issues to be found only in chapter 7.1 without being mentioned in chapter 8.3 ((also not implicitly). Are they out of focus? What to do with data quality elements defined at spatial object-level in chapter 7.1? I understand that we only have to take care for metadata concerning dataset-level!

14 Geraldine Nolf 2.9 67:55 Te The example of the access constraints is in fact a use constraint. We need to foresee another example. In General on the Constraints we have to foresee more explanation between "use" and "acces" eventually via examples.
15 Antonio Rotundo 2.9.1 54:4-8 Te Limitations on public access can't be only represented by the metadata element MD_LegalConstraints.otherConstraints, because it is declared "contitional" in ISO 19115 depending by the value taken by the element MD_LegalConstraints.accessConstraints ("The otherConstraint element of MD_LegalConstraints shall be non-zero (used) only if accessConstraints

and/or useConstraints elements have a value of “otherRestrictions”, which is found in the MD_RestrictionCode

codelist"). As far as the element otherConstraints is concerned, change wording.

"TG Requirement 31 - Limitations on public access shall be represented by at least one of these metadata elements:

- MD_LegalConstraints.accessConstraints
- MD_LegalConstraints.otherConstraints
- MD_SecurityConstraints. classification.
To be compliant with ISO 19115, if MD_LegalConstraints. otherConstraints is used, then MD_LegalConstraints.accessConstraints have to be set at the value "otherRestrictions"" 

The comment and the solution don't concern the updates in document, but the current implementation guidelines (Antonio)

Michael Ö 2015-05-21 I think the conditions for otherConstraints is the opposite. The Condition in ISO 19115 is
accessConstraints or useConstraints equal “otherRestrictions”?  This means as I see it that rule is that it
Shall be provided if accessConstraints or useConstraints is set to “otherRestrictions.”
So it is not mandatory to set otherRestrictions in accessCosntraints or useConstraints.
The conformance rules in ISO19139 Table A1 also have this rule on row 7
But this is not 100% clear so we should discuss it.

 

2015-05-21 (Peter): In ISO 19115 at chapter 6.3.2.3 the following is ruled: "The otherConstraint element of MD_LegalConstraints shall be non-zero (used) only if accessConstraints and/or useConstraints elements have a value of “otherRestrictions”, which is found in the MD_RestrictionCode codelist."

16 Antonio Rotundo 2.9.1 53:53 Te see comment 15 "If there are no limitations on public access, set the metadata element MD_LegalConstraints.accessConstraints at the value "otherRestrictions" and use the free text available MD_LegalConstraints.otherConstraints to enter "No limitations" in the language used for the metadata" The comment and the solution don't concern the updates in document, but the current implementation guidelines (Antonio)

Michael Ö 2015-05-21 See comment on line 15
17 Antonio Rotundo 2.9.3 59:13 Te To be compliant with ISO 19115, the element otherConstraints can be used only if accessConstraints="otherRestrictions". See also comment 15.  At the text of TG requirement 34 add: "To be compliant with ISO 19115, MD_LegalConstraints.accessConstraints have to be set at the value "otherRestrictions"" Michael Ö 2015-05-21 See comment on line 15
18 Antonio Rotundo 2.9.4 61:9 Te see comment 17. Change wording.

"TG Requirement 35 - Contitions applying to access and use shall be represented by one instance of MD_LegalConstraints.accessConstraints with the value "otherRestrictions" and one instance of MD_LegalConstraints.otherConstraints.

 This shall NOT contain a link to the code list for Limitations on Public Access in Inspire registry since that is reserved for documenting Limitations on public access ( see 2.9.3)"
Michael Ö 2015-05-21 See comment on line 15
19 Antonio Rotundo 2.9.4 63:4-29 Te The first 3 XML examples are not compliant with ISO 19115; see also comment 17. Add in the XML examples accessConstraints or useConstraints = "otherRestrictions" Michael Ö 2015-05-21 See comment on line 15
20 Antonio Rotundo 2.13.1 81:   In order to make easier the implementation, consider only the mandatory elements in the class MD_MaintenanceInformation Consider only the element 143. maintenanceAndUpdateFrequency and delete elements 146 and 148. Conseguently update the XML example.

2015-05-20 (Peter): I do not agree with this, because it's explicitly given in Data specifications: "At least the following elements should be used ..."

 

(Antonio) If so, the WG shouldn't even change/modify/update the recommendations on other metadata elements given in DS. E.g. as far as the element "Encoding" (metadata for interoperability) is concerned, Data specifications state that "The property values (name, version, specification) specified in section 5 shall be used to document the default and alternative encodings.", but we have decided to consider only the mandatory elements in MD_FOrmat class (name and version). I think that the aim of the WG is to improve the quality of the description of geographic resources also updating the recommendations on metadata given in Data specifications and to allign the indications on metadata in the 2 guidelines (MD and DS).  In my opinion, requirements and recommendations on metadata should be given only in the metadata guidelines and not in both documents (but that would imply updating all the DS).

 

2015-05-21 (Peter): Antonio, you're right to say that our WG has the power to find new ways and make proposals not in line with DS (as we do with Encoding/MD_Format or especially SDS). In the Excel table I listed all given elements and added mandatory ones from ISO and more than once asked the group to discuss it! I looked up the ticket #2215 again: No one ever mentioned that having element 143 only would be sufficient ...

Of course we can do so! Let's discuss it while the meeting today!

 

2015-06-14 (Michael Ö): Some comments from own experience in general on writing maintenance information. I think it is not so useful with information on frequency unless also a maintenance note are added. The scope is maybe not of so much interest since we only have a single maintenance report.
What are we actually meaning with the multiplicity for updateScope and maintenanceNote. The text says "Should" and the multiplicity is 0..1. Is this a recommendation but not a requirement ?

21 Peter Kochmann 2.12.6 83 Ge/Te The example of using DQ_ConformanceResult doesn't fit here. Data specifications clearly name quantitative and descriptive results only. Conformance results are not in focus of Topological consistency here. Withdraw this example and replace it by suitable ones copied from 2.13.11 2015-05-20 (Peter): prepared for next draft (03), but not yet done. We should discuss this.
22 Martin Seiler 2.9 53:10 Ge The reference to the directive itself is too high-level here. The TGs should mainly reference the IR, as those define the precise requirements for which the TGs demonstrate encodings. subsitute reference to directive with reference to 1205/2008, part B 8.1 and 8.2 2015-05-21 Michael Ö: Agree on this
23 Martin Seiler 2.9 53:22/23 Ee Implementations have to fulfill the requirements of the IR (1205/2008). Hence it should be referenced here. Change wording to: "To fulfill the requirements of EG 1205/2008 an implementation can select ..."

2015-05-21 Michael Ö: Agree on this.

2015-06-14 (Michael Ö) The requirements we have will have in TG MD will both be requirements from IR that we must fullfill. But there are are also requirements related to ISO 19115/ISO 19119/ ISO 19139. We should clearly separate the source for each requirement. In this case we have already referenced the IR MD and I think this specific requirement is related to implementation in ISO 19115

24 Michael Östling 2.2.6   Ge Should  the actual mapping from the requirement in IR 1205/2008 be done differently?
Could CoupledResource actually be the element that matches the requirements in IR instead of OperatesOn !!!!!
When (again) reading the documentation of ISO19119 I get som doubts. This has to be commented by you who are using the ISO19119 more extensively since this is not my area.
We have in ISO19119 both
OperatesON with Domain MD_DataIdentification
and
CoupledResource with domain SV_CoupledResource

To fulfill the requirements in IR it seems to me that CoupledResource is better aimed for fulfilling the requirements of IR (it has a specific identifier as property)

The operatesOn implementation seems to be a way to satisfy users which  to find metadata for the datasets.
The domain for OperatesOn is really the metadata for each dataset though its MD_DataIdentification object.

And the use of the UUIDREF attribute is as Kristian points out a way to reference the MD_Identification objects UUID. (which could/should be the same as the MD_Identifier)

Martin: This would imply quite a change of paradigm. The CSW ISO AP actually extends/profiles the ISO 19119 schema in this case (see section 7.2.2.2 in the ISO AP). That implies that gmx:metadataExtensionInfo has to be provided as well. The queryable would shift to 'operatesOnIdentifier'. 

The version with operatesOn and uuidref/xlink is more or less implemented widely. We'd just have to make sure that the operatesOn queryable  actually evaluates both atrributes.

 

Probably a shift we should reconsider with the updates to the new ISO 19115?!

 

2015-05-21, Pawel S.: In my interpretation rules of ISO 19119 and CSW ISO AP operatesOn should be used if all service's operations are coupled with the same dataset/s and coupledResource should be used only if operations could be couple with diferent datasets.If we use coupledResource the metadata will be more detailed.

25 Peter Kochmann 2.9 56: 22 Ge

There's no dependence between 2.9.3 and 2.9.4 which results in seeing them coupled in any way! 2.9.3 is an alternative for 2.9.1 and 2.9.4 is an alternative to 2.9.2.

So it must be allowed to have e.g. 2.9.1 and 2.9.4

To fulfill the requirements of IR 1205/2008, B.8.1 an implementation can either use 2.9.2 or 2.9.4 and to fulfill IR 1205/2008, B.8.2 an implementation can either use 2.9.1 or 2.9.3

2015-05-21 Michael Ö: If a user selects to use 2.9.1 and 2.9.4 then both IR 1205/2008 B.8.1 and B.8.2  will be mapped to same metadata-element  and then there is no way to separate what belongs to what section in IR. Could you show an example of such a combination so we can analyze it ?

 

2015-05-22 Marc Leobet: I have got the same feeling than Peter. I am not as expert than you all, but I understand that the comments here could be such an example : https://ies-svn.jrc.ec.europa.eu/issues/2212#note-28

 

2015-06-14 Michael Östling: Yes Marc the example you show handles this by using  a some fixed string-values like "Directive 2007/2/CE (INSPIRE), Article 13.1.h" This would be an alternative (as Eleaine writes) instead of referencing to the registry with an Anhor-element. What we loose using just a character string is the idea of having language neutral code in the registry for values like "no conditions apply". This is discussed in Issue MIWP-8 (I) Language neutral identifiers. So if we skip the idea of requiring the Anchor for Limitations on Public Acess then the combination of 2.9.1 and 2.9.4 would be possible.
I would argue to use the Anchor, but that will lead to more implementation work but the metadata will be more interoperable. This have to be dicussed further in group.
But I see no point for anyone to combine 2.9.2 and 2.9.3 or can anyone show such a compination that could be useful?

 

26 Peter Kochmann 2.9.2 + 2.9.4 59: 11 + 64: 5 Ge see Martin's comment #22: this also applies here at the beginning of these chapters   2015-06-14 (Michael Östling):I agree on this. We should go through all our requirements and clarify if they come from IR or standards from eg ISO. So we need a general walkthrough to clarify the source for each requirement and avoid refer directly to the directive as Martin points out.
27 Peter Kochmann 2.9.4 65: 4 Ed ISO-No. of useConstraints is 71, not 70 71. useConstraints 2015-06-14 (Michael Östling):Correct
28 Peter Kochmann 2.9.4 64: 18 Ge In addition to 2.9.1 there maybe two types of content to be placed in a forming of accessConstraints/otherConstraints. Will it be the same one or do we have to rule that separate formings of MD_LegalConstraints are required here?  

2015-05-21 Michael Ö: Do we have to set the rules for this?
Would we generate issues if a record contains two MD_LegalConstraints with a single otherConstraints
compared to a single MD_LegalConstraints with two otherConstraints. This is of both instances relates to same type (access or use). 
If one is on Use and the on Access we would need two separate MD_LegalConstraints I would think.

 

2015-05-22 Marc Leobet: I think, from a coding point of view, that a single MD_LegalConstraints would be better.

2015-06-14 Michael Ö: We need to clarify this in TG as well as handle a number of examples.

29 Martin Seiler A.12.* 118 Ge The document is very long. The examples are only covering one option, where multiple approaches are documented in the TG. 'outsource' the XML-examples to e.g. a github account or joinup and just add a link here. This makes the document a bit shorter and also enables us to document serveral different apporaches that are offered by the TG. Plus its easer to correct errors.

2015-05-22 Marc Leobet: my experience is that developpers, sometimes (!), forget to look at examples which are far away (eg. one click away). The feedback we had in France led to give the code just under the text. A way to make the document easier to handle could be to publish it under a html form, where links could bring direct access to the searched subject.

2015-06-14 Michael Ö. But I would I support to put respository with examples. Then files can be uploaded into eg. XML SPY and can be analyzed in more detail.  I would prefer keep codefragments in document but manage complete files in eg GitHub

30 Ine de Visser 2.9.3   Ge In my opinion the limitations on public access and the reason are more fitting in the ISO elements on security constraints. investigate if the proposed solution in 2.9.3 fits in the security elements.

2015-05-22 Marc Leobet: don't we have this discussion before? From our side, we think that security constraints aim military restrictions and are not fitted for civilian uses.

 

2015-06-03 (Peter): I agree with Marc. That's what I learned from ISO as well.

31 Ine de Visser 2.12.4   Ed reference to the IR is not correct replace point 4 with point 5

2015-05-21 (Peter): already done yesterday for draft 03.

 

32 Martin Seiler 2.9   Ge To reduce the semantic confusion it would be helpful to add definitions of the terms "Use Constraint", "Use Limitation", "Access Constraint", "Legal Constraint" in the intro of the section  

2015-05-22 Marc Leobet: good idea. And a strong challenge to deal with.

2015-06-14 (Michael Ö): Yes this area needs clarfication. These sections is from my perspective probably the hardest ones to fill in to be useful for users. The problem will be to find who can do the work. Let us check on next meeting .

33 Martin Seiler 2.9 53:23 Ge The possible combinations of the solutions should be clarified. 2.9.1 and? or? etc.  

2015-05-22 Marc Leobet: same than comment 25, isn't it?

2015-06-14 (Michael Ö): Yes read my view on this. When we have arrived at a common aggreed solution on this section we should clarify possible combinations. As I see it now current solution with an Anchor does not open for such combinations.

34 Ine de Visser 2.12.6   Ed   replace point 5 with point 4 2015-05-21 (Peter): already done yesterday for draft 03
35 Peter Kochmann 2.12.6   Ge

We still have the problem that everything that is given in Data specifications concerning data quality focusses on ISO 19157 structures. We have seen that there are some elements missing in ISO 19115 when trying to have a mapping for the descriptive results. At other points (e.g. Encoding, SDS) we decided not to follow the Data specifications or the existing TG SDS, focused on “What does the implementing rule mean?” instead and made conclusions that maybe go a different way.

  1. For concerns of Topological consistency forget about the Data specifications and concentrate on Implementing rule 1089/2010, article 13.
  2. This element should express “Correctness of the explicitly encoded topological characteristics of the data set as described by the scope.”. Are there quantitative results concerning Topological consistency at all? I guess it will be a descriptive issue anyway.
  3. IR says that this element is needed when “the data set includes types from the Generic Network Model and does not assure centreline topology (connectivity of centrelines) for the network.” This can be seen as a kind of conformance statement: specification is “INSPIRE Generic Network Model”, pass I guess would be “FALSE” and with explanation we have an element of free text where to put anything that has to be expressed by text.
  4. With this we wouldn’t have a difference between descriptive and quantitative results any longer but have a clear expression covering all aspects given in implementing rule concerning this element 

I’m afraid I won’t be able to have an example for this until the meeting in Lisbon. Maybe we can talk about it at first.

36 Eliane Roos 2.9.1 and 2.9.3   Ge

2014.05.26

 

2.9.1 and 2.9.3 could be merged since they are using the same ISO 19115 implementation (MD_LegalConstraint.accessRestriction + MD_LegalConstraint.otherRestrictions). Moreover I am not in favour of having 2 options.

My position is the following :

 

  • Define the INSPIRE limitation codeList presented in 2.9.3, including the “noLimitation” value
  • Mandatory : MD_LegalConstraint.accessConstraint=”otherRestrictions” + MD_LegalConstraint.otherConstraint = one of the value of the INSPIRE codeList.
    • Think about the possibility to add an instance of MD_LegalConstraint.accessConstraint=”restricted” in case there is a limitation
    • Note : 2.9.3 is advicing to use an Anchor which is a good idea for those who can handle it. For limited system, maybe it would be a good idea to enable to use directly the free text field with the values of the codelist.
  • Optional : one instance of MD_SecurityConstraint.classification. But I would advice to be careful when using this one. Generally, MD_SecurityConstraint should be used only within military context, for national or international defense context. In that case, I would also advice to double the information by providing a legalConstraint and chosing the “national security” choice in the INSPIRE list of code for limitation on public access
  • Optional : other instances of MD_LegalConstraint.accessConstraint or MD_LegalConstraint.useConstraint using other values of the ISO codelist.
2015-06-14 (Michael Ö): As the implementation is writtten now the specification for 2.9.1 and 2.9.3 is different. 2.9.3 requires the reference to the Inspire registry with an Anchor element while 2.9.1 is just a free text string. It is possible that the use of Anchors will be more videly used in general since we also suggest to use Anchor for reporting Category for SDS and that there are sugegstions to report conformance to ATS in dataspecifications using an Anchor. 
I think the requirement to use Anchor or not will be our next analysis on this issue to see in what direction we should work on. 
Adding MD_LegalConstraint.accessConstraint=”restricted” is good option as I see it since it add some sematics for the OtherConstraint.
37 Eliane Roos 2.9.4   Ge

2014.05.26

I do not see the need for having 2.9.4, since 2.9.2 is totally correct in term of ISO Standard. The useLimitation element can be used within an MD_LegalConstraint class, since this one is a sub-class of MD_Constraint and by the way inherits its properties. Then it is more logical to use the useLimitation.

Delete 2.9.4. In the comment line of the table in 2.9.2, it can be “The useLimitation field may be used either within an MD_Constraint class or one of its sub-classes (MD_LegalConstraint or MD_SecurityConstraint)”. 2015-06-08 (Peter): We had this discussion before (see concerning ticket in task A). The question was not how to access useLimitation itself via MD_Constraints or MD_LegalConstraints but where to put the designated information "Conditions apllying to access and use". It became clear that INSPIRE used useLimitation the wrong way concerning the content. The designated information has to be put into useConstraints/otherConstraints or accessConstraints/otherConstraints.
38 Peter Kochmann 2.2.7 31: 14 Ge Though not in focus of our work when strictly speaking: Following James' proposal on specifying ISO 639-2/T for metadata language (see #1) we would have a difference to resource language: here the domain still is ISO 639-2/B. Are we going to change this as well?  

2015-06-10 (Martin/Peter): We should be consistent in our choice throughout the document. Referring to #1 we should go with ISO 639-2/B here as well.

2015-06-14: (Michael Ö): Yes I would go for using the ISO 639-2/B here (see updated comment on #1) Since A change to ISO 639-2/T would mean we have to convert languagde codes at least for Germany , France and Netherlands.

 

Remarks.docx - All my comments in one doc, since I'm not good yet in this tool and its layout, sorry for that. (18.1 KB) Geraldine Nolf, 19 May 2015 02:33 pm

MD_IR_and_ISO_20131029_Copy_for_editing_in_MIWP8_SDS3.doc - metadata for interoperable spatial data services (243 KB) Ine de Visser, 20 May 2015 04:02 pm