Response to INSPIRE Metadata Draft

• See Reading the INSPIRE Metadata Draft for preparatory material.
• See FOSS SDIC

Any member of the Free and Open Source Geospatial software community is welcome to participate in creating this response. Please add your name, and contact details on your userpage, to the list of participants and at any key stage (first stable draft; when sending the response).

Due 15.03.2007? -- Stefan 19:11, 15 March 2007 (CET)

I am sure it was the 30th, the NAP draft was due the 15th?

Right now i am trying to get the docs for the form of the response out of the JRC and change our contact dets for the SDIC. -- Jo 23-03

The deadline is definitely the 30th March, thankfully. Comments must be submitted in this Excel template: http://www.ec-gis.org/inspire/sdic_call/templates/metadataIRComments.xls

The form for each comment is:

Chapter, section or clause no. | Paragraph/Figure/Table | Type of comment | Comment justification for change) | Proposed change 

So i am working on integrating Ian's and Jan's comments and reconnecting mine to chapter, verse and clause. I planned to put it all into the Excel template this evening, then i discovered that the template doesn't work properly in OpenOffice. So i'm just going to dump a pipe-delimited version of what is collated into this wiki page for others to see, and worry about getting it into the proper format later in the week :/ I realise it makes sense to do that anyway because there is a lot to do in terms of structuring to get as much directly connected to the draft as possible... What is there now is only a start. :/

-- Jo 26-03

Just to mention i am doing another batch this evening and will upload them either later or first thing a.m. Meanwhile the JRC replaced the spreadsheet template with one that works, which is great.

-- Jo 28-03

Participants

• Jo Walsh
• Markus Neteler
• Ian Ibbotson
• Jan Růžička
• Stefan Keller

Responses

Note: these will be automatically re-sorted by chapter, clause etc order when they are submitted so there's no priority ordering and not much point in number ordering...

