What is the difference between Invocable-Interoperable-Harmonized Network Spatial Data Services?

[InspireGeo]

First off all, I should understand what is exactly different with;

• Not invocable SDS • Invocable SDS • Interoperable SDS • Harmonised SDS • Network services

If someone has proper documentation I will be very grateful ..

Best Regards

[iuriemaxim]

Very good question. I am not the only one that cant understand what should be done for having an interoperable or a harmonised SDS.

I also raised this question here, but in another way in two questions: https://github.com/inspire-eu-validation/community/issues/362 https://github.com/inspire-eu-validation/community/issues/361

I am also interested to get a proper response and not just to be pointed to the TGs of the SDS that are not explicit on what a data provider should do in order to have a harmonised SDS, besides on how to fill the metadata. I am just curious if a Harmonised SDS is not actually a Download Network Service. I am curious why it was made this split NS vs SDS, that had as consequence the elimination of the WPS while playing with the words invoke & invocable and confusion was introduced starting from this schema:

[carlospzurita]

Deasr @InspireGeo and @iuriemaxim

Thank you for raising and discussing this issue, as it is a basic topic that not always is clear for INSPIRE users, newcomers and veterans.

However, we would kindly ask you to move this topic to the INSPIRE forums, as this community space is intended for the validator issues and improvement proposals; this discussion is more on the theoretical side of INSPIRE.

Thank you

[MarcoMinghini]

This issue was originally opened in the Validator helpdesk. We moved it here, since it addresses a more general INSPIRE discussion topic and is not Validator-specific.

[iuriemaxim]

This question is still open as it is not clear and others, including me, have similar questions as can be observed here: https://github.com/INSPIRE-MIF/helpdesk/issues/1

[heidivanparys]

First off all, I should understand what is exactly different with;

• Not invocable SDS • Invocable SDS • Interoperable SDS • Harmonised SDS • Network services

@InspireGeo I created the following Euler diagram that hopefully can shed light on the different kinds of services (the original diagram in SVG format, with clickable links, is available here)

It is not an officially approved figure, but it reflects my view on this. Some supplementary information:

1. The concept "spatial data service" is not specific to INSPIRE. In ISO TC/211 it is usually called "geographic information service", but it means the same really. So that is why there is a box named "INSPIRE spatial data service" on the diagram.
2. The concepts "discovery service", "view service", "download service", "transformation service" and "invoke service" are not specific to INSPIRE. It is a categorisation of services based on the categorisation scheme "usage life cycle" (so a user would first discover a data set, then visualize it, then download it, then do even more advanced stuff, etc.) This is recognised in the current edition of ISO 19119: "services shall be categorised according to a service taxonomy based on architectural areas† and may also be categorised according to a usage life cycle perspective‡, as well as according to domain specific and user defined service taxonomies, providing support for publication and discovery of services". So this is why e.g "discovery service" and "INSPIRE spatial data service" overlap, instead of the "discovery service" being contained in "INSPIRE spatial data service".
3. I would argue that the concepts "discovery service", "view service", "download service", "transformation service" and "invoke service" are by no means specific to the geographic information domain. The same kinds of services can be identified for other domains (perhaps they are called something else, but basically it is the same): e.g. statistical data can be discovered in a portal viewed/visualised as charts, downloaded as CSV files, etc. So this is why e.g "discovery service" and "spatial data service" overlap, instead of the "discovery service" being contained in "spatial data service".
4. "network service" is on the other hand an INSPIRE-specific concept. The term "network service" is used in other contexts, but with a different meaning.
5. "network service" and "invocable spatial data service" are disjoint, an INSPIRE spatial data service is either a network service or an invocable spatial data service, an INSPIRE spatial data service cannot be both. The IR interoperability of spatial data sets and services states this clearly in article 1: "This Regulation does not apply to the network services falling within the scope of Commission Regulation (EC) No 976/2009"
6. A "harmonised spatial data service" is a kind of "interoperable spatial data service", therefore a "harmonised spatial data service" is contained in "interoperable spatial data service" on the diagram.

† That is the classification referred to here in the IR metadata and also available here. ‡ If you have access to ISO 19116:2016: see section 10.11, User-perspective Lifecycle model for Services

[heidivanparys]

I am also interested to get a proper response and not just to be pointed to the TGs of the SDS that are not explicit on what a data provider should do in order to have a harmonised SDS, besides on how to fill the metadata. I am just curious if a Harmonised SDS is not actually a Download Network Service. I am curious why it was made this split NS vs SDS, that had as consequence the elimination of the WPS while playing with the words invoke & invocable and confusion was introduced starting from this schema [...]:

@iuriemaxim The comment above and the diagrams hopefully answer your questions:

• No, a harmonized spatial data service is not a download network service
• WPS is not eliminated as far as I can see. I have no experience with WPS, but depending on the exact processes it implements, I guess a specific installation could be categorised
  • as a transformation service
  • as an invoke service
  • as a service that is neither a discovery, view, download, transformation or invoke service.

(update 14 May 2021: changed the text "It is a non-invocable SDS" to "It is an INSPIRE SDS that is not a Network service and not an invocable SDS" on the diagrams)

[KathiSchleidt]

