Reading the INSPIRE Metadata Draft - Revision history

Wiki-Aisenor at 17:58, 2 April 2007

2007-04-02T17:58:24Z

Wiki-Jencek: /* Too general */

2007-03-24T22:12:28Z

Too general

Wiki-Jencek: /* Areas which are unclear */

2007-03-24T22:05:58Z

Areas which are unclear

Wiki-Jencek: /* Things that are there that probably shouldn't be */

2007-03-24T22:02:44Z

Things that are there that probably shouldn't be

Wiki-Jencek: /* Things that aren't there that should be */

2007-03-24T21:25:01Z

Things that aren't there that should be

Wiki-Jencek: /* Things that aren't there that should be */

2007-03-24T21:23:00Z

Things that aren't there that should be

Wiki-Jencek: /* Too general */

2007-03-19T21:48:02Z

Too general

Wiki-Jencek: /* Issues */

2007-03-19T21:36:54Z

Issues

Wiki-Ianibbo: /* Lack of engagement with packaging and re-use issues */

2007-03-14T12:19:55Z

Lack of engagement with packaging and re-use issues

Wiki-Ianibbo: /* Search / discovery services */

2007-03-14T12:03:34Z

Search / discovery services

@@ Line 34: / Line 34: @@
 * use (once access gained, how to best use the data)
-It is illuminates to compare this with the [[Reading the NAP Metadata Draft|North American Profile]] metadata draft which talks about
+It is illuminating to compare this with the [[Reading the NAP Metadata Draft|North American Profile]] metadata draft which talks about
 * discovery

← Older revision		Revision as of 22:12, 24 March 2007
Line 207:		Line 207:
	== Too general ==		== Too general ==
	I am now finishing the reading and my first feeling from the IR document is that there are some parts too general and not helpful for implementation. It is like ISO 19115 or CSW 2.0. When you start to implement it you have to find your own way how to do it. This will probably lead in inconsistency of catalogues interfaces and content. I know that something is better than nothing and I welcome INSPIRE metadata IR, but I know that there should be specified more that is in this document. We are now testing CSW 2.0 implementation in GeoNetwork Open Source and we have found a lot of problematic parts (in implementation and in specification as well). I have some concrete comments to IR metadata, but I have to sumarised them first to publish them here. Some of them are probably mentioned here (in that case I will just comment that I agree with mentioned issues).		I am now finishing the reading and my first feeling from the IR document is that there are some parts too general and not helpful for implementation. It is like ISO 19115 or CSW 2.0. When you start to implement it you have to find your own way how to do it. This will probably lead in inconsistency of catalogues interfaces and content. I know that something is better than nothing and I welcome INSPIRE metadata IR, but I know that there should be specified more that is in this document. We are now testing CSW 2.0 implementation in GeoNetwork Open Source and we have found a lot of problematic parts (in implementation and in specification as well). I have some concrete comments to IR metadata, but I have to sumarised them first to publish them here. Some of them are probably mentioned here (in that case I will just comment that I agree with mentioned issues).
		+
		+	== List of issues ==
		+	I have tried to put what I have find it the IR document to this page, but you can find different form of structure in http://gis.vsb.cz/ruzicka/down/ruzne/inspire/CommentsMetadata.pdf

