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

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)?