Many thanks for the diagrams and descriptions, I've also often been down this road of trying to figure out what are the NS (the 5 types listed: discovery, view, download, transformation, invoke), thus by process of elimination determining that the delta left over must be SDS. But, I don't find anything :( Going through the list and adding examples, I come to the following:

• discovery: Catalogue services, e.g. CSW
• view: seems to default to WMS in all cases
• download: here we have a rich set of approved service types, WFS, WCS, SOS, OAPIF, STA
• transformation: assuming WPS, could also include WCPS, but haven't yet seen utilized in INSPIRE
• invoke: ah... this is where I already start getting lost, I'm familiar with invoking services, but am a bit at a loss as to what an invoke service itself would actually be. Working assumption is that this has to do with orchestration, chaining various of the services above within a workflow, but never really confirmed, less seen in operation

However, that brings me to the end of my potential service types (probably due to my lack of understanding) - could somebody please provide a concrete example of what a SDS would actually be? Something other than the often repeated process of elimination pointing to "the rest"?

Actually, the best (albeit politically incorrect ;) ) explanation I've received over the years on both the Invoke and SDS is that these are actually artifacts of the legal transposition of the text - the lawyers involved not familiar with the terminology doing their best to make English legal text from the various technical plans - somehow the words Invoke Service and Spatial Data Service made sense in this process, was never technically challenged. Ever since, brave souls have been searching for a technical content for these legal artifacts. May just be a rumor, but made more sense than anything else I've heard to date! ;)

[iuriemaxim]

Dear @KathiSchleidt and @heidivanparys thank you very much for the clarifications. I have the same or almost the same understanding,

But first I would like to ask a simple question: Can a WMS or WFS (that serves as spatial dataset that is in th scope of INSPIRE, i.e, coresponds to one or multiple INSPIRE Data themes) be an invocable SDS?

I have the same problem as pointed by Kathy, but I will reformulate a little bit: Can somebody provide a concrete example of what an invocable SDS would actually be, if it is disjoined to the network service?

Here is the answer that I found to the above question :) : https://inspire.ec.europa.eu/id/document/tg/sds/4.0/examples