← Older revision		Revision as of 22:05, 24 March 2007
Line 119:		Line 119:

	IR talks about dataset series. Some of the diagrams talk about 'MD_Aggregates'- this term isn't used elsewhere. No conception in this model of one UrDataSet with many different potential sources according to how they are packaged or processed. As the IRs mandate properties for dataset series, really need more clarity / examples about what they actually are.		IR talks about dataset series. Some of the diagrams talk about 'MD_Aggregates'- this term isn't used elsewhere. No conception in this model of one UrDataSet with many different potential sources according to how they are packaged or processed. As the IRs mandate properties for dataset series, really need more clarity / examples about what they actually are.
		+
		+	=== Other ===
		+
		+	* Page 17. sec. 4.1. Note 6, par. 2: "Services, including web services, are routinely measured in terms of availability and performance. These parameters are easily quantified and users can easily agree on their value: services that are available more often (seeking the elusive 99.9% "up-time") are more desirable than services that are available less often, and services that provide faster response time are more desirable than similar services that are slower to respond.". This is not exact. When a user wants to use a service he must know more than about availability and speed of the service. For example cost, quality of used geodata, used algorithms, quality of used algorithms, possibility of chaining, quality of self-description of the process, development, update, security, type of call (synchronous x asynchronous). Perhaps all that you have to know about software, because a service is a software and a user will not use it once but many times and perhaps for a long time.
		+	* Page 30. sec 5.2.4.: Does it mean that the resource for INSPIRE can not be encoded in other encoding such as Windows 1250? This is a problem that we have found in ISO 19115 and we still do not know how to handle it. We have a lot of geodata encoded in Windows-1250 and nobody is going to change the encoding, and it means that we can not describe them using ISO 19115 (or we do not know how, except extending the list).
		+	* Page 33. sec 5.3.2: The resource responsible party must be searchable. The abstract should be searchable.
		+	* Page 39. sec 6.3: The formulation are not clear. They need to be specified better with examples and schemas.
		+	* Page 58. A.3.8.2: Not conform with A.3.8.1. Why A.3.8.2 is conditional and A.3.8.2 is mandatory?
		+	* Page 64. sec B.6: The keyword element must be mandatory for services as well.
		+	* Page 72. sec D4.2: I think that ISO 19139 must be adopted always not only when there is not any other XML schema, I can prepare my own schema compatible with ISO 19115 but not with ISO 19139, but this is not useful for INSPIRE.
		+	* Page 19. sec. 4.3. Par 4 (numbering 3): This is not right. When there is not ISO 19139 yet final we can not talk about maturity. Some of the services have adopted ISO 19115, but there is not a conformity in adoption and many adoptions are probably wrong.
		+	* Page 27. sec 5.1. Par 2 (bullet 1): "the user query expressed through the search interface of the search engine and provided in a form compatible with the metadata repository interface". This is unclear, what does it mean? Any repository can have different interface? That is horrible if you know that there is CSW 2.0 specified now.
		+	* Page 28. sec 5.1. Par 9: "The discovery metadata elements are defined at an abstract level in order to make the Implementing Rules independent of ...". This is often wrong, if there is not specified encoding. In this case the IR for metadata can be useless.
		+	* Page 33. sec 5.3.3: The Operation name should be moved to Discovery level 1 and must be searchable, this is necessary for services searching.
		+	* Page 44. sec A1.2.1 Note 3: This kind of condition is problematic. Who will decide that particular statement or quality report is required? I assure you, nobody will do more than is specified in the IR for metadata.
		+	* Page 49. sec A.2.3.1: EX_GeographicBoundingBox must be defined always for services too. Not conditional. When the service is not based on GeographicBoundingBox then it should be defined for a whole world.
		+	* Page 45. sec A.1.2.2: “identifier: MD_identifier. condition: if the identifier is available”. Identifier will be probably available always and if not it should be generated.
		+	* Page 58. A.4: Why are metadata on metadata in level 2 and why not searchable.
		+	* Page 59. sec A.4.3: Free text. I do not understand why when there is a list. Does not list include all languages?
		+	* Page 62. sec B.3: Do not understand the extent definition, description looks very strange.

	== General concerns ==		== General concerns ==

