Use of the `gmd:function` element to distinguish the INSPIRE operations

[ukiz]

In the consolidated approach presented during the third meeting on 11 May, JRC proposed to use the gmd:function element to distinguish the INSPIRE operations. The element would contain information or download values available in the ISO 19139 codelist.

During the meeting it was mentioned that getCapabilities request is always information, so if we agree on its mandatory presence in the Resource Locator, then the gmd:function element could be avoided.

JRC pointed some practical disadvantages of the removal of the gmd:function, i.e. with several resource locators it would need to iterate to discover and distinguish the mandatory linkage element. We would therefore propose to keep the gmd:function for practical reasons.

[MarieLambois]

I think that using "download" for GetMap would create a confusion for the final users as it would say "download" for the view service.

We should really be careful not to over-standardize here. We should only define what is needed for the INSPIRE SDI (and indicators) and let other elements free so that they can be used/defined by member states for other SDIs (national, open data, thematic, etc).

What I remember about @idevisser proposal was tagging only the GetCapabilities operation with the "INSPIRE Spatial data service type" codelist. The INSPIRE SDI would know that it is the GetCapabilities. That's it, we do not need to go further. (Ine : am I correct ?)

[idevisser]

I agree with Marie, we should not over-standardize and keep it as simple as possible. For the INSPIRE SDI, the bare minimum is a URL containing the GetCapabilities (or comparable) for the required "INSPIRE Get Download/View Service Metadata" request, and a value of the "INSPIRE Spatial data service type" codelist. This value should only be used in combination with "INSPIRE Get Download/View Service Metadata" request. The protocol element makes it easier to distinguish between the possible view and download services. The other elements are not really needed and can used for other SDIs.

[pvgenuchten]

Some aspects to consider here:

• function="information" may also be used for links that reference actual information, such as manuals, some clients may not expect to find a capabilities document there (but I'm not aware of any actual implementations using the element)
• Having an explicit element for the getcapabilities operation also helps the case where the element is missing. In a scenario in which a recommended capabilities operation is missing, the client knows that it has to make additional effort to derive the getcapabilities operation (or decide to skip the record).

An example to make this clear:

In the industry it is quite common to reference a WMS,lacking the getcapabilities parameter, so the plain url will return a 500. A client can prevent that by adding the required parameters.

<gmd:onLine>
            <gmd:CI_OnlineResource>
              <gmd:linkage>
                <gmd:URL>https://geo.zaanstad.nl/geoserver/wms?SERVICE=WMS</gmd:URL>
              </gmd:linkage>
              <gmd:protocol>
                <gco:CharacterString>OGC:WMS</gco:CharacterString>
              </gmd:protocol>
              <gmd:name>
                <gco:CharacterString>geo:Atlas_Vlinders_dagvlinders</gco:CharacterString>
              </gmd:name>
            </gmd:CI_OnlineResource>
          </gmd:onLine>

In the INSPIRE simplified scenario, the client could detect from an element that a getcapabilities operation is expected and use the url without adding the parameters.

[dartasensi]

@MarieLambois one minor clarification about the codelist value applicable to the gmd:function

I think that using "download" for GetMap would create a confusion for the final users as it would say "download" for the view service.

I've just follow the annotation, associated to those values, in the official ISO schema. http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#CI_OnLineFunctionCode Let me quote them here:

<!-- === CI_OnLineFunctionCode === -->
<codelistItem>
<CodeListDictionary gml:id="CI_OnLineFunctionCode">
<gml:description>function performed by the resource</gml:description>
<gml:identifier codeSpace="ISOTC211/19115">CI_OnLineFunctionCode</gml:identifier>
<codeEntry>
<CodeDefinition gml:id="CI_OnLineFunctionCode_download">
<gml:description>online instructions for transferring data from one storage device or system to another</gml:description>
<gml:identifier codeSpace="ISOTC211/19115">download</gml:identifier>
</CodeDefinition>
</codeEntry>
<codeEntry>
<CodeDefinition gml:id="CI_OnLineFunctionCode_information">
<gml:description>online information about the resource</gml:description>
<gml:identifier codeSpace="ISOTC211/19115">information</gml:identifier>
</CodeDefinition>
</codeEntry>
[...]
</CodeListDictionary>
</codelistItem>

That's why the download value (ie. trasferring data from one storage device or system to another) sounds appropriate to me, for describing any kind of data transfer as png, gml or zip. Although, I would also agree if we decide to implicitly express the distinction just through the simple use of applicationProfile valued with one the already discussed SpatialDataServiceType codelist.

[MarieLambois]

@dartasensi Your explanation does not really convince me. When you request a WMS you download an image that is a representation of the data but not the data itself. So it does not comply with the ISO definition. Of course each time you send a request to a service you "download" something in the response (the GetCapabilities in XML, an HTML page, etc) so if you take this path you would just have "download" for everything.

[heidivanparys]

CI_OnlineFunctionCode has more values in a more recent edition of the standard, see also https://schemas.isotc211.org/schemas/19115/resources/Codelist/gml/CI_OnLineFunctionCode.xml. browseGraphic would perhaps be the best value. But can newer code lists be used with the old schemas?

[dartasensi]

@MarieLambois apologies, I notice only right now your comment. :) Just few minutes ago, I updated the consolidated proposal, already following your suggestions and discarding the use of function for this purpose.

[idevisser]

Please remove in the proposal the sentence "Finally, the Resource Locator shall contain the gmd:function definition (described before here)." (paragraph view, download and examples)

[MichaelOstling]

I see there some places still in the draft that contains references to use of online function code. I strongly approve that we do NOT use gmd-function.

I see now that Ine just before me wrote the same thing.

[MarieLambois]

Use of gmd:function abandonned in the last proposal.