I am almost sure that the TG from 2016 (https://inspire.ec.europa.eu/id/document/tg/sds) created a lot of confusion by disjoining the datasets from services, while defining Interoperable SDS that are not Network services.

If they are not network services and if they neither serve for discovering, viewing, downloading or processing a dataset, what are they? An FTP server is an interoperable SDS? Or maybe a Google Drive or OneDrive folder? But this still would be a download service, even if not one listed in any INSPIRE TG.

Related to the lawyers involved, I also read the text of the INSPIRE Directive. There is no single article which stipulates that the serrvices should be either network services, either should be invocable/interoperable/harmonsided.

Invocability, interoperability and harmonisation refers actually both to the the data and to the services. There are a lot of network services that are neither interoperable, neither the data that is served by them is harmonised. But they are network services, even if they are not compliant. Therefore I cant figure why it was decided that a service could be either a network service alowing spatial dat ato be discovered, viewed, downloaded or pricessed,, either an invocable/interoperable/harmonsised or even another SDS (whatever this could mean if disjoined).

Can someone indicate the Article in the INSPIRE Directive from where it is clear that network services should be disjoined to the invocable/interoperable/harmonised/other SDS and why they cant overlap ?

What I am quite surprised is that there are a lot of people that have the legal understanding that only the datasets that are served by these SDS needs to be harmonised, while there is no obligation to provide trough a WFS or WMS acces to a harmonised dataset. And this is a serious problem. Because data providers should understand if legally they are obliged or not to create harmonised datasets and if they are creating them, then how to allow them to viewed or downloaded if not trough Network Services?

I rather think that the TG from 2016 contradicted the Inspire Directive by mentioning this:

And this is how the invocable SDS appeared, by using "invocable" instead of "invoke", even if this document from 2011 was actually correctly defining "invoke" services.

[iuriemaxim]

Dear @heidivanparys

Thank you for the image that reflects the TG from 2016,

I can imagine one invocable SDS that is neither a discovery/view/download/transformation/(invoke) service: Sending an email to an email address indicated in the metadata of the service as being the "resource locator" of the service of the data provider that is responding with the dataset attached to the email, while both the dataset and the service are described trough INSPIRE valid metadata. Should this be considered as an example of an Invocable SDS? It can be even imagined that the dataset identifier should be indicated in the sebject of the email, while the response could be automatic, but then it will not become a download service? Probably if the data provider will send the dataset by post trough a DVD, then that service could bot be considered a download service. Should this be considered as an example of an Invocable SDS?

If the resource locator should be a URL, then at that URL could be a Form to be filled in order to request the dataset.

I have a certain problem to understand the 5th one (non-invocable SDS). Probably the same service as the above one, but where the Metadata is not valid or the metadata is valid but the email or phone number where to make the request os not provided, so the user should search for this information on Google by knowing the name of the data provider. Could this be considered as an example for a non-invocable SDS?

Please do not considered the above reflections as being humour, as they are not, I just think what invocable SDS could be if coorectly interpreting the existing documents.

If I am corectly interpreting the documentation and the Roadmap ...

... then in theory a data provider can provide a dataset on a DVD by post, if it receives an email at the address that is indicated as being the resource locator in the metadata of the service. In order to fulfill the requirements and the INSPIRE Roadmap, then the dataset on the DVD should be interoperable.

My current understanding, is that the data providers are still obliged to serve that dataset trough network services:

However this decision block creates confusion...

... in relation to this

If I am replacing "invocable" with "invoke" (WPS) then everithing is clear in the INSPIRE implementation roadmap. However this sentence wich "overides" the INSPIRE Directive text states that trough "invoke", a data provider should not understand "WPS", but should read it as "invocable", which is a characteristic which actualy any Network Service has it, but the decision block say that "invocable" should not be a characteristic of a Network Service, as "invocable" spatial data services, should not be "network services".

Therefore instead of allowing and encouraging data providers to create WPS, data providers are allowed to create "invocable" spatial data services, without being clear at al what are they.

As the lawyers were mentioned, didn't they already contradicted the text of the Inspire Directive when they stated this?

From what I know, the European Court of Justice is looking at the text of the Directive and will not agree with the text above, that changed the sense of the Directive.

Most probably EC should reflect to corect the mistake or should provide guidance for a proper or clear understanding of the requirements.

There are a some documents prepared by the EC that states that the "invoke" services are refering to WPS. Here are two examples: https://inspire.ec.europa.eu/documents/Network_Services/Technical_notes_inspire_invoke_services.pdf https://inspire.ec.europa.eu/documents/Network_Services/NSDT_PositionPaper_IR_Invoke_Services_v1.0.pdf

In the documentation of Geoserver is also clarified that "invoke" services are WPS. https://docs.geoserver.geo-solutions.it/edu/en/inspire/intro.html

So, the chart maybe should be adjusted by deleting the "invoke" services if not looking only at the Inspire Directive and understading that "invoke" was transformed into "invocable" in order to create this new category of invocable/interoperable/harmonised/other SDS, instead of aknowledge that Network Services (as well as the datasets served by them) could be either invocable, interoperable or harmonised and that "invoke" services are "WPS".

[iuriemaxim]

@InspireGeo or @carlospzurita Please re-open this "discussion".

[iuriemaxim]

@KathiSchleidt

I can provide some clear examples of "invoke" service easy to be understood, considering that they are WPS according to these documents: https://inspire.ec.europa.eu/documents/Network_Services/Technical_notes_inspire_invoke_services.pdf https://inspire.ec.europa.eu/documents/Network_Services/NSDT_PositionPaper_IR_Invoke_Services_v1.0.pdf and to the Geoserver documentation https://docs.geoserver.geo-solutions.it/edu/en/inspire/intro.html

Trough an Invoke service a user could:

• deterimne the percentage of each category of protected sites (protected areas) in each administrative unit by invoking two services, one that provides access to the protected sites (PS) and another one that provides access to administrative units (AU). The inwoke service will require the two WFS requests or the two datasets in GML format and will return a file with the results (could be either a GML, an XML, CSV or Excel file)
• determine the maximum, minimum, average and standard deviation of the distances between meteorological stations and/or determine the areas where there the distance to any meteorogical station is larger than 50 km, in this case only one service should be invoked (EF), by providing the request that returns the position of meteorological stations
• Determine the total length of various types of roads in a country or in a certain area.
• Determine the lenght of the roads that are crossing and are within protected areas.
• Determine the total area of forests within all and each protected areas by invoking Land Cover and Protected Sites.
• Determine the total area loss/increase of forests within all protected areas in the last 20 years.
• Determine the number of buildings (BU) in the Natural Risk Zones (NZ) of a certain category (i.e. flooded areas).

Such computations are usually made manually in a GIS Desktop, but in applications such computations are done automatically and the users should not be GIS Specialists.

"Invoke" services are actually replacing GIS Specialists with services (robots) for tasks that can be automated.

For example a significant part of the Standard Data Forms for Natura 2000 sites and the corresponding database is filled in Romania automatically trough such processes that are executed on servers every day at 3 AM. Such services could be exposed as WPS to allow users to make their own computations without using a GIS and without being necessary for them to know and learn ArcGIS Desktop or qGIS or other GIS software.

We even imagined and designed a system to create hazard maps automatically from flood risk maps and exposed elements (all are NZ) trough a WPS in order to allow concurent users to process their data in the cloud, where hardware resources can be increased in order to meet the deadlines, by taking into consideration the number of concurent processing and size of the areas that are processed in a continuous work-chain 24/7.

[heidivanparys]

@KathiSchleidt

invoke: ah... this is where I already start getting lost, I'm familiar with invoking services, but am a bit at a loss as to what an invoke service itself would actually be. Working assumption is that this has to do with orchestration, chaining various of the services above within a workflow, but never really confirmed, less seen in operation

I also think that the original idea had to do with workflow engines. I found at least two documents that mention BPEL: https://kortforsyningen.dk/sites/default/files/old_gst/DOKUMENTATION/Data/Emigreret_fra_www2/Kortforsyningsseminar2009/KFseminar2009_AFC_geoportal.ppt says "invoke: Enables and controls the execution of spatial data services; Business Process Execution Language (BPEL)" (slide 18) and http://inspire.ec.europa.eu/documents/Network_Services/Technical_notes_inspire_invoke_services.pdf also mentions "workflow engine" and "BPEL" a few times

However, that brings me to the end of my potential service types (probably due to my lack of understanding) - could somebody please provide a concrete example of what a SDS would actually be? Something other than the often repeated process of elimination pointing to "the rest"?

The classification from ISO 19119 can give some inspiration, see also https://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceCategory. E.g. a feature generalisation service could be a good candidate.

Actually, the best (albeit politically incorrect ;) ) explanation I've received over the years on both the Invoke and SDS is that these are actually artifacts of the legal transposition of the text - the lawyers involved not familiar with the terminology doing their best to make English legal text from the various technical plans - somehow the words Invoke Service and Spatial Data Service made sense in this process, was never technically challenged. Ever since, brave souls have been searching for a technical content for these legal artifacts. May just be a rumor, but made more sense than anything else I've heard to date! ;)

My personal opinion is that proper clarification of concepts and terms, ánd documenting all that in a glossary of some sort, should be done before legislation enters into force, as we here see the consequences of not doing so. See e.g. https://en.digst.dk/policy-and-strategy/digital-ready-legislation/ and https://en.digst.dk/media/20206/en_guidance-regarding-digital-ready-legislation-2018.pdf (principle 4: Consistency across authorities - uniform concepts and reuse of data).

[heidivanparys]

@iuriemaxim

But first I would like to ask a simple question: Can a WMS or WFS (that serves as spatial dataset that is in th scope of INSPIRE, i.e, coresponds to one or multiple INSPIRE Data themes) be an invocable SDS?

A WMS is a view service, a WFS is a download service. So those services are network services, not invocable spatial data services.