← Older revision		Revision as of 22:02, 24 March 2007
Line 98:		Line 98:
	Both of these are at 'Level 1 for discovery metadata' which implies that any INSPIRE compliant metadata set MUST have both topic category and associated keywords.		Both of these are at 'Level 1 for discovery metadata' which implies that any INSPIRE compliant metadata set MUST have both topic category and associated keywords.

		+	I partly agree: It is true that for INSPIRE should be defined thesaurus for keywords. INSPIRE is mainly oriented to environment protection. There is GEMET thesaurus, but there is not a common agreement to use it. This part of metadata is not so simple and I understand that definition of a IR for this part is very difficult.
		+
		+	Other issues:
		+	* Page 60. sec B.2.1: Temporal extent is meaningful always for discovering and searching.
		+	* Page 85. sec H.5.2: Too difficult for implementation and not very useful, there are other ways how to support multilingual descriptions.
		+	* Page 38. sec 6.2: Identifier are of two types. This is problematic. It is usually better to have only one type of identifier. The preferred one should be URL (URI). The document says that URL can be in some cases not unique. If you want to make identification more unique than mix URL with UUID. Like this: http://gis.vsb.cz/01f8da38-10d7-11da-b569-000f1f1a7b03

	== Areas which are unclear ==		== Areas which are unclear ==

@@ Line 53: / Line 53: @@
 '''Some form of electronic or telephonic contact address should be mandatory, if the org/person's details are mandatory.''' Why publish ownership information - especially if there are constraints on access and reuse of the described data - if you can't immediately get in personal contact with someone who can make assurances about the data?
-I agree, but no only for data, btu for metadata as well:
+I agree, but not only for data, btu for metadata as well:
 Page 53. sec A.2.8.1 and A2.8.2 and A.4.1: Other information for identification is necessary like e-mail, URL, voice number.
@@ Line 65: / Line 65: @@
 I agree:
 Page 31. sec 5.2.12: The lineage element is not enough for data evaluation. The same problem is on Page 55. sec A.3.2.
 === Things that are there that probably shouldn't be ===

@@ Line 52: / Line 52: @@
 '''Some form of electronic or telephonic contact address should be mandatory, if the org/person's details are mandatory.''' Why publish ownership information - especially if there are constraints on access and reuse of the described data - if you can't immediately get in personal contact with someone who can make assurances about the data?
 Annex A on mapping to IS019115 mandates that contact persons and organisations be free text, not resource identifiers. 2 serious problems with the ISO 19115 mapping:
@@ Line 59: / Line 62: @@
 '''No discussion of formalising dataset accuracy / completeness - crucial for cost-benefit evaluation / evaluation of suitability for combining with other data sets.'''
 === Things that are there that probably shouldn't be ===

← Older revision		Revision as of 21:48, 19 March 2007
Line 162:		Line 162:
	= Feelings =		= Feelings =
	== Too general ==		== Too general ==
		+	I am now finishing the reading and my first feeling from the IR document is that there are some parts too general and not helpful for implementation. It is like ISO 19115 or CSW 2.0. When you start to implement it you have to find your own way how to do it. This will probably lead in inconsistency of catalogues interfaces and content. I know that something is better than nothing and I welcome INSPIRE metadata IR, but I know that there should be specified more that is in this document. We are now testing CSW 2.0 implementation in GeoNetwork Open Source and we have found a lot of problematic parts (in implementation and in specification as well). I have some concrete comments to IR metadata, but I have to sumarised them first to publish them here. Some of them are probably mentioned here (in that case I will just comment that I agree with mentioned issues).

← Older revision		Revision as of 21:36, 19 March 2007
Line 159:		Line 159:

	So we have a 'distributed computing platform' metadata property that is required by the IRs. In the ISO19915 mapping in Annex A this is a '''free text field''', yet 5.2.15 states that the property "is necessary for a client to bind to the service". If it must be mandated, it should be as a URI. It would be wonderful to have examples of what other than HTTP or OGC web services is envisaged NOW as a means of access to the backend of a distributed computing platform.		So we have a 'distributed computing platform' metadata property that is required by the IRs. In the ISO19915 mapping in Annex A this is a '''free text field''', yet 5.2.15 states that the property "is necessary for a client to bind to the service". If it must be mandated, it should be as a URI. It would be wonderful to have examples of what other than HTTP or OGC web services is envisaged NOW as a means of access to the backend of a distributed computing platform.
		+
		+	= Feelings =
		+	== Too general ==

@@ Line 144: / Line 144: @@
 Cf. Dataset series / aggregates. The examples have 'MasterMap' as one potential dataset! Real world use cases are going to need subsets of such huge data sets broken down into packages with smaller spatial extents or with less layers.
