Question regarding publishing of Download Service metadata (req 53)

[heidivanparys]

I would like to have a clarification regarding the publishing of Download Service metadata. The TG Download Services says that

In order to make the Download Service INSPIRE metadata elements available via a standard WFS it is necessary to use ows:ExtendedCapabilites in the WFS capabilities response and publish the INSPIRE metadata according to an extension schema within an inspire_dls:ExtendedCapabilities element. [...] There are two possible options that may be used and it is up to the implementing Member State to decide which is more appropriate according to need. The first option is to use the ows:ExtendedCapabilities to publish a link to a Download Service metadata record. (e.g. in a discovery service). [...] The second option is to publish all the metadata elements directly in the WFS capabilities (and ows:ExtendedCapabilities) [...]

and later on in the TG, requirement 53 says

INSPIRE Metadata for the Download Service shall EITHER be linked to via an in an extended capabilities section, OR the extended capabilities section shall contain all the INSPIRE Metadata for the Download Service in accordance with Table 4 19 and the inspire_dls:ExtendedCapabilities schema.

So as I understand this, the choice between option 1 and 2 is mutually exclusive. Thus you are not allowed to publish a metadata record AND publish all the metadata elements directly in the WFS capabilities.

Thus when using option 1, you are e.g. not allowed to have an element ows:ServiceIdentification/ows:Abstract in the WFS Capabilities, as the Resource Abstract is documented in the metadata record.

Two metadata element implementations would have to be an exception to this requirement (see also https://docs.google.com/spreadsheets/d/1BRWbh-Hdi53tQ853sQACXGIPoVwobfMZYTab4EkummY/edit?usp=sharing):

1. ows:ServiceIdentification/ows:Title , as it is mandatory according to the WFS Capabilities XML schema.
2. wfs:FeatureTypeList/wfs:FeatureType/wfs:MetadataURL , as this is not only an implementation of the Coupled Resource, but also of the Spatial Data Sets Metadata parameter

My questions:

• Was this indeed what the authors of the TG had in mind when writing this?
• And is it implemented like this in the validation?

For sure, most implementers would like to keep redundancy to a minimum and avoid having all INSPIRE metadata elements documented twice, but may nonetheless find it a good idea to have certain elements documented twice.

In addition to this, I can see that the TG View Services has taken a different approach:

Two scenarios have been identified for publishing View Service metadata conforming to the Regulation on INSPIRE Network Services [INS NS] and on Metadata [INS MD]. It is up to the Member State to choose which scenario best fits its needs. As these scenarios are not mutually exclusive, a Member State may choose to implement both.

This issue is derived from the discussion around issue #81 .

[aquaglia]

Dear Heidi,

There has been quite a lot of confusion about the statement of optionality during the last weeks.

The statement was copied over from the other Technical Guidelines (Discovery and View Services) but it refers to the metadata elements required by the Metadata Regulation.

The additional element SpatialDataSetIdentifier was introduced specifically for WFS services and refers to the additional elements required by the Network Service Regulation.

That is actually the reason why it is called SpatialDataSetIdentifier instead of UniqueResourceIdentifier even though they are supposed to contain the same values:

So, it is intended to be mandatory.

ows:Title, ows:Abstract are supposed to be populated in any case, in order to preserve the functionality of NON-INSPIRE aware clients. It makes sense to use the same values used found in the ISO 19139 metadata.

​ ​

On Wed, May 9, 2018 at 3:05 PM, Heidi Vanparys notifications@github.com wrote:

I would like to have a clarification regarding the publishing of Download Service metadata. The TG Download Services says that

In order to make the Download Service INSPIRE metadata elements available via a standard WFS it is necessary to use ows:ExtendedCapabilites in the WFS capabilities response and publish the INSPIRE metadata according to an extension schema within an inspire_dls:ExtendedCapabilities element. [...] There are two possible options that may be used and it is up to the implementing Member State to decide which is more appropriate according to need. The first option is to use the ows:ExtendedCapabilities to publish a link to a Download Service metadata record. (e.g. in a discovery service). [...] The second option is to publish all the metadata elements directly in the WFS capabilities (and ows:ExtendedCapabilities) [...]

and later on in the TG, requirement 53 says

INSPIRE Metadata for the Download Service shall EITHER be linked to via an

in an extended capabilities section, OR the extended capabilities section shall contain all the INSPIRE Metadata for the Download Service in accordance with Table 4 19 and the inspire_dls:ExtendedCapabilities schema. So as I understand this, the choice between option 1 and 2 is mutually exclusive. Thus you are not allowed to publish a metadata record AND publish all the metadata elements directly in the WFS capabilities. Thus when using option 1, you are e.g. not allowed to have an element ows:ServiceIdentification/ows:Abstract in the WFS Capabilities, as the Resource Abstract is documented in the metadata record. Two metadata element implementations would have to be an exception to this requirement (see also https://docs.google.com/spreadsheets/d/1BRWbh- Hdi53tQ853sQACXGIPoVwobfMZYTab4EkummY/edit?usp=sharing): 1. ows:ServiceIdentification/ows:Title , as it is mandatory according to the WFS Capabilities XML schema. 2. wfs:FeatureTypeList/wfs:FeatureType/wfs:MetadataURL , as this is not only an implementation of the Coupled Resource, but also of the Spatial Data Sets Metadata parameter My questions: - Was this indeed what the authors of the TG had in mind when writing this? - And is it implemented like this in the validation? For sure, most implementers would like to keep redundancy to a minimum and avoid having all INSPIRE metadata elements documented twice, but may nonetheless find it a good idea to have certain elements documented twice. In addition to this, I can see that the TG View Services has taken a different approach: Two scenarios have been identified for publishing View Service metadata conforming to the Regulation on INSPIRE Network Services [INS NS] and on Metadata [INS MD]. It is up to the Member State to choose which scenario best fits its needs. As these scenarios are not mutually exclusive, a Member State may choose to implement both. This issue is derived from the discussion around issue #81 . — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub , or mute the thread .

[bgsmase]

I don't believe the WFS Technical guidance is intended to exclude filling in standard WFS (OWS) elements in the GetCapabilities response if you are providing a link in to INSPIRE metadata. I wouldn't have interpreted it that way even as written but, if the wording "EITHER .. OR" is confusing this could be changed. The XML Schema for the INSPIRE ExtendedCapabilities element itself enforces the choice between "Scenario 1" or "Scenario 2" for the extra INSPIRE metadata elements that aren't mapped to standard WFS GetCapabilities elements.

[bgsmase]

The problem with using wfs:FeatureType/wfs:MetadataURL is that for a WFS supplying features according to an application schema (as INSPIRE services will be) then there isn't necessarily a correspondence between the feature types in a WFS and data sets in the INSPIRE sense. This is different from WCS where an individual coverage listed in the WCS may correspond to a particular data set. It is also different from a view service using WMS where layers may portray particular data sets. That is why section 6.4 of the (WFS) Download Technical Guidance requries a separate WFS endpoint for each INSPIRE dataset. So I don't think wfs:FeatureType/wfs:MetadatURL is the place to put coupled resource or spatial data sets metadata.

[aquaglia]

Dear Heidi, concerning your statement:

*INSPIRE Metadata for the Download Service shall EITHER be linked to via an

in an extended capabilities section, OR the extended capabilities section shall contain all the INSPIRE Metadata for the Download Service in accordance with Table 4 19 and the inspire_dls:**ExtendedCapabilities schema.* *So as I understand this, the choice between option 1 and 2 is mutually exclusive. Thus you are not allowed to publish a metadata record AND publish all the metadata elements directly in the WFS capabilities.Thus when using option 1, you are e.g. not allowed to have an element ows:ServiceIdentification/ows:**Abstract in the WFS Capabilities, as the Resource Abstract is documented in the metadata record.* The intended choice was between: a) adding to the Extended Capabilities all the metadata elements that do not fit in the standard ows capabilities parameters; OR b) to indicate, in the Extended Capabilities, the URL of the service metadata document, in order to avoid at least some of the redundancy; Option b, was never intended to imply leaving ows:Abstract as that would have broken standard NON_INSPIRE clients. Best regards, Angelo On Tue, May 22, 2018 at 4:55 PM, Marcus Sen wrote: > The problem with using wfs:FeatureType/wfs:MetadataURL is that for a WFS > supplying features according to an application schema (as INSPIRE services > will be) then there isn't necessarily a correspondence between the feature > types in a WFS and data sets in the INSPIRE sense. This is different from > WCS where an individual coverage listed in the WCS may correspond to a > particular data set. It is also different from a view service using WMS > where layers may portray particular data sets. That is why section 6.4 of > the (WFS) Download Technical Guidance requries a separate WFS endpoint for > each INSPIRE dataset. So I don't think wfs:FeatureType/wfs:MetadatURL is > the place to put coupled resource or spatial data sets metadata. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > , > or mute the thread > > . >