I have the same problem as pointed by Kathy, but I will reformulate a little bit: Can somebody provide a concrete example of what an invocable SDS would actually be, if it is disjoined to the network service?

The classification from ISO 19119 can give some inspiration, see also https://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceCategory. E.g. a feature generalisation service could be a good candidate.

Related to the lawyers involved, I also read the text of the INSPIRE Directive. There is no single article which stipulates that the serrvices should be either network services, either should be invocable/interoperable/harmonsided.

[...]

Can someone indicate the Article in the INSPIRE Directive from where it is clear that network services should be disjoined to the invocable/interoperable/harmonised/other SDS and why they cant overlap ?

Please note that the implementing rules are also legally binding, see also the figure below. So the relevant legally binding text is article 1 in the IR ISDSS (Regulation 976/2009 being the IR NS):

This Regulation does not apply to the network services falling within the scope of Commission Regulation (EC) No 976/2009

Thank you for the image that reflects the TG from 2016

As I said, the image reflects as how I see it, so I cannot guarantee it is a 100% correct, but the idea was that it should reflect what is said in the legislation (Directive plus Implementing Rules). Which is why the diagram includes "invoke service", although https://inspire.ec.europa.eu/id/document/tg/sds does not have "invoke service" in its diagram.

I have a certain problem to understand the 5th one (non-invocable SDS). Probably the same service as the above one, but where the Metadata is not valid or the metadata is valid but the email or phone number where to make the request os not provided, so the user should search for this information on Google by knowing the name of the data provider. Could this be considered as an example for a non-invocable SDS?

(I corrected the previous diagrams to say "INSPIRE SDS that is not a Network service and not an invocable SDS" instead of "non-invocable SDS"). The IR ISDSS states:

‘Invocable spatial data service’ means all of the following:

(a) a spatial data service with metadata which fulfils the requirements of Commission Regulation (EC) No 1205/2008 ( 3 ), (b) a spatial data service with at least one resource locator that is an access point, (c) a spatial data service in conformity with a documented and publicly available set of technical specifications providing the information necessary for its execution

My guess is that it is point b and c that are important here. So if there e.g. is an INSPIRE spatial data service, that is not a network service, and without specification, so without the information necesary for its execution for an external user, then that external user cannot actually use that service, hence the service is non-invocable. Perhaps an analogue service or a service that involves sending a mail would fit here as well, but I would ask for a second opinion here.

[heidivanparys]

So, the chart maybe should be adjusted by deleting the "invoke" services if not looking only at the Inspire Directive and understading that "invoke" was transformed into "invocable" in order to create this new category of invocable/interoperable/harmonised/other SDS, instead of aknowledge that Network Services (as well as the datasets served by them) could be either invocable, interoperable or harmonised and that "invoke" services are "WPS".

The terminology can be confusing indeed. "invocable spatial data service" in an INSPIRE context should not be understood as "normal" English (so as in "spatial data service that can be invoked", "spatial data service that can be called") but should be understood as defined in article 2 of the IR ISSDS. "invocable non-network service" would be closer to "normal" English I guess, at least for the "invocable" part. But we have to stick to the terms in the current legislation.

The same reasoning goes for the other terms (interoperable, harmonized).

But I don't agree that "invoke" was transformed to "invocable".

This means that discovery network services need to provide access also to the additional SDS metadata elements, which contain, among other things, information necessary for the invocation of SDS. Through the provision of these metadata additional elements, the obligation to provide (network) “services allowing spatial data services to be invoked” is being fulfilled.

I don't know the background for this formulation in https://inspire.ec.europa.eu/id/document/tg/sds. @alexanderkotsev @michellutz Who could provide more info about this? Is it perhaps just meant as a clarification that, for a given dataset, an "invoke service" associated to that data set does not necessarily have to exist (in contrary to a download service: it must always be possible to download that data set)? And if a data provider has established a workflow engine on one or more INSPIRE spatial data sets, then that service is an INSPIRE spatial data service, it has type "invoke service", and it must be compliant with the IR metadata and IR network services.

For the transformation services, such a clarification is already in the Directive: "Spatial data sets shall be made available in conformity with the implementing rules either through the adaptation of existing spatial data sets or through the transformation services referred to point (d) of Article 11(1)."

[KathiSchleidt]

@heidivanparys I love the idea of requiring clear definitions for all relevant terms BEFORE finalization of a legal act!

I just checked IATE to see if similar definitions existed from other legislation, but all comes from the known bits around INSPIRE and it's followup regulations.

Alternatively, as this issue has caused a great deal of confusion for a long time now, do you think it could be possible to get extended definitions (e.g. on invoke services more than service that allows defining both the data inputs and data outputs expected by the spatial service and a workflow or service chain combining multiple services, still reads close to a processing service) together with examples somewhere on the official INSPIRE pages. I believe such clarification would save many people much time!

[iuriemaxim]

Dear @heidivanparys, the answer is really helpful.

The classification from ISO 19119 can give some inspiration, see also https://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceCategory. E.g. a feature generalisation service could be a good candidate.

Indded now I can identify in the https://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceCategory some SDS that cant be considered network services. Hovever a feature generalisation is still a LATER EDIT geographic processing service, so it is a network service, isn't it? But services such as the following ones indeed do not seems to be Network Services,:

• Order handling service
• Standing order service
• Registry Service
• Subscription service
• Messaging service
• Remote file and executable management
• Geographic feature editor
• Geographic spreadsheet viewer
• Geographic symbol editor
• Geographic viewer
• Service editor

All that are clasified as Geographic Processing Service, I think that are falling inside transformation services and invoke services, or at least can be implemented trough OGC WPS.

But indded there are services listed there that are not Network Services.

