MIWP-8 2nd virtual meeting 2014-12-04¶
Time 14:00 -16.00 CET¶
- Use of WIKI and Issue-tracker
- Participants in working groups (List of Members MIWP-8) (Michael Ö)
- Description of each Issue in Release A (Lead for each subgroup)
- Walkthrough of initial analysis (description) for each issue (Work programme Update TG Metadata)
- If possible use the headlines added to each issues wiki-page (but feel free to add any additional headers)
- That gives us a common view of:
- What is the problem
- Possible solutions
- Relation to IRs
- Relation to other issues withon MIWP-8
- Relation to other MIG-T subgroups
- What work have been done ?
- What will next step be ?
- Are there any obstacles that are hindering the work ?
- Coming meeting dates (Michael Ö)
Please comment in these if you see missing discussion-points that have been lost.
Each issue in ToR we work have a WIKI and a corrensponding Ticket in Ticket.
In the top of WIKI and Ticket there is a link to the corrensponding page.
WIKI: use this for adding new findings and suggestions
Ticket: use this for commenting on what written on the wiki
If you are not sure, add your suggestions as comment on the ticket.
Files: If you are adding files. Add them to the file-section and link to them from the wiki or ticket.
Emails: Try to avoid using emails for communicating ideas. Add it as tickets instead so they are traceable and visible for all.
Then if needed send an email to these you want to respond with a link to the issue.
Initially this takes some more time but it is easier to have a transparent work if we use Redmine as much as possible.
Issues - Dicussions on status¶
Ine de Viser is group leader.
Michael Ö described the legal status:
In the initial phase of work related to SDS and Invoke services there where
Draft implementation rules (INSPIRE spatial data services and services allowing spatial data services to be invoked– Draft Implementing Rules and annex to ammending reg 1089-2010.)
and Technical guidelines ( Draft TG for INSPIRE Spatial Data Services and services allowing spatial data services to be invoked.) written for SDS.
It has though been decided that there should not be a separate IR for SDS. Instead there will be two amendments
a draft COMMISSION REGULATION amending Regulation (EU) No 976/2009 as regards services allowing spatial data services to be invoked, as part of the implementing rules on network services referred to in article 11.1(e) of Directive 2007/2/EC of the European Parliament and of the Council of 14 March 2007 establishing an Infrastructure for Spatial Information in the European Community (INSPIRE)
a draft COMMISSION REGULATION amending Regulation (EU) No 1089/2010 implementing Directive 2007/2/EC as regards interoperability of spatial data services, as part of the implementing rules on the interoperability of spatial data sets and services referred to in Article 7(1) of Directive 2007/2/EC of the European Parliament and of the Council of 14 March 2007 establishing an Infrastructure for Spatial Information in the European Community (INSPIRE).
After these two amendments are published in the Official Journal of European Union member states shall implement metadata according to these regulations within one year. It is expected that these will be published before the end of this year.
The status and plans for Technical guidelines for SDS are not clear. If parts of these will be published regarding the parts that does not go into TG metadata. We are checking with JRC on status for them.
Michael L will get back on this.
The WIKI are update with background material on that gives a good background on the work that needs to be done.
Ine wishes that we get some more participants that can join the work so please volunteer to join this group.
(COMMENT AFTER WEBINAR, the amendemnts are now published on dec 10th, see links below)
Leader for this group is James Reid (UK).
These six element are defined in each dataspecification and is listed in Article 13 of the Implementing Rules on interoperability of spatial data sets and services.
Peter Kochmann mentioned that there could be advantages to handle these elements in similar way as the elements that handled MIWP-8 (E-1) Integrate Theme specific metadata.
These are though mainly optional.
Peter K has also attached a very good overview-table to the WIKI in Excel of all metadata elements for all themes. This contains both mandatory and optional elements.
The six elements are mapped against ISO19115/ISO19139 in later versions of dataspecifications. These mapping tables could be copied into chapter 2 of TG Metadata.
Leader for this group is Michael Östling (SE)
Some element that now are freetext can have specific values in certain cases like.
“no conditions apply” for metadata element Conditions for Acess and Use.
This element is normally understood as that it should be translated to the metadata language of the metadata record. But this is not fully clear in TG.
Andrea P added feedback from the validation workshop that these textfields are hard to validate and that we may have to codelists for these.
We will update on this when we get the minutes from the validation workshop.
The element creates links between a Service metadata record and the datasets the service uses.
The normal implementation done in most member states are by adding a HREF to the metadata record for each dataset in a CSW-catalogue by using a GetRecordByID request.
An alternative according to TG Metadata is to reference to a A unique resource identifier. The datatype for this element should be a MD_Dataidentification.
Very few have implemented this element as it’s intended by ISO19119. Using a GetRecordByIdRequest has been a straightforward way to link medata for the services and metadata for the datasets.
Kristian Senkler mentions that this is not how OperatesOn should be implemented. He will give some deeper insights in what the original specification by ISO19119 has foreseen.
We have two options here:
A update the TG Metadata so that the guidance is more concise and only explains the GetRecordByID case.
or we have to be much more clear what it really means by referencing a MD_DataIdentifcation object. But that could result in a largescale update of existing metadata records.
Peter Kochmann mentioned again the overview done of all elements mentioned in dataspecifications. (The excel-sheet is attached to WIKI-page) This need to be update to latest versions of
The question that needs to be raised here is how should these elements be handled. There are several possible ways. Please add suggestions on ticket to discuss.
The question that needs to be raised here is how should these elements be handled. There are several possible ways.
Publish the element-overview as an informative document published on the Inspire-web and referenced from TG Metadata document
Add the overview to the TG Metadata as an appendix
Add some of the more commonly referenced elements into TG metadata and describe the implementation in more detail to make these elements more interoparable.
(Even if they are optional they should be handled in a common way by each dataspecfication to be interoparable)
|Status of Draft TG SDS||These guidelines have been published as draft. Should these be published? How will then relation to TG Metadata be ?||Michael L|
|Attach minutes from validation workshop||There are issues that was raised on this workshop that will influence work for TG Metadata. We must also inform Validation WG the issues that we work on and that will affect the ATS:s that are written.||Michael Ö|
|Explain the OperatesOn element||The current use of OperatesOn is not the intention of ISO19119. It shoudl be explained so we can take action if the TGs should be updated based on these findings.||Kristian Senkler|