Response to INSPIRE Network Services Architecture

From OSGeo
Jump to: navigation, search

The Network Services Architecture is not an Implementing Rule but does have a lot of impact on SDI work in Europe.

The current draft proposes a GeoRM layer (even a null one) before all INSPIRE services. It offers some arguments in favour of SOAP bindings for all OWS and other services, but is actively seeking consultation from implementor/user communities on the usage of SOAP/WSDL in the frame of setting up an SDI.

The consultation ends Feb 18th 2008.

Responses

6.1 paragraph 2 - "The goal of discovery is to support discovery" is tautological - first "discovery" should read "discovery services", second "discovery of data" or similar clearer wording.

6.6 - describes "registry services" as being separate from "discovery services", which is debatable or even misleading, as discovery services depend on a registry and repository being available. - should provide clearer guidance as to how a "registry service" relates to storage of metadata and searching for data.

7 paragraph 3 (list of "arguments in favour of SOAP") - see SOAP for detail

7 paragraph 7 point 1 (describing figure 7.2) - states that public authorities in Member States do not have to comply with the INSPIRE Network Service Definitions (e.g. the IRs) if the Member State is running an INSPIRE-compliant portal with access to data services they provide - should provide a reference to where, in the INSPIRE Directive text or in any of the Implementing Rules, this exception to compliance is allowed.

7 paragraph 7 point 3 - "INSPIRE service ... can be realised by a facade which cascades". The phrase "facade which cascades" has no clear or common technical meaning and should be explained. Rewrite to expand, or remove, the facade statement.

7.2 paragraph 2 - suggests applying an empty GeoRM filter to services which have no restrictions (all Discovery Services and most View Services according to the Directive text. The performance impact of this is unknowable and may provide a severe bottleneck for services. Does not take into account common practises in "caching" content from view services (TMS, WMTS), how will a GeoRM filter be cached along with an imagery tile, by potentially unknown hosts? - There is no formal GeoRM specification yet - the document goes on to state that it is "early state-of-the-art". Its inclusion in a reference architecture is pre-emptive.

7.3 paragraph 3 - "The service usage is always mono-lingual". This will not be the case in areas of Europe where there are 2 or more administrative languages available in a national-level interface, for example Catalan and Castellano, or Flemish and Walloon - nor at the EU level. - This assumption should be removed.

7.4 Table 1 - "reliability" should read "availability" and "availability should read "reliability"

Appendix A para 3 - "The INSPIRE Directive recognises the critical importance of public authorities property rights" - this strongly-worded statement about critical importance is untrue to both the letter and the spirit of the Directive text, which merely states that it should not affect the existence or ownership of public authorities' intellectual property rights. The statement should be reworded or removed.

Appendix A para 7 - It is not correct to state that CC licensing options are made available for "essentially static content". The definition of static is not clear, and there is clear precedent for CC licenses being used for information that changes frequently, for structured data in general and for geographic data sets maintained by European public authorities. IGN, Spain's NMA for example, are publishing the PNOA dataset or aerial imagery under a CC-BY-SA-NC license. Other CC-inspired models such as Science Commons' CC0 proposed data license, and the Open Database License which takes into account European database rights law as well as copyright law, are certainly not limited to "static" content. - This statement should be reworded or removed.