I have a problem in identifying which one are or could be considere invovable, interoperable or harmonised and which ones fall into "other SDS" category. So please provide some guidance.

I have also a problem to classify these ones as being SDS according to this decision block, by in some cases I can imagine, but this is stil unclear to me. Any comments are welcomed.

I understand then that the INSPIRE Registry falls into SDS category. Is this correct?

I have also a problem understanding what should be done to an SDS that is invocable in order to make it interoperable or harmonised:

Can the INSPIRE Registry become interoperable or harmonised?

Can be provided an exanple of an interoperable and harmonised SDS?

Thank you for the clarifications, Iurie

[KathiSchleidt]

to Can the INSPIRE Registry become interoperable or harmonised?

I just compared the 2 INSPIRE metadata-codelists:

• Spatial data service type: List of the well known Network Services plus "Other"
• Classification of spatial data services: 78! different types of potential services

The first codelist would actually imply that Spatial Data Services ARE Network Services (or are the SDS the Other?), while the 2nd blows my mind! Apart from clarifying what the first codelist implies pertaining to NS vs. SDS, I'd really like a matrix of the 78 entries from the classification to the service types (with or without SDS ;) )

[iuriemaxim]

Hi @KathiSchleidt,

The first codelist would actually imply that Spatial Data Services ARE Network Services (or are the SDS the Other?), while the 2nd blows my mind! Apart from clarifying what the first codelist implies pertaining to NS vs. SDS, I'd really like a matrix of the 78 entries from the classification to the service types (with or without SDS ;) )

Here I can provide some insights: All those listed as "Geographic Processing Service" are Network Services, either "transformation services" or "invoke services".

An example of a "Feature access service" is the WFS An example of a "Map access service" is a WMS An example of a "Coverage access service" is a WCS An example of a "Catalogue service" is a CSW

So almost sure all the above and the ones classified as "Geographic Processing Service" are "Network Services".

I have a problem to clarify if a "Gazetter service" is a "Network Service" or not, but maybe with very few exceptions all the other falls i o "Network Services" are not "Network Services".

I cant see however how the rest of the services in the list could become interoperable or harmonsied (where applicable), as the IR is requesting this. But of course first we should clarify if all those are ”spatial data services” as defined by the INSPIRE Directive”.

The INSPIRE Directive:

And "harmonis" should be searched as well in the INSPIRE Directive. The result is

In any case, none of the two codelists are legally binded by the text of the Directive and the code list of the SDSs is not legally binded by any other legislation. The value "Other" in the "Spatial data service type" codelist was added in order to allow this decision block which is not sustained however by the text of the INSPIRE Directive:

[iuriemaxim]

Dear @KathiSchleidt I raised a question to the INSPIRE Registry Helpdesk in order to clarify the content of the Spatial Data Services Codelist.

Question is here: https://github.com/INSPIRE-MIF/helpdesk-registry/issues/19

[iuriemaxim]

By analysing the Article 7 of the INSPIRE Directive there are certain conclusions:

A) From this paragraph: "Implementing rules laying down technical arrangements for the interoperability and, where practicable, harmonisation of spatial data sets and services, designed to amend non-essential elements of this Directive by supplementing it..."

Conclusion 1: Interoperablity and where practicable harmonisation are characteristics of both:

• Spatial Data Sets
• Services (text is refering to "services" and not to ”Spatial Data Services”, so it is not very clear if the text is refering to "Spatial data services" as defined in article 3 of the Directive, or to "Services")

Conclusion 2: Interoperablity and where practicable harmonisation characteristics are designed to amend non-essential elements of INSPIRE Directive.

B) From this paragraph: "Where organisations established under international law have adopted relevant standards to ensure interoperability or harmonisation of spatial data sets and services, these standards shall be integrated, and the existing technical means shall be referred to, if appropriate, in the implementing rules mentioned in this paragraph."

Conclusion 3: Standards that ensure Interoperability and harmonisation of spatial data sets and services, from international organisations, (such as for example ISO), shall be integrated, while the technical means could be reffered into IR if appropriate.

C) From this paragraph: "Member States shall ensure that all newly collected and extensively restructured spatial data sets and the corresponding spatial data services are available in conformity with the implementing rules referred to in paragraph 1 within two years of their adoption, and that other spatial data sets and services still in use are available in conformity with the implementing rules within seven years of their adoption. Spatial data sets shall be made available in conformity with the implementing rules either through the adaptation of existing spatial data sets or through the transformation services referred to point (d) of Article 11(1)."

Conclusion 4: newly collected and extensively restructured spatial datasets are coresponding to newly collected and extensively restructured spatial data services (which serves these spatial datasets), so it is not possible to have a spatial data service that is not coresponding to at least one spatial data set.

Conclusion 5: The text "Spatial data sets shall be made available in conformity with ..." is setting requirements for spatial data sets not for spatial data services. Spatial data services are corresponding to spatial data sets. This is also clarified in the next paragraph.

D) From this paragraph: "4. Implementing rules referred to in paragraph 1 shall cover the definition and classification of spatial objects relevant to spatial data sets related to the themes listed in Annex I, II or III and the way in which those spatial data are geo-referenced."

Conclusion 6: Implementing rules referred to in paragraph 1 shall cover definition and classification of spartial objects relevant to spatial data sets related to the data themes listed in Annex I, II or III. No reference exist for "services" or "spatial data services" in this phrase.

My personal considerations: 1) There is no article in the INSPIRE Directive mentioning that other services than the Network Services should exist.