[MichaelOstling]

Dear Angelo and Heidi, A comment on your discussion above.

So as I understand this, the choice between option 1 and 2 is mutually exclusive

In our Swedish recommendations we suggest users to document using Option 1 (adding a link to service-metadatarecord through ). But since there are clients that may only read the contents of Capabilities we also mention it could be good to have some of the service-metadata copied explicitly into the capabilities according to option 2.

This seems to give us problems. We see that the metadata according to option 1 validates correct but since there also exist some metadata according to option 2 the validator seems to prioritize the check of metadata according to option 2.

Is it not allowed to handle metadata according to both methods? What logic do validator/proxybrowser use to decide what metadata it should check (according to option 1 OR 2)

Regards Michael

[aquaglia]

Dear Michael, Scenario 1 and Scenario 2 for the INSPIRE Extended Capabilities have always been mutually exclusive in all OGC Services as far as it concerns the metadata elements required by the Metadata Regulation.

The SpatialDataSetIdentifier element is NOT part of those, hence it is always mandatory.

Note that it is possible to optionally include the service metadata URL also in Scenario 1.

Angelo Quaglia angelo.quaglia@gmail.com

Il giorno 26 mag 2018, alle ore 08:00, MichaelOstling notifications@github.com ha scritto:

Dear Angelo and Heidi, A comment on your discussion above.

So as I understand this, the choice between option 1 and 2 is mutually exclusive

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/inspire-eu-validation/download-service/issues/88#issuecomment-392239480, or mute the thread https://github.com/notifications/unsubscribe-auth/AAhmKm9nwpNVm2Yuxr9k_QR8fqIIM38cks5t2O-bgaJpZM4T4SB5.

[IGNCNIG]

I agree with @aquaglia