search

inspire-eu-validation / download-service

Abstract Test Suite for the Technical Guidance for the implementation of INSPIRE Download Services
Creative Commons Zero v1.0 Universal
2 stars 4 forks source link

Issue with description of inspire_dls:SpatialDataSetIdentifier in TG (test Service Metadata) #81

Open heidivanparys opened 6 years ago

heidivanparys commented 6 years ago

There seems to be a problem with the last entry in table 19 in the Technical Guidelines. This is of relevance to test Service Metadata and its implementation.

This table describes the mapping of the INSPIRE metadata elements of a download service to the Capabilities, and the last entry in the table describes the mapping of the mandatory Unique Resource Identifier. But

Proposal for solution:

image

[...]

image

image

cportele commented 6 years ago

Another topic the MIG-T subgroup should discuss. Thanks, Heidi!

heidivanparys commented 6 years ago

From https://ies-svn.jrc.ec.europa.eu/issues/3104#note-8 :

[...] the SpatialDataSetIdentifier element was added to the schema of the INSPIRE Extended Capabilities of the WFS in order to map the required Spatial Data Sets Metadata parameter of the Get Download Service Metadata Response.

A client of the Download Service will then use that information as the value of the Spatial Data Set Identifier parameter of the Get Spatial Data Set request

bgsmase commented 6 years ago

I've always assumed this was unique identifier of the data sets not the service. Not ideal if there is more than one dataset per service but I think assuming that in most cases that there would be one service endpoint per data set (Para 6.5).

PeterParslow commented 6 years ago

TG Requirement 52 "A separate WFS endpoint shall be provided for each INSPIRE dataset thus providing one dataset per GetCapabilities response."

I've never been too clear how this relates to the 'direct access download service'. I assume it is about having a separate endpoint for each 'predefined dataset download', and then another one for the direct access.

I think the final row in Table 19 should be clarified as the Unique Resource Identifier(s) of the dataset(s) available from this endpoint: one each for 'predefined dataset'; perhaps more than one for 'direct access'?

heidivanparys commented 6 years ago

[2017.4 meeting 2018-02-15] The issue was discussed but no final decision/clarification could be made. Everybody was encouraged to have a look at this issue again. @heidivanparys will try to take this issue further and come with an additional explanation and/or proposal.

heidivanparys commented 6 years ago

I think the final row in Table 19 should be clarified as the Unique Resource Identifier(s) of the dataset(s) available from this endpoint: one each for 'predefined dataset'; perhaps more than one for 'direct access'?

That would make this row the Coupled Resource, wouldn't it? According to the regulation:

1.6. Coupled resource If the resource is a spatial data service, this metadata element identifies, where relevant, the target spatial data set(s) of the service through their unique resource identifiers (URI).

heidivanparys commented 6 years ago

I tried to create an overview of section 6.6, added some extra columns to the table and added the questions I have regarding this section. I hope this clarifies the issue. Please have a look and let me know your opinions.

https://docs.google.com/spreadsheets/d/1BRWbh-Hdi53tQ853sQACXGIPoVwobfMZYTab4EkummY/edit?usp=sharing

PeterParslow commented 6 years ago

"That would make this row the Coupled Resource, wouldn't it?" - yes, my confusion.

So, I suggest that the optional identifier of the service is not implemented by inspire_dls:SpatialDataSetIdentifer (as per the red annotation of table 6 above).

"Unique resource identifier" is not required for services in the Metadata Regulation, so not even mentioned for in the Metadata TG. The View Service TG doesn't suggest that the service itself has a Unique resource identifier.

My suggestion now is that the Download Service TG is incorrect at this point, and the last row of Table 19 should be deleted. And further up, in the "Coupled Resource" row, the text "per feature type" is changed to "per dataset" - the equivalent in View Service is layer metadata.

Metadata TG 4.1.2.4 has some detail on Coupled Resource, in the context of a 19139 file, not a WFS response - whether, in practice, the full URLs shown there are needed in a WFS is not something I'm familiar with: what do WFS clients do with wfs:MetadataURL?