2) According to INSPIRE Directive " 'spatial data services’ means the operations which may be performed, by invoking a computer application, on the spatial data contained in spatial data sets or on the related metadata;". Therefore the list of SDS that is in the INSPIRE Registry (here https://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceCategory) is not correct, as there are a lot of services listed in the INSPIRE Registry there that are not operating on a spatial data set or its related metadata. For example "Geographic symbol editor" is not an SDS according to the definition in the INSPIRE Directive.

3) According to INSPIRE Directive " ‘interoperability’ means the possibility for spatial data sets to be combined, and for services to interact, without repetitive manual intervention, in such a way that the result is coherent and the added value of the data sets and services is enhanced;". So interoperability is defined for both spatial data sets and for "services". However the IR for Interoperability seems not to fully reflect this definition.

4) There are no such "invocable services" or "invocable spatial data services" defined or mentioned in the INSPIRE Directive. However there are "invoke" services mentioned in the directive. Therefore the following text contradicts the INSPIRE Directive and also it is not correct.

5) The article 7 from the CHAPTER III - INTEROPERABILITY OF SPATIAL DATA SETS AND SERVICES was made in order to ensure that "spatial data sets can be combined, and that services can interact, without repetitive manual intervention, in such a way that the result is coherent and the added value of the data sets and services is enhanced". Interoperability must be ensured for all data sets and for their corresponding services. Interoperability must be ensured for all data sets (served trough Network Services).

6) An example of ensuring interoperability according to article 7 of the Directive could be serving a dataset in a GeoJSON format instead of the GML format, while the spatial data could be served trough OData instead of a WFS. An example of harmonisation for the service, could be the operations that should be mandatory for the OData (i.e. provide "apply" and "extend" functionality). An example of the harmonisation of the spatial data set served trough OData could be the names of the structure of the GeoJSON file.

7) Another example of ensuring interoperability and harmonisation where practicle according to Article 7 of the Directive coould be considered the interoperability rules that should be provided for ensuring that datasets served trough SensorThings API are interoperable (so they can be combined).

8) According to the defininition of Interoperability for datasets from the INSPIRE directive, that means that the data can be combined, it means that it is important that the data should be combined. Combination of data can be made only trough processing services (invoke services) and interesting but IR for interoperability was based on the fact that invoke services do not exist, because all services are invocable trough metadata. But invoke services are not the same with invocable services. Only invoke services allows data to be combined and unfortunately exactly this kind of service that allows ensuring interoperability was excluded and not treated accordingly to its importance.

[KathiSchleidt]

@iuriemaxim

To your point 6 above on utilizing OData, for OGC SensorThings API we do, and are now endorsed as an official INSPIRE Good Practice However, for the wider feature world, looks like OGC API - Features is the accepted way forward. A bit sad as doesn't have all the rich query options of OData and STA, but to each their own (we can now extend STA with other spatial features, keeping the OData power)