-II: Indeed, as well as the srw/sru binding experiment, I've been wondering about the OAI binding, which I know you've already discussed elsewhere. What might be generally useful (And maybe this already exists) is a set of TREC style test data. Setting up a static gateway OAI server wouldn't be so hard, and might give us some valuable real-world information about this problem.
+II: Indeed, as well as the srw/sru binding experiment, I've been wondering about the OAI binding, which I know you've already discussed elsewhere. What might be generally useful (And maybe this already exists) is a set of TREC style test data. Setting up a static gateway OAI server wouldn't be so hard, and might give us some valuable real-world information about this problem. I now the records won't be in the right schema, but something we can try and munge into gmd would be a real help.
 === Bypassing of feature-level metadata from consideration ===

@@ Line 106: / Line 106: @@
 I'm a bit confused by the "Temporal Reference" Element... 5.2.2. Talks about what I would expect to see from a temporal reference, but 5.3.2 maps temporal reference on to  "One of the dates of publication, last revision or creation of the resource". These three elements are already well defined by dublin core attributes... Maybe I've misunderstood whats implied by table 1 in 5.3.2. Also, similar issues to the spaital access point arise (With structured data, as opposed to text queries). In some UK datasets, periods such as "Neolithic" can be used instead of an ISO 19108 Date Time. (I seen note 11 under 5.3.4 talks about this, which is good. Whats important is that regardless of the outcome of the study, the IR are extensible enough to cope with the eventual decision). I'd consider seperate access points for controlled vocabulary time period and structured temporal data. This seems a specific example where the abstract IR model needs to go beyond what is defined in the A2 binding.
-Geographic Extent.. the doc seems a bit bounding box heavy. Would be nice to understand (have examples of) specification of interior/exterioir polygons. Servers only supporting minimal bounding boxes can gracefully degrade (Since it's easy to calculate a MBR from a polygon) whilst allowing other servers to retain the full richness of polygons. It's not clear where the semantics for parsing these strings will be defined.. for example should geographic extent be encoded as OpenGIS strings (Which seems to make sense to me, but I'm biased by Oracle and MySQL's spatial functions). This might seem a bit extreme for the abstract part of the document, but it's one of those make-or-break issues for interoperability, and might be worth the pain. Also, I think it's worth entertaining the idea that spatial specifications such as MBRs and polygons (Structured spatial constructs) might be better exposed using their own abstract access point, and "Place Name" having it's own access point. This will help server implementors avoid problems with disambiguation of search terms.
+Geographic Extent.. the doc seems a bit bounding box heavy. Would be nice to understand (have examples of) specification of interior/exterioir polygons. Servers only supporting minimal bounding boxes can gracefully degrade (Since it's easy to calculate a MBR from a polygon) whilst allowing other servers to retain the full richness of polygons. It's not clear (in the abstract model, it is in the A2 binding) where the semantics for parsing these strings will be defined.. for example should geographic extent be encoded as OpenGIS strings (Which seems to make sense to me, but I'm biased by Oracle and MySQL's spatial functions). This might seem a bit extreme for the abstract part of the document, but it's one of those make-or-break issues for interoperability, and might be worth the pain. Also, I think it's worth entertaining the idea that spatial specifications such as MBRs and polygons (Structured spatial constructs) might be better exposed using their own abstract access point, and "Place Name" having it's own access point. This will help server implementors avoid problems with disambiguation of search terms.
 I'm interested in what the expected semantics of resource language are on retrieval of language-neutral data sets.... Should a result record not be selected because the user specified "Nor" as the search language, but resources matching other criteria (Geo Extent for example) do match. Normally in Info Retrieval this is a no-brainer, of course it shouldn't, but I'm a bit less certain when we talk about result records that aren't primarily "Text" based. (Actually, this is a slightly wider concernn about annex A and those "CharacterString" elements... In IEEE LOM for example we have "LangString" element that has a "Lang" attribute. That community chose to allow language variants of a resource to be expressed within one record by allowing an element to hold all language variants, for example