5.2.8	-	T	If a Resource responsible party for the data is mandated, then contact details, either an electronic mail address, a HTTP URL with details, or a phone number, should be included. If access to a dataset is restricted and it is not available via a service, no means of contact will impede the flow of data and the ability to reuse and redistribute it.	Require contact details be provided for a resource responsible party.
A.2.8	-	T	Contact details should be mandated in the ISO19115 mapping in order to facilitate access to the data set. This could be an email, URL or telephone number.	Add mandatory contact details for resource responsible party.
A.2.8.3	-	T	A contributor's "role" is not useful for discovery, evaluation or use of the data. In the interests of minimising the burden on the provider it should not be a mandatory property.	Change Mandatory to Optional for role of resource responsible party
A.4.1	-	T	If a Resource responsible party for the metadata is mandated, then contact details, either an electronic mail address, a HTTP URL with details, or a phone number, should be included. A property such as email address can be used as an identifier to facilitate searches. Providing a contact for metadata assist in evaluation and reuse of it.	Add contact details (email address, url or phone number) as mandatory if a metadata resource reponsible party is provided in the ISO19115 mapping.
5.2.12		T	A free text lineage element is not structured enough for data evaluation. A more structured and detailed method of describing accuracy and quality of data should be prescribed, otherwise providers will be able to claim "compliance" with a minimal level of effort that does not further the interests of reuse of public sector information.	If requiring lineage information. require it in a more structured form, which may overlap with Data Specification work
A.3.2		T	A free text description of data "lineage" tries to perform too many functions at once. More detailed and structured description of a dataset's origins and processing history is needed to express and infer accurate data quality information.	Conditions under which lineage is required to be provided, are too vague. Lineage should be structured information and not free text.
A.3.2		E	Presumably should read 'mandatory when...'	Should read 'mandatory when...'
5.3.4	Table 3	T
6.2		T	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 This may be covered in the Data Specification Implementing Rules?	Recommend one preferred, URL-based identifier scheme
6.3	Paragraph 4	T	A reference data set may not be available via a service, for many reasons including infrequent use, access restrictions, scarcity of resources or changes in distribution technologies.	Should not assume that a reference data set is provided by a 'service'
6.3	Paragraph 13	G	A provider may take a broad view of what consitutes "very fine grained" in order to exempt themselves from exposing insight into the detail and structure of a data set.	More detailed description of what contitutes "very fine grained", and detail of what metadata is subject to exemption for components of a highly detailed data set, is required.
5.2.3	Paragraph 1	T	A geographic extent may be in three dimensions and for some applications ( geology, meteorology, climatology ) vertical extent is crucial. 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. The IR should not simply specify a bounding box but should outline the many alternatives.	Change 'bounding box' to read 'bounding box, polygon or 3 dimensional set of polygons' (better wording)?
5.3.2	Table 1	T	Article 11.1.a dictates that services must be searchable on the basis of "the public authorities responsible [for the data]", e.g. the resource responsible party.	Resource responsible party should be a searchable property (marked with X)
5.3.2	Table 1	T	Even a simple search through a large volume of data records cannot rely on a limited range of topic classifications and user-supplied keywords. 'Abstract' is likely to be the most verbose user-supplied description from which useful inferences can be made.	Abstract should be a searchable property (marked with X)
G	Paragraph 1	E	The meaning of "the confrontation of this interpretation with the discovery set" is unclear.	Change "the confrontation of this interpretation" to indicate clear meaning.
G	Paragraph 2	G	The text mentions "quality indicators", but the examples given in the table are all derived from the standard discovery metadata. These help to assess potential suitability of a dataset for a specific purpose, but provide no metric for quality of a data set (which may be partially complete, be at different resolution within different spatial extents). Article 11.1.a of the directive is specific about "the quality and validity of spatial data sets" as a *specific search criterion*	Add a treatment of data quality metrics that can inform suitability for a particular purpose.
G	Table G.1	T	Fulltext description of data lineage is not enough to accurately or efficiently establish restrictions on use of data. The listing in table G.1 is blurring together use constraints with data processing and packaging information.	Lineage information should be expressed in a more structured way, and exactly what lineage is meant to contain should be clearer.
4.1	Note 6, Paragraphs 4 & 5	G	These paragraphs suggest that no description of quality of data available via a service will be mandated by IR. Service evaluation, and the means to talk about it in a structured way, will be a key to a successful data infrastructure. If we can quality as "fitness for use" then there are ways to transmit and reuse evaluation of a service or dataset for a specific purpose. Expectations that users of a data infrastructure will search "news and mail forums" or learn about service performance "by word of mouth", do not belong in a framework for a useful data infrastructure.	Paragraphs 4 and 5 should be removed, this Note as a whole revised.
5.2.7		T	It is necessary when implementing a spatial data or service discovery engine, to be able to get authoritatively identifying information about the service type, that does not involve human intervention in order to be able to verify it. The service type should be mandated as a URN or other consistent identifier (OGC:WMS is commonly used), either from a supplied list of well-known standard services, or by being able to refer to an external list in a structured way.	Service type should not be a free-text field, but be a guaranteed unique and consistent property.
A.2.7		T	In order to be reusable in service discovery or service chaining applications, Service Type should not be a freetext field but a URN or other reusable and definitive description of a service. The ISO19115 model is deficient in this respect. ISO19119 provides structured descriptions of service types and these are recommended in the current North American Draft Profile for metadata, the conceptual equivalent to this IR that will replace the current Common Profile.	Service type should be an externally-delimited identifier, not a "Free text" property.
4.6	Paragraph 6	T	The assertion that data should be available "preferably via a standard interface and/or standard encoding format such as XML" is too vague to be useful. An abstract model for discovery interfaces is common practise in the broader information retrieval community; it is needed in order to be able to ensure and evaluate conformance.	This paragraph should either be removed or supplemented with more detail from the IR on Discovery Services.
A.3.8		T	The table refers to a code list for "distributed computing platform", but no reference to a code list is supplied. If a code list is not available, this should be a URN or a URL, with ability to extend into a namespace supplied by user communities and future applications.	A reference to the code list should be supplied, *or* the property should be a URN or a reference to a URI.
I		T	Temporal extent is optional in the Dublin Core mapping, "mandatory when it is meaningful for discovering and searching spatial data sets". Arguably, temporal characteristics of a data set are *always* useful in attempting to search a large repository and evaluate results.	Temporal extent should be mandatory.
B.6		T	Keywords are just as useful for discovering and filtering services as they are for data sets and series. If mandatory for data sets, should also be mandatory for services.	Obligation/condition should change either M mandatory, or C (mandatory for datasets, dataset series, and services )	5.1	Paragraph 9	T	"The discovery metadata elements are defined at an abstract level in order to make the Implementing Rules independent of ...". If there is no specified encoding or mapping into different common standard implementations, there is likely to be so much variance in encoding of metadata, as to cause new classes of problems (meta-mapping between different slightly discrepant models) while not solving the ones we face now. The usability of metadata in search engine applications. There is such a thing as too futureproof.	Hard to suggest a concrete change as this is a deep conceptual issue.