Thus both of these APIs now qualify as INSPIRE Download Services (same applies to SOS and WCS - only bit missing on WCS are the data models, now also mostly sorted via the Coverage Good Practice

What IS missing is a plan on how to make these similar but different OGC APIs interoperable, one of the many cool outputs of the API4INSPIRE project

[iuriemaxim]

@KathiSchleidt This is exactly what I mean, that interoperability and harmonisation is not a characteristic for "Other" Spatial Services, but they are characteristics of "services", aka Network Services.

And indeed in the first instance I thougt to include in point 6 the WPS, but I just thought that SensorThings API is a better example for people to understand.

This can be read as well in order to understand various positions, as there are data provides that claim that the datasets that are served trough Network Services should not be valid (should not be interoperable/harmonised): https://github.com/INSPIRE-MIF/helpdesk-validator/issues/39

So for me it was clear even from 2016 that the TG and IR for Interoperability was wrongly designed. But as we are approaching the 2021 last deadline in implementing the INSPIRE Directive, it should be clarified that legaly there are no "Other" SDS, but only Network Services. Alternatively, if data providers are required to transform the "invocable" services into interoperable or where practical harmonised services, then it should be very clear what are these invocable services that should be transformed into interoperable/harmonised services.

So the question remains opened.

[heidivanparys]

I just compared the 2 INSPIRE metadata-codelists:

• Spatial data service type: List of the well known Network Services plus "Other"

• Classification of spatial data services: 78! different types of potential services

The first codelist would actually imply that Spatial Data Services ARE Network Services (or are the SDS the Other?) [...]

@KathiSchleidt How do you come to that conclusion?

"spatial data service" is a generic concept, not an INSPIRE-specific concept, see the definition in article 3 of the INSPIRE Directive.

A network service is a spatial data service that is in the scope of INSPIRE and that is one of the following:

• discovery service
• view service
• download service
• transformation service
• invoke service

So a network service is a kind of spatial data service.

On the other hand, a spatial data service that is in the scope of INSPIRE is not necessarily a network service.

A spatial data service that is in the scope of INSPIRE and that is not a network service - thus a service that is located in the grey area on the figure below -, must have metadata element "spatial data service type" set to http://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType/other

Some confusion may arise from the following in https://inspire.ec.europa.eu/id/document/tg/sds:

Those SDS that are not network services, but fulfil the requirements of Commission Regulation (EC) 1205/2008, have at least one resource locator and follow a publicly available technical specification are called invocable spatial data services. All invocable SDS shall meet the requirements specified in [INS ISDSS]. All other SDS are referred to in this document as other SDS.

The "other SDS" as described in https://inspire.ec.europa.eu/id/document/tg/sds is a service located in the light blue area on the figure below.

So the "other" in http://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType/other is not the same as "other" in https://inspire.ec.europa.eu/id/document/tg/sds, the "other service" in http://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType/other is broader than "other SDS" in https://inspire.ec.europa.eu/id/document/tg/sds.

All the following kinds of services will have metadata element "spatial data service type" set to http://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType/other:

• invocable SDS
• interoperable SDS
• harmonised SDS
• non-invocable and non-network INSPIRE SDS

[heidivanparys]

Hovever a feature generalisation is still a transformation service, so it is a network service, isn't it?

@iuriemaxim I don't know how the text of the Directive should be interpreted. As always, the definition should be checked before assuming anything just from the term. It says (highlighting is mine): "transformation services, enabling spatial data sets to be transformed with a view to achieving interoperability"

I am not sure whether feature generalisation can be categorized as a service that transforms data "with a view to achieving interoperability". I would say the goal of a feature generalisation is a different goal. But again, I am not a legal expert, these are just my thoughts.

[heidivanparys]

A general comment: metadata for all data sets and service on the INSPIRE Geoportal can be browsed via the "Resource browser"

There you can see what services were classified by the member states as http://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType/other

If you e.g. narrow the results down to "humanInteractionService", you'll find the metadata of the Arctic SDI portal.

[iuriemaxim]

@heidivanparys

Lets take one by one. This post will treat only this:

"spatial data service" is a generic concept, not an INSPIRE-specific concept, see the definition in article 3 of the INSPIRE Directive.

INSPIRE Directive is defining ‘spatial data services’ means the operations which may be performed, by invoking a computer application, on the spatial data contained in spatial data sets or on the related metadata; (it can be noted that plural is used)

If this is the definition, then the "Registry service" or "Geographic symbol editor", both listed in https://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceCategory cant be considered "spatial data services" according to definition from the INSPIRE Directive.

First I cant understand why "Registry service" or "Geographic symbol editor" were listed as "Spatial Data Services Categories" (note: not as Spatial Data Services, but as Spatial Data Services Categories), as there is no spatial data contained in spatial datasets on which the service operates, neither a related metadata to a spatial dataset served by the service and neither they are "operations that may be performed on the spatial data". Many other SDS (SDS categories) from the 78 records in the INSPIRE Registry are not operating on a spatial dataset and none of them are operations, so they are not "Spatial Data Services" according to INSPIRE definition.

Of course somebody may claim that the list in the INSPIRE Registry is not containing the list of "Spatial Data Services", but it is containing the "Spatial Data Services Categories", whatever "categories" would mean. But we are interested to find which are those "Spatial Data Services" that are not "Network Services" or if INSPIRE "Spatial Data Services" are overlaping with "Network Services" or are the same as "Network Services", or if they are inddeed "services", or even something else, from the INSPIRE Directive perspective (not from subsequent legislation or Technical Guidlines which should not contradict or missinterpret the INSPIRE Directive). So we should understand the definition of the 'spatial data services'.

It seems that there is no legal text which is listing the 78 items from the INSPIRE Registry as being "Spatial Data Services" (or Spatial Data Services Categories) according to INSPIRE definition. If there is a legal text from where the 78 items were taken to populate this list, https://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceCategory, would be good to see it and understand the context for these "categories".

Even if "Spatial Data Services" may apper to be a generic concept, this is not true at all, as there is no such definition in OGC https://www.ogc.org/ogc/glossary/all and none can be found in ISO.

Even if OGC is using certain terms that could sematically have the same semnification, INSPIRE has its own definition for this concept that is not generic at all.

Searching for "Spatial Data Service" or "Spatial Data Services" on Internet, will reveal that this term is used in documents related to INSPIRE and is used also by Microsoft, in relation with for Bing Maps.

Therefore "Spatial Data Services" it is not a generic concept as it may appear to be.

As can be seen in the images below, the 78 items listed in the INSPIRE Registry as being "Spatial Data Services Categories" are not mentioned with this terminology by OGC, as both "Network Services" and "Spatial Data Services" therms are caracteristic to INSPIRE only.

Reading the definition carefully <<‘spatial data services’ means the operations which may be performed by invoking a computer application,...>> it may be understood that the 'spatial data services' are the operations. The 'spatial data services' are not the "computer aplication" which is the "service", but are "operations" of a "service".

A service such as WFS is a computer application, but operations ('spatial data services' according to the INSPIRE definition) are these ones:

So, then, what are "Spatial Data Services" according to the definition of the INSPIRE Directive, if the "'spatial data services’ means the operations which may be performed"...?

The OGC glssary is also clarifying what are operations (https://www.ogc.org/ogc/glossary/all).

It should be noted that INSPIRE Directive is using plural in the definition of the 'spatial data services', while all the other definition are using singular, as it is normally to be expressed in any legal act and in any scientific paper. However there are many operations offered by a "computer aplication" (service) which may be performed "on the spatial data contained in spatial data sets or on the related metadata" and thats why plural was used, to clarify that the definition refers to all operations offered by a service.

And indded I am almost sure that the IRs and TGs wrongly interpreted the definition of "INS spatial data services" and as a consequence data providers cant understand what are they required to do in order to make the "IR spatial data services" interoperable and where practicable harmonised.

My understanding based on INSPIRE Directive definition for 'spatial data services', is that for the OGC Web Feature Service, the INSPIRE 'spatial data services' are:

• GetCapabilities
• DescribeFeatureType
• GetFeature

I know that this is hard to digest, but this is what the definition of the "spatial data services" from the INSPIRE Directive is mentioning.

I can read the definition from INSPIRE Directive "‘spatial data services’ means the operations which may be performed, by invoking a computer application, on the spatial data contained in spatial data sets or on the related metadata" as follows:

‘spatial data services’ are the operations on the spatial data contained in spatial data sets or on the related metadata, which may be performed, by invoking a computer application (service);

"GetCapabilities" operation falls under "related metadata" category, while "GetFeature" operation falls under "operations on the spatial data contained in spatial data sets".

The operations are characterised by the requests to a service and responses from a service.

Important: The sintagm "spatial data sets and services" used in the INSPIRE Directive does not refer to "spatial data sets" and "spatial data services". It refers to "spatial data sets" and "services".

The sintagm "spatial data services" is used 3 times in the INSPIRE Directive (except in the definition section), namely in:

Article 4. Paragraph 3. This Directive shall also cover the spatial data services relating to the data contained in the spatial data sets referred to in paragraph 1

Article 7. Paragraph 3 Member States shall ensure that all newly collected and extensively restructured spatial data sets and the corresponding spatial data services are available in conformity with the implementing rules referred to in paragraph 1...

Article 11 (e) services allowing spatial data services to be invoked.

So, lets first clarify the definition of "spatial data services" (plural used in the INSPIRE Directive) and then we can continue with the rest.

PS: Sorry for this: Hovever a feature generalisation is still a transformation service, so it is a network service, isn't it? I corrected it into "Hovever a feature generalisation is still a geographic processing service, so it is a network service, isn't it?" I am referring here to the fact that "feature generalisation" falls in the article 11 (e) category: "services allowing spatial data services to be invoked" which now probably can be better understood, as previously most people read it as "a service allowing services to be invoked" and this mistake was further perpetuated in TG and IR.

[iuriemaxim]

@KathiSchleidt With the hope that this subject will be clarified, I raised a second batch of questions at the INSPIRE Registry, now related to the Spatial Data Service Type Codelist, here: https://github.com/INSPIRE-MIF/helpdesk-registry/issues/20

[heidivanparys]

@InspireGeo As you are the original author of this issue: I hope that the explanation in https://github.com/INSPIRE-MIF/helpdesk/issues/25#issuecomment-840468560 on your question on the difference between the different kinds of services has been answered sufficiently.

Follow-up on the discussion here:

• The aforementioned diagram is an unofficial diagram, but I can explore the options to get the approval of the MIG(-T) on this or a similar diagram for inclusion into more official documentation, if needed.
• I can also explore the options for at some point updating the Technical Guidance for INSPIRE Spatial Data Services and services allowing spatial data services to be invoked in order to clarify what was discussed at https://github.com/INSPIRE-MIF/helpdesk/issues/25#issuecomment-842118830
• Some of the questions raised here are raised as separate issues: #26, https://github.com/INSPIRE-MIF/helpdesk-registry/issues/19 and https://github.com/INSPIRE-MIF/helpdesk-registry/issues/20 and follow-up should occur there.

[iuriemaxim]

@heidivanparys Can we conclude than that "spatial data services" as defined by the INSPIRE Directive are operations such as GetCapabities, GetFeature, GetMap, etc?

[iuriemaxim]

As first I tried to clarify that this is not correct at all: "spatial data service" is a generic concept, not an INSPIRE-specific concept, see the definition in article 3 of the INSPIRE Directive.

I can analyse the next: A network service is a (kind of a) spatial data service

In the article 3 of the INSPIRE Directive exist the following definition "‘spatial data services’ means the operations which may be performed, by invoking a computer application, on the spatial data contained in spatial data sets or on the related metadata;"

Therefore A network service is a (kind of a) spatial data service would mean that:

"A network service" is (a kind of a) "(the) operations which may be performed, by invoking a computer application, on the spatial data contained in spatial data sets or on the related metadata". ("operations" is used with plural form).

This is also incorrect even if plural is used: "Network services" are (a kind of) "operations which may be performed, by invoking a computer application, on the spatial data contained in spatial data sets or on the related metadata"

The above sentence does not seems to be correct. Correct could be that "network services are services". And the word "services" is used alone in the INSPIRE Directive many times.

According to OGC SA could be also correct "A network service is a geographic service" and "Network services are part of geographic model/information management services"

"Operations such as GetCapabilities, GetMap, GetFeature etc can be performed on Network Services" could be correct too.

Or "Comunication with Network Services is done trough operations" is correct too.

Simmilar "Communication with Network Services is done trough spatial data services" could be correct too. (note that spatial data services is always used by using plural in the INSPIRE Directive).

INSPIRE Directive is using the following therms: "Network services", "A network of services" and "services".

Now this type of service: "services allowing spatial data services to be invoked" reads more normal as: "services allowing operations which may be performed on the spatial data contained in spatial data sets, to be invoked"

A "network service" is not a "spatial data service" according to the INSPIRE Directive, also because the Directive is using plural for both these therms.

It is not correct to say neither that a "network of services" are (a kind of) "spatial data services".

INSPIRE Directive is always using "network services" at its plural form because it means a "network of services" as it is clarified in article 11. ("Member States shall establish and operate a network of the following services")

Both "network services" and "spatial data services" are not generic concepts, but concepts that are used ONLY in the INSPIRE Directive context.

[heidivanparys]

@iuriemaxim I am not in a position to draw any final conclusions on this topic. I would be happy to bring the discussion on this comment's diagram and underlying assumptions to the MIG-T and try to seek to a consensus diagram and final conclusions, as also proposed in https://github.com/INSPIRE-MIF/helpdesk/issues/25#issuecomment-845926742.

In order to keep the overview I would like to close this issue soon, if @InspireGeo 's question has been answered sufficiently, and follow-up on the different topics touched upon here as proposed in https://github.com/INSPIRE-MIF/helpdesk/issues/25#issuecomment-845926742 (that is, follow-up in separate issues).

[KathiSchleidt]

@heidivanparys as we've been through this discussion time and time again, manage to reach some educated assumptions but never get these confirmed, I think many people would appreciate some more formal clarification/confirmation on these theories - otherwise we'll be back to this discussion next year! To my view, this service type topic would warrant a dedicated page, ideally including your diagram, maybe also explaining the difference between Network Services, Spatial Data Services, the various classifications of Spatial Data Services mentioned above

Think you could bring this to the MIG-T?