michellutz commented 6 years ago

[2017.4 meeting 2018-03-16] The issue is rather complex and requires a separate discussion based on the overview prepared by @heidivanparys. Volunteers to participate in the discussion: @aquaglia @bgsmase @michellutz Veronika Kusova (CZ) Michal Med (CZ). @heidivanparys to organise.

aquaglia commented 6 years ago

Yes, we definitely need to "sit down" and talk about this even though having things written down helps the discussion.

@Heidi Your Excel file is very useful, many thanks.

I agree with changing the label of row 18 from Unique Resource Identifier to Coupled Resource 18 Unique Resource Identifier Coupled Resource M //inspire_dls: ExtendedCapabilities/inspire_dls:SpatialDataSetIdentifier So, we do not have to worry about the case of Ext Caps Scenario 2 (long) where the link to the service metadata is optional.

Instead, I am not convinced of this proposal: Spatial Data Sets Metadata parameter INSPIRE metadata elements M //inspiredls:ExtendedCapabilities/inspire dls:SpatialDataSetIdentifier/@metadataURL In the INSPIRE Geoportal model, attributes are usually reserved for internal purposes, while elements carry the content:

The reason why a DatasetMetadataURL element was not introduced, back at the time, was the opposition from France. It was agreed instead to have the URL to the dataset metadata in the wfs:MetadataURL inside the wfs:FeatureType elements.

So, I would write this, instead:

Spatial Data Sets Metadata parameter INSPIRE metadata elements M wfs:FeatureTypeList/wfs: FeatureType/wfs:MetadataURL

Angelo

On Mon, Mar 26, 2018 at 6:45 PM, Michael Lutz notifications@github.com wrote:

[2017.4 meeting 2018-03-16] The issue is rather complex and requires a separate discussion based on the overview prepared by @heidivanparys https://github.com/heidivanparys. Volunteers to participate in the discussion: @aquaglia https://github.com/aquaglia @bgsmase https://github.com/bgsmase @michellutz https://github.com/michellutz Veronika Kusova (CZ) Michal Med (CZ). @heidivanparys https://github.com/heidivanparys to organise.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/inspire-eu-validation/download-service/issues/81#issuecomment-376232755, or mute the thread https://github.com/notifications/unsubscribe-auth/AAhmKj7M8qt77WJD8lxXai5Td1ybBS3yks5tiRscgaJpZM4R9ams .

michellutz commented 6 years ago

[2017.4 meeting 2018-04-19] @heidivanparys to propose a resolution (TG update?) for the original issue and create additional separate issues for the other discussion points that came up in the discussion.

heidivanparys commented 6 years ago

Proposal for resolution of the original issue, indeed by updating the TG:

billede

There should also be some text in or around table 19:

heidivanparys commented 6 years ago

And further up, in the "Coupled Resource" row, the text "per feature type" is changed to "per dataset" - the equivalent in View Service is layer metadata.

@PeterParslow I think that the "per feature type" is correct, as the full XPath indeed is wfs:FeatureTypeList/wfs:FeatureType/wfs:MetadataURL . Thus you need to indicate the metadata URL for the data set for every feature type served by the WFS. Conceptually, it is the data set that has a metadata URL, and it could have been implemented in a different way, but that proposal was rejected, see earlier comment:

The reason why a DatasetMetadataURL element was not introduced, back at the time, was the opposition from France. It was agreed instead to have the URL to the dataset metadata in the wfs:MetadataURL inside the wfs:FeatureType elements.

And a response to:

what do WFS clients do with wfs:MetadataURL

I did a quick test with QGIS 3.0.0, and it does not seem to read anything from the metadata in the WFS Capabilities, all elements are empty. I don't know what other GIS applications do with the metadata.

billede

bgsmase commented 6 years ago

Agree deletion of "Unique Resource Identifier" row from the table as this is not part of the INSPIRE metadata required for services anyway.

bgsmase commented 6 years ago

The Coupled Resources metadata element comes from the Metadata IR section on metadata for services and the Spatial Data Sets Metadata parameters from the Network Services IR section on download services. For a download service it would seem to me that they are referring to essentially the same thing as the " target spatial data set(s)" of a download service are the available data sets of the services. So I wonder whether using the INSPIRE Extended Capabilities SpatialDataSetIdentifier element to satisfy both is OK.

bgsmase commented 6 years ago

@aquaglia Was the designer of the inspire_dls.xsd aware of the "INSPIRE Geoportal model" of having attributes only for internal purposes? It seems not as they added the @metadataURL attribute to the SpatialDataSetIdentifier element. If the Geoportal model is a real principle that is supposed to be adhered to then perhaps the XSD Schema needs altering to make it a sub-element rather than just ignoring the attribute.

bgsmase commented 6 years ago

I think we are going to have to acknowledge that download services implemented by WFS are going to be different from those implemented by WCS or SOS as they can only have one data set per WFS endpoint (see my comment on #88) whereas a WCS could have different coverages corresponding to different data sets and the SOS technical guidance has proposed using the SOS offering to correspond to data sets. I guess the inspire_dls.xsd SpatialDataSetIdentifier element was created with just WFS in mind. For WCS and SOS it makes more sense to map the coupled resource and spatial data sets metadata to the coverages / SOS offerings sections of the GetCapabilities(Describe Coverage) responses.

aquaglia commented 6 years ago

@bgsmase Actually, there are cases where it might make sense to allow multiple datasets per WFS endpoint. For example, datasets belonging to the same Spatial Data Theme and containing the same Spatial Object Types.

On Tue, May 22, 2018 at 5:41 PM, Marcus Sen notifications@github.com wrote:

I think we are going to have to acknowledge that download services implemented by WFS are going to be different from those implemented by WCS or SOS as they can only have one data set per WFS endpoint (see my comment on #88 https://github.com/inspire-eu-validation/download-service/issues/88) whereas a WCS could have different coverages corresponding to different data sets and the SOS technical guidance has proposed using the SOS offering to correspond to data sets. I guess the inspire_dls.xsd SpatialDataSetIdentifier element was created with just WFS in mind. For WCS and SOS it makes more sense to map the coupled resource and spatial data sets metadata to the coverages / SOS offerings sections of the GetCapabilities(Describe Coverage) responses.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/inspire-eu-validation/download-service/issues/81#issuecomment-391038914, or mute the thread https://github.com/notifications/unsubscribe-auth/AAhmKt_PFrkQO2jexNcAkvGC9Mos9Bd8ks5t1DGPgaJpZM4R9ams .

aquaglia commented 6 years ago

@bgsmase metadataurl is defined correctly as an attribute of the SpatialDataSetIdentifier element. Why do you think it is not the case?

On Tue, May 22, 2018 at 5:25 PM, Marcus Sen notifications@github.com wrote:

@aquaglia https://github.com/aquaglia Was the designer of the inspire_dls.xsd aware of the "INSPIRE Geoportal model" of having attributes only for internal purposes? It seems not as they added the @metadataurl attribute to the SpatialDataSetIdentifier element. If the Geoportal model is a real principle that is supposed to be adhered to then perhaps the XSD Schema needs altering to make it a sub-element rather than just ignoring the attribute.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/inspire-eu-validation/download-service/issues/81#issuecomment-391033120, or mute the thread https://github.com/notifications/unsubscribe-auth/AAhmKkTug-h1LV1O585cbwiBA5F__jPAks5t1C3cgaJpZM4R9ams .

bgsmase commented 6 years ago

@aquaglia On the metadataurl attribute question I was interpreting your comment above -

Instead, I am not convinced of this proposal: Spatial Data Sets Metadata parameter INSPIRE metadata elements M //inspiredls:ExtendedCapabilities/inspire dls:SpatialDataSetIdentifier/@metadataURL In the INSPIRE Geoportal model, attributes are usually reserved for internal purposes, while elements carry the content:

Maybe I've misunderstood what you meant by "internal purposes" but I was interpreting your sentence as meaning that attributes aren't supposed to be carrying actual content that people might want to look at. What is the attribute metadataURL for here?

bgsmase commented 6 years ago

@aquaglia If there are multiple data sets per WFS endpoint, how can a WFS request supply the Spatial Data Set Identifier (as defined in Network Services IR) to select one. The current (WFS, ATOM) download technical guidance states in requirement 52 that a separate endpoint shall be provided fore each INSPIRE dataset. If there's a reasonable way for a WFS to support more than one dataset then the technical guidance needs updating to show this.

(It might be that some pre-defined dataset with an identifier actually had the same data as a collection of other pre-defined sub-data sets but, in the context of this discussion, each WFS endpoint is only capable of fulfilling requests for one identified dataset.)

aquaglia commented 6 years ago

@bgsmase We ought to find a way to stretch the requirement and accomodate for some specific cases like, for example, datasets sharing the same Spatial Object Types. Could you detail which mandatory operations of a Download Service would be affected?

On Wed, May 23, 2018 at 10:17 AM, Marcus Sen notifications@github.com wrote:

@aquaglia https://github.com/aquaglia If there are multiple data sets per WFS endpoint, how can a WFS request supply the Spatial Data Set Identifier (as defined in Network Services IR) to select one. The current (WFS, ATOM) download technical guidance states in requirement 52 that a separate endpoint shall be provided fore each INSPIRE dataset. If there's a reasonable way for a WFS to support more than one dataset then the technical guidance needs updating to show this.

(It might be that some pre-defined dataset with an identifier actually had the same data as a collection of other pre-defined sub-data sets but, in the context of this discussion, each WFS endpoint is only capable of fulfilling requests for one identified dataset.)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/inspire-eu-validation/download-service/issues/81#issuecomment-391261648, or mute the thread https://github.com/notifications/unsubscribe-auth/AAhmKkUwlVTMbTkzSh3gEHeInhQR-0eUks5t1Rs2gaJpZM4R9ams .

aquaglia commented 6 years ago

@bgsmase By "internal purposes" I meant that the attributes do not usually hold content directly required or recommended by the Regulations. (Metadata, Network Services, etc.) They may carry values the INSPIRE Geoportal uses to derive the prescribed content.

More in general, I created the INSPIRE Geoportal model when I started implementing the INSPIRE Geoportal many years ago, as a layer of abstraction to decouple the terminology used in actual implementations (OGC WMS, WFS, SOS, WCS, Atom, ISO 19139) from the one used in the INSPIRE Regulations. So, for example, WMS, WFS, SOS, WCS, Atom are all transformed into a DownloadService xml representation, on which json, jsonp and HTML representations are automatically derived.

In that way, "client" applications (like the Thematic Viewer, the Resource Browser and the DIscovery) can using on the model without worrying about the implementation specification, unless, of course, where it is really needed.

However, the main aim was not for it to be used outside the INSPIRE Geoportal ecosystem.

Angelo

On Wed, May 23, 2018 at 9:57 AM, Marcus Sen notifications@github.com wrote:

@aquaglia https://github.com/aquaglia On the metadataurl attribute question I was interpreting your comment above -

Instead, I am not convinced of this proposal: Spatial Data Sets Metadata parameter INSPIRE metadata elements M //inspiredls:ExtendedCapabilities/inspire dls:SpatialDataSetIdentifier/@metadataurl In the INSPIRE Geoportal model, attributes are usually reserved for internal purposes, while elements carry the content:

Maybe I've misunderstood what you meant by "internal purposes" but I was interpreting your sentence as meaning that attributes aren't supposed to be carrying actual content that people might want to look at. What is the attribute metadataURL for here?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/inspire-eu-validation/download-service/issues/81#issuecomment-391255914, or mute the thread https://github.com/notifications/unsubscribe-auth/AAhmKkfpnVYdAE5G5-877JfM6NGfZaGVks5t1RZZgaJpZM4R9ams .

bgsmase commented 6 years ago

@aquaglia Operations of a Download service that take a Spatial Data Set Identifier parameter according to NS IR:

If we were to call the collection of datasets belonging to the same Spatial Data Theme and containing the same Spatial Object Types a new dataset with its own metadata record then I think we can stretch the interpretation so that a particular WFS endpoint supplied just that new dataset (with separate endpoints for the component datasets). I can't, however, think of a good way with WFS implementations so that an endpoint could also take a Spatial Data Set Identifier parameter to select one of several datasets that it was supplying.

bgsmase commented 6 years ago

@aquaglia OK I think I understand your "internal purposes" now. That mapping of different service types response elements to an intermediate DownloadService xml representation sounds very useful. I didn't know about that.

Were the INSPIRE Extended Capabilities XML Schemas designed as part of this intermediate model though? In Scenario 1 the NS IR requirement to "contain" the INSPIRE metadata elements of the Download Service in the response to a Get Download Service Metadata request is being satisfied not by directly including those elements but by supplying a URL for where the service metadata can be found in the content of the ExtendedCapabilities/MetadataURL element.

What we are discussing here is how to satisfy the NS IR 2.2.4 requirement that the INSPIRE metadata elements of the available Spatial Data Sets shall be provided in the response to a Get Download Service Metadata request. It seems to me that the mechanism presented by the ExtendedCapabilities element is to include identifiers for the Spatial Data Sets in the ExtendedCapabilities/SpatialDataSetIdentifier which can presumably be looked up in a discovery service to get the metadata elements of the data sets. Optionally, in addition, a URL to a metadata record for the dataset can be given in the metadataURL attribute of the SpatialDataSetIdentifer element. These are both indirect ways of getting at the INSPIRE metadata elements that the NS IR says should be included rather than direct ways of including them.

aquaglia commented 6 years ago

@bgsmase

@aquaglia https://github.com/aquaglia OK I think I understand your "internal purposes" now. That mapping of different service types response elements to an intermediate DownloadService xml representation sounds very useful. I didn't know about that.

I can say that I find it useful for my daily tasks here at the JRC.

It might be worth noting that if you open in your browser any INSPIRE Geoportal resource URI, for example the following representation of a WFS 2.0 Download Service, you will get an HTML representation.

http://inspire-geoportal.ec.europa.eu/GeoportalProxyWebServices/resources/INSPIREResource/INSPIRE-80e86358-9378-11e5-a300-a0369f4c5bc0_20180523-081708/services/1/PullResults/141-160/services/12/resourceLocator1/download/services/1/ http://inspire-geoportal.ec.europa.eu/GeoportalProxyWebServices/resources/INSPIREResource/INSPIRE-80e86358-9378-11e5-a300-a0369f4c5bc0_20180523-081708/services/1/PullResults/141-160/services/12/resourceLocator1/download/services/1/

However, if you ask for application/xml, this is what you get, instead:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<ns2:Resource xmlns="http://inspire.ec.europa.eu/schemas/common/1.0" xmlns:ns6="http://inspire.ec.europa.eu/schemas/inspire_ds/1.0" xmlns:ns5=" http://www.w3.org/1999/xlink" xmlns:ns8="http://www.opengis.net/wms" xmlns:ns7="http://www.opengis.net/ows/1.1" xmlns:ns9=" http://www.opengis.net/ogc" xmlns:ns11=" http://inspire.ec.europa.eu/schemas/inspire_vs_ows11/1.0" xmlns:ns10=" http://inspire.ec.europa.eu/schemas/inspire_vs/1.0" xmlns:ns2=" http://inspire.ec.europa.eu/schemas/geoportal/1.0" xmlns:ns4=" http://www.opengis.net/ows" xmlns:ns3=" http://inspire.ec.europa.eu/schemas/inspire_dls/1.0">

<ns2:DownloadServiceResource>

    <ResourceTitle>Harmonised WFS Land-Water Boundary</ResourceTitle>

    <ResourceAbstract>Harmonised WFS Download service. The baseline

defining the boundary between land and sea.

    <ResourceType>service</ResourceType>

    <ResourceLocator originalEncodingReference="gmd:transferOptions"

remoteIdentifier="Land Water Boundary">

        <URL>

https://msdi.data.gov.mt/deegree/services/hy_LandWaterBoundary?service=WFS&amp;request=GetCapabilities 

        <LinkDescription>Land Water Boundary Harmonised INSPIRE WFS

Download service

        <InitialResponseMilliseconds>40</InitialResponseMilliseconds>

        <BytesTransferred>25274</BytesTransferred>

        <TimeElapsed>1</TimeElapsed>

        <AverageBytesPerSecond>2.5274E7</AverageBytesPerSecond>

    </ResourceLocator>

    <MandatoryKeyword>

        <KeywordValue>infoFeatureAccessService</KeywordValue>

    </MandatoryKeyword>

    <Keyword>

        <KeywordValue>WFS Service</KeywordValue>

    </Keyword>

    <GeographicBoundingBox>

        <East>14.58</East>

        <West>14.18</West>

        <North>36.08</North>

        <South>35.81</South>

    </GeographicBoundingBox>

    <TemporalReference>

        <DateOfCreation>2016-05-03</DateOfCreation>

    </TemporalReference>

    <SpatialResolution abstract="Harmonised WFS Download service. The

baseline defining the boundary between land and sea."/>

...

Were the INSPIRE Extended Capabilities XML Schemas designed as part of this intermediate model though? In Scenario 1 the NS IR requirement to "contain" the INSPIRE metadata elements of the Download Service in the response to a Get Download Service Metadata request is being satisfied not by directly including those elements but by supplying a URL for where the service metadata can be found in the content of the ExtendedCapabilities/MetadataURL element.

That came after.

When the team in charge of writing the TGs for View Services (they came before the Download Services) arrived to the conclusion that INSPIRE Extended Capabilities in OGC services were needed, I proposed to re-use the XML schemas I had already written for the INSPIRE Geoportal Operational Pilot.

After all, the fact of having XML element names matching those defined in the Metadata Regulation must have looked somewhat appealing.

Referencing remote XML fragment or entire documents is a very well established practice in the HTTP/XML world (e.g. xlink:href). You just follow the specified rules, i.e. resolve the given URL and read the response content stream. The agreed specification is that the Download Service Metadata Response is the document you obtain after resolving the links.

The composite document is compliant with the Metadata and Network Service Regulations.

At the time, the main reason why some Member States pushed for the Scenario 1/ Scenario 2 optionality was that even getting a stable URL to metadata documents in the National Discovery Services was still a problem for quite a few of them.

So, even though the INSPIRE Extended Capabilities XML Schemas do rely on the INSPIRE Geoportal base types, I had to “give in” or compromise, when we had to agree on the element structure and naming inside the INSPIRE Extended Capabilities

What we are discussing here is how to satisfy the NS IR 2.2.4 requirement that the INSPIRE metadata elements of the available Spatial Data Sets shall be provided in the response to a Get Download Service Metadata request. It seems to me that the mechanism presented by the ExtendedCapabilities element is to include identifiers for the Spatial Data Sets in the ExtendedCapabilities/SpatialDataSetIdentifier which can presumably be looked up in a discovery service to get the metadata elements of the data sets. Optionally, in addition, a URL to a metadata record for the dataset can be given in the metadataURL attribute of the SpatialDataSetIdentifer element. These are both indirect ways of getting at the INSPIRE metadata elements that the NS IR says should be included rather than direct ways of including them.

I was in the working group for drafting the Download Service TGs and I actually proposed to have the Spatial Data Set metadata URL in the Extended Capabilities. France opposed that very strongly saying it was redundant because already present in the coupled resources of the service metadata. However:

Clemens Portele managed to have everybody agree on having at least the Spatial Data Set identifiers in the Extended Capabilities.

Best regards, Angelo

On Thu, May 24, 2018 at 10:43 AM, Marcus Sen notifications@github.com wrote:

@aquaglia https://github.com/aquaglia OK I think I understand your "internal purposes" now. That mapping of different service types response elements to an intermediate DownloadService xml representation sounds very useful. I didn't know about that.

Were the INSPIRE Extended Capabilities XML Schemas designed as part of this intermediate model though? In Scenario 1 the NS IR requirement to "contain" the INSPIRE metadata elements of the Download Service in the response to a Get Download Service Metadata request is being satisfied not by directly including those elements but by supplying a URL for where the service metadata can be found in the content of the ExtendedCapabilities/MetadataURL element.

What we are discussing here is how to satisfy the NS IR 2.2.4 requirement that the INSPIRE metadata elements of the available Spatial Data Sets shall be provided in the response to a Get Download Service Metadata request. It seems to me that the mechanism presented by the ExtendedCapabilities element is to include identifiers for the Spatial Data Sets in the ExtendedCapabilities/SpatialDataSetIdentifier which can presumably be looked up in a discovery service to get the metadata elements of the data sets. Optionally, in addition, a URL to a metadata record for the dataset can be given in the metadataURL attribute of the SpatialDataSetIdentifer element. These are both indirect ways of getting at the INSPIRE metadata elements that the NS IR says should be included rather than direct ways of including them.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/inspire-eu-validation/download-service/issues/81#issuecomment-391637072, or mute the thread https://github.com/notifications/unsubscribe-auth/AAhmKs6JkIGFjYU1tJrdRc7h5OaULxg1ks5t1nK7gaJpZM4R9ams .

thijsbrentjens commented 6 years ago

I'm working on the TG changes now, the section of the mapping of the spatial dataset identifier. In the TG Metadata (of march 2017) I read in the Unique Resource Identifier section:

"The unique resource identifier is needed to provide a queryable information when following data-service-coupling (see also 4.1.2.4). Therefore it is necessary to have the identifier itself together with the namespace in element code. The use of RS_Identifier (with a separate element codeSpace) is not suitable here"

So the RS_Identifier shouldn't be used any longer (according to the new Metadata guidelines) (edit: for the dataset identifier). Should we change the TG download services for this? So remove the RS_Identifier mapping in the section 4.1.3?

And if so, I think it would make sense to remove the element inspire_dls:SpatialDataSetIdentifier/inspire_common:Namespace from the ExtendedCapabilities. Or at least recommend not to use it, but use namespace+identifier in the element inspire_dls:SpatialDataSetIdentifier/inspire_common:Code

aquaglia commented 6 years ago

That strong statement is taken from section C.2.5 Unique resource identifier

However, in the same document that translates to a simple recommendation:

TG Recommendation 1.1: metadata/2.0/rec/datasets-and-series/use_md_identifierIt is strongly recommended to use the MD_Identifier instead of the the RS_Identifier type and to encode the complete URI in the code element.

So, no, I would not remove the inspire_common:Namespace from the ExtendedCapabilities which is, in any case, an optional element.

On Thu, May 31, 2018 at 2:37 PM, Thijs Brentjens notifications@github.com wrote:

I'm working on the TG changes now, the section of the mapping of the spatial dataset identifier. In the TG Metadata (of march 2017) I read in the Unique Resource Identifier section:

"The unique resource identifier is needed to provide a queryable information when following data-service-coupling (see also 4.1.2.4). Therefore it is necessary to have the identifier itself together with the namespace in element code. The use of RS_Identifier (with a separate element codeSpace) is not suitable here"

So the RS_Identifier shouldn't be used any longer (according to the new Metadata guidelines). Should we change the TG download services for this? So remove the RS_Identifier mapping in the section 4.1.3?

And if so, I think it would make sense to remove the element inspire_dls: SpatialDataSetIdentifier/inspire_common:Namespace from the ExtendedCapabilities. Or at least recommend not to use it, but use namespace+identifier in the element inspire_dls:SpatialDataSetIdentifier/ inspire_common:Code

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/inspire-eu-validation/download-service/issues/81#issuecomment-393516078, or mute the thread https://github.com/notifications/unsubscribe-auth/AAhmKjhoERESiNUDC6zKOXLaouyl3WQuks5t3-P4gaJpZM4R9ams .

thijsbrentjens commented 6 years ago

That's a very clear answer, thanks! We need the RS_Identifier and (optional) separate namespace element then.