MIWP-8: Metadata - Task #2221 MIWP-8 (M) Coupled resource

Transcription

1 MIWP-8: Metadata - Task #2221 MIWP-8 (M) Coupled resource 17 Sep :02 am - Michael Östling Status: Closed Start date: 17 Sep 2014 Priority: Normal Due date: Assignee: % Done: 0% Category: Estimated time: 0.00 hour Proposed change or action: Description This section has now been locked for editing and a draft version have been moved into the draft document. See page: Further discussions and comments should be done on the draft WIKI: The data-service-coupling part of the TGs need clarification urgently. The suggested solution is inconsistent and examples are confusing, making use of XML object IDs without any hints/explanation. Suggesting that both, URI or URLs to DataIdentification objects are allowed create a significant confusion for implementers and no justification is given. The task of this group is to provide more context for the purpose of the coupled resource and to provide justification for the coupled resource as well as an outline of the related use cases (as in other parts of the document). History #1-04 Dec :01 am - Michael Östling - Description updated #2-04 Dec :34 am - Michael Östling The version 1.3 published of the Technical guidelines contains updated examples (in section 2.2.6) of this element. ( Version 1.2 published uses the reference by id as only example eg. srv:operateson xlink:href=" But I'm still not clear on the full definition which is similar in both versions A unique resource identifier or locator (URL) of the MD_DataIdentification object. When inspecting metadata in Inspire Geoportal it seems many records is just a plain GetRecordById to a CSW-catalogue services that returns a MD_Metadata object. The example URL in version 1.3 of TG Metadata is: CSW&VERSION=2.0.2&REQUEST=GetRecordById&ID=f9ee6623-cf4c-11e a97ab &OUTPUTSCHEMA= &ELEMENTSETNAME=full#lakes 11 Dec /15

2 Is the intention here that the #lakes in the end of URL is an anchor to a MD_DataIdentification object ID="Lakes" within the metadatarecord with ID=f9ee6623-cf4c-11e a97ab? I think we also would need an working example how metadata could be registred using only "A unique resource identifier " If our identifiers where persistant URLs then this should be easier. But an operates on that uses "A unique resource identifier" that is using as identifier. Is that pointing to the resource itself and/or the metadata record? #3-04 Dec :44 pm - Pawel Soczewski I propose two choices: 1) Resource identifier which is "URI dereferencing" according to the Linked Date idea. The Url should be resolvable as a metadata record. Below example of German SDI registry: Resource Id { namespace prefix } {namespace} { localid} Metadata record 2) Link to metadata record, request of GetRecordById or direct link to metadata file #4-04 Dec :58 pm - Geraldine Nolf - File Example_Flanders_OperatesOn.xml added #5-18 Dec :31 am - Martin Seiler I'd like to stress the importance of this issue once again. IMHO this is not only a metadata issues, but critical for the overall architecutre of INSPIRE, as this is the glue it relies on! So its important that this is carefully reviewed and improved. #6-18 Dec :40 am - Martin Seiler Regarding the proposals in the wiki: Regardless of whether encoded in the uuidref or xlink attribut, the identenifier to put here has to be the Uniquie Ressource Identifier and not the fileidentifier of the metadata record itself! 11 Dec /15

3 While I am in favor of using the xlink here, this means essentially that the Unique Ressource Identifier (as provided in the metadata set describing the dataset itself) has to be a resovable URL. Putting GetRecordById requests here is possible, but then implies that the Ressource Identifier is a GetRecordById request itself. This has disadvantages (e.g. long identifiers, CSW URL might change over time,...). The identifier could also (and additionally) be placed in the uuidref attribute (not the fileidentifier). The ISO schema allows any string here. It does not have to be a uuid. #7-18 Dec :44 am - Martin Seiler Regarding the domain ("A unique resource identifier or locator (URL) of the MD_DataIdentification object") I propose to change this to "The unique resource identifier as provided in the metadata record describing the dataset (IR Part B 1.5)" #8-18 Dec :05 pm - Michael Östling It would be great if we could show a usecase that shows how the uuidref= Wouldn't we need the uuidref to be a URI that is possible to dereference as Pawel mentions above or that the uuidref is a persistant URL. An other minor comment, when using the HREF to point out a metadatarecord we will normally get a MD_Metadata object in return if we have put files on a WAF. But in the case of a GetRecordByIDRequest the MD_Metadata will be wrapped in a GetRecordByIDResponse obejct. So the datatypes for the two will differ. #9-19 Dec :46 am - Martin Seiler Michael Östling schrieb: It would be great if we could show a usecase that shows how the uuidref= It might be a good idea to add use cases we target here (and/or explainations) as an introduction to the section / as currently done e.g. for section 2.8 or 2.9. #10-19 Dec :11 am - Pawel Soczewski I agree with Martin. Value of OperatesOn element should point metadata of relevant dataset. Ideally it would be dataset identyfier as a resovable URL but by this time it should allow an alternative value - GetRecordsById request. According to the Martin's proposal, change the domain of Coupled Resource to "The unique resource identifier as provided in the metadata record describing the dataset (IR Part B 1.5)" and at "Comments" to add "In the case where the unique resource identifier is not a resovable URL should be provide a reference to the metadata record as link to GetRecordsById request". #11-19 Dec :19 pm - Martin Seiler Pawel Soczewski schrieb: 11 Dec /15

4 I agree with Martin. Value of OperatesOn element should point metadata of relevant dataset. Ideally it would be dataset identyfier as a resovable URL but by this time it should allow an alternative value - GetRecordsById request. According to the Martin's proposal, change the domain of Coupled Resource to "The unique resource identifier as provided in the metadata record describing the dataset (IR Part B 1.5)" and at "Comments" to add "In the case where the unique resource identifier is not a resovable URL should be provide a reference to the metadata record as link to GetRecordsById request". This would not be inline with the current CSW ISO AP, this would have to be stated and explained as well so avoid confusion. #12-07 Jan :18 am - Ine de Visser I have some of questions on above discussions; Can you clearify what not inline is with current CSW ISO AP? is it inline with the new ISO 19115? If we need to use the GetRecordsById request, should that be a request to a record in the same CSW or another CSW? this is a problem by harvested metadata? I suggest we do one stap back, to get the things clear; 1. What are de definitions in the relevant standards, CSW ISO AP, ISO 19115,... and the IR, Where should the resource locator point to based on the defenitions in the relevant standards, the dataset or the metadata of that dataset. 3. How can we link to that? XLink,UUIDref, What is the locator, an URI(resolvable URL) or an UUID, is it applicable, #13-08 Jan :23 am - Michael Östling I think we have some problems resolving the requirements of both ISO1915 and CSW ISO AP. I have tried to inspect what's written and understand the consequences. When studying the CSW ISO API I can see on page 37 A service that is associated with specific datasets or datasetcollections. Service metadata shall describe both the service and the geographic dataset, the latter being defined in accordance with ISO CSW ISO AP mandates that metadata for the service (eg a view-service) should contain metadata for both the service and the dataset(s) (having one dataidentification object for each dataset). By this is then clearer to understand why TG Metadata includes the definition: A unique resource identifier or locator (URL) of the MD_DataIdentification object As I see it this is not inline with Inspire TG that demands us to have a separate metadata records for each dataset. A dataset can also exist in mutiple services so including the dataset metadata with the service-metadata is not possible as i see it. I suggest we go for the solution that is implemented in various membersstates and that is included on WIKI and that also are included as a complete XML-example using both uuidref and xlink:href. 11 Dec /15

5 #14-08 Jan :32 am - Martin Seiler Ine de Visser schrieb: Can you clearify what not inline is with current CSW ISO AP? The CSW ISO AP demands that operateson points to the Unique Ressorce Identifier. A GetRecordById however point to the Id of the metadata record itself (aka fileidentifier). I suggest we do one stap back, to get the things clear; What are de definitions in the relevant standards, CSW ISO AP, ISO 19115,... and the IR,... Where should the resource locator point to based on the defenitions in the relevant standards, the dataset or the metadata of that dataset. How can we link to that? XLink,UUIDref,... What is the locator, an URI(resolvable URL) or an UUID, is it applicable, Good idea. Should be done in the wiki. #15-08 Jan :44 pm - Pawel Soczewski I've studied annex F of CSW ISO AP - Coupling services with datsets. In it we can see: It is recommended to support the linkage between services and data instances defining equality of: MD_DataIdentification.citation.CI_Citation.identifier.MD_Identifier.code for data metadata and one of 1) SV_ServiceIdentification.operatesOn@uuidref or 2) SV_ServiceIdentification.operatesOn.MD_DataIdentification.citation.CI_Citation.identifier.MD_Identifier.code for service metadata. If the values of those identifiers match, the linkage between the service and the data metadata is properly described. I understand, that #1 is for byreference and #2 is for inline. It is not clear to me whether uuidref = MD_DataIdentification@uuid (or gmd:md_metadata@uuid) or uuidref = MD_DataIdentification.citation.CI_Citation.identifier.MD_Identifi er.code? If this is the second case, then it demands the construction of Unique Ressorce Identifier (?). On page 49 of CSW ISO AP there is definition of queryable property OperatesOn: OperatesOn Identifier of a dataset Identifier MD_Metadata.identificationInfo.SV tightly coupled with the _Ser service instance. viceidentification.operateson.md_ DataI 11 Dec /15

6 dentification.citation.ci_citation.id entifi er I'll test how implement this queryable property CSW service (terracatalog). #16-08 Jan :58 pm - Martin Seiler Pawel Soczewski schrieb: I've studied annex F of CSW ISO AP - Coupling services with datsets. Thanks for digging this out. Just want to point out that the Annex is labeled 'informative'. I.e. this should be seen as a 'a possible way to implement' or recommendation rather than a requirement by the standard. In it we can see: It is recommended to support the linkage between services and data instances defining equality of: MD_DataIdentification.citation.CI_Citation.identifier.MD_Identifier.code for data metadata and one of 1) SV_ServiceIdentification.operatesOn@uuidref or 2) SV_ServiceIdentification.operatesOn.MD_DataIdentification.citation.CI_Citation.identifier.MD_Identifier.code for service metadata. If the values of those identifiers match, the linkage between the service and the data metadata is properly described. I understand, that #1 is for byreference and #2 is for inline. It is not clear to me whether uuidref = MD_DataIdentification@uuid (or gmd:md_metadata@uuid) or uuidref = MD_DataIdentification.citation.CI_Citation.identifier.MD_Identifi er.code? If this is the second case, then it demands the construction of Unique Ressorce Identifier (?). On page 49 of CSW ISO AP there is definition of queryable property OperatesOn: OperatesOn Identifier of a dataset tightly coupled with the service instance. Identifier MD_Metadata.identificationInfo.SV_Ser viceidentification.operateson.md_datai dentification.citation.ci_citation.identifi er I'll test how implement this queryable property CSW service (terracatalog). Three more considerations on this: 1. As far as I know the second version is not supported by the ISO schema. Which would be a problem as then we could not use those for validation anymore 2. uuidref in the related ISO has the value-domain 'string'. I.e. this can be a uuid, but also a URL (or any other text...) 3. As this annex is informative we could still agree to use xlink here without violating this AP. #17-08 Jan :17 pm - Pawel Soczewski Martin Seiler napisa?(a): Three more considerations on this: 1. As far as I know the second version is not supported by the ISO schema. Which would be a problem as then we could not use those for validation anymore I just checked, it is supported by the ISO schema but as written by Michael, inline is not compatible with INSPIRE TG. #18-08 Jan :20 pm - Martin Seiler Pawel Soczewski schrieb: Martin Seiler napisa?(a): Three more considerations on this: 1. As far as I know the second version is not supported by the ISO schema. Which would be a problem as then we could not use those for validation anymore I just checked, it is supported by the ISO schema but as written by Michael, inline is not compatible with INSPIRE TG. Ah, good. Could you point out the section of the schema-file? #19-08 Jan :29 pm - Pawel Soczewski 11 Dec /15

7 type="gmd:md_dataidentification_propertytype" minoccurs="0" maxoccurs="unbounded"/> #20-08 Jan :46 pm - Pawel Soczewski Pawel Soczewski napisa?(a): I'll test how implement this queryable property CSW service (terracatalog). I've tested terracatalog. The queryable proporty operateson is implemented as MD_Metadata.identificationInfo.SV_Ser viceidentification@xlink:href #21-09 Jan :46 pm - Martin Seiler Pawel Soczewski schrieb: Pawel Soczewski napisa?(a): I'll test how implement this queryable property CSW service (terracatalog). I've tested terracatalog. The queryable proporty operateson is implemented as MD_Metadata.identificationInfo.SV_Ser viceidentification@xlink:href Thanks for checking. It seems to in GeoNetwork (v 2.8) #22-12 Jan :39 am - Ine de Visser In my opinion it should be conform the standards, the implementation of those standards should not be leading. #23-16 Jan :48 pm - Kristian Senkler - File Investigations on coupled resources.docx added Hi all, I have written some sections to summarize the problems using different approaches for coupling reosurces. The attached documented tries to identifier the shortcomings of each approach and, hopefully, provides some insight into possible conclusions. It's far from perfect, so feel free to comment anything that is unclear. P.S.: If this is not the right place in the Wiki to put such documents, please move it to a more suitable location 11 Dec /15

8 #24-22 Jan :03 am - Ine de Visser Thanx for this investigation. I have an other option; use option 1 uuidref in combination with option 2 xlink:href Pros; - in line with the OGC CSW AP ISO spec (uuidref) - best practice at the moment (xlink:href) - The reference to the dataset is directly given (uuidref) - self-contained (xlink:href) Cons: - Not fully compliant with ISO semantics - Bound to conventions regarding stable URLs #25-03 Feb :22 pm - Martin Seiler From the wiki: When checking in CSW ISO APi how this value should be implemented There are two possibilities where either the dataset is pointed out by reference Note: This is a recommendation from the informative annex F. So providing the URI only should be sufficient. It should just be mandatory that the URI provided is dereferenceable. Having dereferenceable URIs here would satisfy both use cases, e.g. with a redirect to the metadata record. #26-03 Feb :26 pm - Martin Seiler From the wiki: What is the justification for xlink:href=[getrecordbyid url]? A reference to a metadata record should be sufficient. This could be a GetRecordById or a static XML on a web server or a redirect to either of them. #27-03 Feb :29 pm - Martin Seiler From the wiki: Use Case A: You are a user and finds metadata for a service (WMS) You then want to evaluate the service 11 Dec /15

9 and read metadata for the datasets that this services works on. This use case can be realized with the same approach as in UC B: Extract the URIs from the operateson elements and query the CSW for respective data sets. #28-03 Feb :09 pm - Michael Östling - File MD_IR_and_ISO_ _Copy_for_editing_in_MIWP8_2.2.6Only.doc added I have updated a DRAFT document after our last meeting and reading the document by Kristian S (excellent description of the case). Just so we can push our discussions forward. There are as it looks like no perfect solution. We have to do the best also handling the situation for all existing metadata (that is already now using and have been adviced to use xlink:href). ' I have tried to modify the text according to this. In the attached doc only chapter Coupled resource is modified. I have modified the text to only have uuidref as mandatory element and giving recommendation to use xlink:href to point out the metadatarecord. It is correct as you mention above Martin that if the resource identifier is dereferenceable then we should not not need the xlink:href. But since we are not there (yet). I think its good to also recommend the xlink:href. But we see here the importance of the task of working with persistant and dereferenceable identifiers #29-03 Feb :20 pm - Michael Östling Martin, Can you elaborate on this comment? I'm not sure I follow you here. "Note: This is a recommendation from the informative annex F. So providing the URI only should be sufficient. It should just be mandatory that the URI provided is dereferenceable. Having dereferenceable URIs here would satisfy both use cases, e.g. with a redirect to the metadata record. " Do you mean that a dereferenceable URI would be enough and that no uuidref would be needed? Do you mean a URI where the resource identifier is included as an argument. I think we must include the resource identifier in the OperatesOn some how, since IR specifies the need for actually specifying the resource identifier. Can you give an example of how you would write in case you could handle all your identifiers without limitations. How would an dereferenceable URI look line in OperatesOn #30-05 Feb :44 am - Marc Leobet Dear colleagues, after investigation, I bring back to you two answers to the questions asked by Michaël : 11 Dec /15

10 > Are there a queryable in their CSW for OperatesOn and ResourceIdentifier? Yes, as indicated in the getcapabilities : > What are they mapped to? OperatesOn does not point toward xlinkhref but uuidref. We have the project to add this functionnality in our future CSW. ResourceIdentifier points toward the resource ID of the dataset (MD_Identifier ou RS_Identifier). #31-05 Feb :28 am - James Reid - File MD_IR_and_ISO_ _Copy_for_editing_in_MIWP8_2.2.6Only-UK-edit-to-repharse-better.doc added I have modified slightly Micahels draft text for to better phrase things in English. I have left the existing logic the same. #32-05 Feb :46 pm - Michael Östling Martin Seiler wrote: From the wiki: What is the justification for xlink:href=[getrecordbyid url]? A reference to a metadata record should be sufficient. This could be a GetRecordById or a static XML on a web server or a redirect to either of them. Yes correct, any URL to a XML could be ok. Have though to discuss what class the URL shoudl point to: - In case we call a GetRecordID we get a GetREcordBYID-response with MD_Metadata embedded - In case we call a GetRecords we get a GetRecords response? with MD_Metadata embedded - In case point to a xml-file we would point directly to a MD_Metadata class #33-05 Feb :06 pm - Michael Östling Pawel Soczewski wrote: Pawel Soczewski napisa?(a): I'll test how implement this queryable property CSW service (terracatalog). I've tested terracatalog. The queryable proporty operateson is implemented as MD_Metadata.identificationInfo.SV_Ser viceidentification@xlink:href I guess you mean MD_Metadata.identificationInfo.SV_ServiceIdentification.OperatesOn@xlink:href #34-05 Feb :07 pm - Kristian Senkler I'm still not convinced that using the GetRecordById approach is suitable in terms of the requirements of the IR. The IR clearly states to reference related documents using unique resource identifier(s). GetRecordById uses the identifier of the metadata document, which is a totally different thing. I think it is sufficient to use uuidref (even though it is not fully ISO compliant) or, as an alternative, use xlink@href in combination with a GetRecords request that utilizes the resource identifier. Hence, the latter approach calls for setting the HTTP GET operation for a GetRecords as mandatory within INSPIRE. The CSW spec specifies HTTP GET being optional only. #35-05 Feb :12 pm - Michael Östling 11 Dec /15

11 Som background info on CSW queryables: In terracatalog OperatesON is mapped (but can be configured to use uuidref instead, or even both uuidref and ) In Geonetwork 2.8 and 2.10 it mapped (but can be configured to use both uuidref and xlink:href) In Geonetwork 3.0 it mapped against Do we have any other catalogues we can get info on? ESRI Geoportal? DEGREE? This is just to get some info on current practices. #36-05 Feb :17 pm - Kristian Senkler One word on terra.catalag: operateson it is mapped to xlink@href by default, but you can configure it to use uuidref instead, or even both uuidref and xlink@href. #37-05 Feb :24 pm - Michael Östling Kristian Senkler wrote: I'm still not convinced that using the GetRecordById approach is suitable in terms of the requirements of the IR. The IR clearly states to reference related documents using unique resource identifier(s). GetRecordById uses the identifier of the metadata document, which is a totally different thing. I think it is sufficient to use uuidref (even though it is not fully ISO compliant) or, as an alternative, use xlink@href in combination with a GetRecords request that utilizes the resource identifier. Hence, the latter approach calls for setting the HTTP GET operation for a GetRecords as mandatory within INSPIRE. The CSW spec specifies HTTP GET being optional only. Ok, If we can change TG for discovery service then it should be fine for me. But if we use uuidref then this identifier has to be an URL or anyhow an URI that be dereferenced, right? Otherwise the system can not find the resource. So we should end up with uuidref as required and xlink:href to a getrecords request as recommended or should we either of them as requirement? We still have an issue to handle with getrecordsbyid. That is the currently recommended solution in TG and that is I think what most countries have implemented. To remove an existing recommendation needs some dicussions in MIG in think. #38-05 Feb :42 pm - Martin Seiler Kristian Senkler schrieb: I'm still not convinced that using the GetRecordById approach is suitable in terms of the requirements of the IR. The IR clearly states to reference related documents using unique resource identifier(s). GetRecordById uses the identifier of the metadata document, which is a totally different thing. I think it is sufficient to use uuidref (even though it is not fully ISO compliant) or, as an alternative, use xlink@href in combination with a GetRecords request that utilizes the resource identifier. Hence, the latter approach calls for setting the HTTP GET operation for a GetRecords as mandatory within INSPIRE. The CSW spec specifies HTTP GET being optional only. I agree. This would only be in line with the IR if the Unique Resource Identifier would be the full GetRecordById request itself. #39-05 Feb :49 pm - Martin Seiler Michael Östling schrieb: 11 Dec /15

12 But if we use uuidref then this identifier has to be an URL or anyhow an URI that be dereferenced, right? Otherwise the system can not find the resource. So we should end up with uuidref as required and xlink:href to a getrecords request as recommended or should we either of them as requirement? We still have an issue to handle with getrecordsbyid. That is the currently recommended solution in TG and that is I think what most countries have implemented. To remove an existing recommendation needs some dicussions in MIG in think. Well, the the described use cases can be accomplished simply with a second CSW request searching for datasets / services with Unique Resource Identifiers. While it is useful and desirebale that the metadata sets can be directly accessed (through dereferenceable identifiers) I still don't see where the solid requirement in the context of INSPIRE is comming from. #40-16 Feb :34 pm - Pawel Soczewski Hi all, over the last few weeks, I was very busy but now I have carefully read the current discussion and I have the following conclusions. From Kristian's document: 1. Semantically, it is not correct to use the that way. As per ISO 19118, A.5.5.2, [ ] The uuidref attribute shall be used to refer to an object within the universe of an application domain. [ ]. By example, this means that an elements defined as: can be referenced elsewhere by a new element like this: Hence, the approach given above links a uuidref attribute with the element value of an identifier class, which is not correct. In my opinion there isn't inconsistencies in "by reference" approach (SV_ServiceIdentification.operatesOn@uuidref) from annex F of CSW AP ISO. According with ISO encoding of reference to dataset metadata record should be following: refer to PL.ZIPGUS.312.SU According with ISO if you want to refer to objects that are located in other datasets use attribute "uriref" (URI). In ISO the implementation of the above issues is slightly modified from that in ISO in order to be more consistent with ISO The gco:objectreference attributegroup contains a reference to the xlink:simplelink attributegroup, plus the definition of an XML attribute named uuidref of type xs:string. According ISO the xlink:href attribute is used to build reference to feature. Using the xlink:href to encoding references is the best practice at the moment. #41-17 Feb :52 am - Pawel Soczewski My proposal is only to use xlink:href approach using a unique resource identifier. The unique resource identifier should be encoded URI (URL). Dereferenceable URI is desirable but not required. Pros: 11 Dec /15

13 in line with the OGC CSW AP ISO spec (byreference) compliant with ISO and ISO semantic (using xlink:href to refer to objects) compliant with INSPIRE IR (unique resource identifier) best practice to encoding references Cons: Bound to conventions regarding stable URLs not in line with best practice at the moment (GetRecordById) not all unique resource identifiers are compilant with URI(URL) schema #42-04 Mar :10 pm - Geraldine Nolf - File Overview_DS_DSS_SRV_ObjCat.PNG added For your information: In the branch of our GeoNetwork node (Flanders - Belgium) we use too both uuidref (to the resource identifier of the dataset) and xlink:href (to the metadata file, via the CSW Request GetRecordByID and the metadata fileidentifier). Example: - service itself: - operateson: f.e. uuidref="0574c388-20a4-4e1a-9e8d-fca40001c917"xlink:href=" org/2005/gmd&elementSetName=full&id=8ac7a847-c322-4a60-ac77-42c3064d1392"/>uuidref= "0574c388-20a4-4e1a-9e8d-fca40001c917"xlink:href=" org/2005/gmd&elementSetName=full&id=8ac7a847-c322-4a60-ac77-42c3064d1392"/> Once I had made a slide in PowerPoint to help our data providers. I'll upload it hereby. Geraldine #43-05 Mar :06 pm - Pawel Soczewski I've read carefully the mail from Michel and I thought about the issue again. My proposal from post#41 covers the path d. In my opinion it'll be ideally, unique resource identifier should be dereferenceable URL (in HTTP schema). However, if we would have imposed such a requirement would fall into this scenario d. There will not always be affect only the metadata eg. in Poland resource id (not compliant with URL scheme) is a part of external object id and format and structure of identifier are regulated by law. If they change resource id, should change object id and this is inconsistent with the article 9 of CR "The external object identifier for the unique identification of spatial objects shall not be changed during the life-cycle of a spatial object." That's why most appropriate proposal from post #21 will be (path b) with two options: option 1 uuidref - unique resource id xlink:href - GetRecordById option 2 if resource id is dereferenceable URL xlink:href - unique resource id 11 Dec /15

14 Using the GetRecords operation may cause additional costs for the MS eg. in Poland is popular terracatalog and it don't support this operation by GET binding. #44-23 Mar :19 pm - Martin Seiler Pawel Soczewski schrieb: I've read carefully the mail from Michel and I thought about the issue again. My proposal from post#41 covers the path d. In my opinion it'll be ideally, unique resource identifier should be dereferenceable URL (in HTTP schema). However, if we would have imposed such a requirement would fall into this scenario d. There will not always be affect only the metadata eg. in Poland resource id (not compliant with URL scheme) is a part of external object id and format and structure of identifier are regulated by law. If they change resource id, should change object id and this is inconsistent with the article 9 of CR "The external object identifier for the unique identification of spatial objects shall not be changed during the life-cycle of a spatial object." That's why most appropriate proposal from post #21 will be (path b) with two options: option 1 uuidref - unique resource id xlink:href - GetRecordById option 2 if resource id is dereferenceable URL xlink:href - unique resource id Using the GetRecords operation may cause additional costs for the MS eg. in Poland is popular terracatalog and it don't support this operation by GET binding. Which are you reffering please make sure to keep the technical discussion on issues here. Its not traceable otherwise... #45-23 Mar :27 pm - Martin Seiler I still don't see consensus here. In the suggested update acutally both, uuidref and xlink, point to the fileidentifier. However, we need a reference to the Resource Identifier here. #46-23 Mar :58 pm - Pawel Soczewski Martin Seiler napisa?(a): Pawel Soczewski schrieb: I've read carefully the mail from Michel and I thought about the issue again. My proposal from post#41 covers the path d. In my opinion it'll be ideally, unique resource identifier should be dereferenceable URL (in HTTP schema). However, if we would have imposed such a requirement would fall into this scenario d. There will not always be affect only the metadata eg. in Poland resource id (not compliant with URL scheme) is a part of external object id and format and structure of identifier are regulated by law. If they change resource id, should change object id and this is inconsistent with the article 9 of CR "The external object identifier for the unique identification of spatial objects shall not be changed during the life-cycle of a spatial object." That's why most appropriate proposal from post #21 will be (path b) with two options: option 1 uuidref - unique resource id xlink:href - GetRecordById option 2 if resource id is dereferenceable URL xlink:href - unique resource id Using the GetRecords operation may cause additional costs for the MS eg. in Poland is popular terracatalog and it don't support this operation by GET binding. Which are you reffering please make sure to keep the technical discussion on issues here. Its not traceable otherwise... It was from to all member of group. #47-24 Mar :47 am - Martin Seiler Pawel Soczewski schrieb: It was from to all member of group. Thanks! #48-24 Mar :00 am - Martin Seiler The proposed solution (uuidref=fileidentifier is mandatory, xlink=getrecordbyid optional) is - in my opinion - not fullfilling the requirements of the Metadata IR (1205/2008) as they (both) reference the fileidentifier of the metadata record itself and not the resource. B 1.6 demands a URI here: 11 Dec /15

15 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). And it goes on with even repeating the requirements of the (basic) URI design from B 1.5: The value domain of this metadata element is a mandatory character string code, generally assigned by the data owner, and a character string namespace uniquely identifying the context of the identifier code (for example, the data owner). In the MIWP-8 calls we learned that the OGC ISO AP is not in all parts very well written or even inconsistent. However, while we should follow the OGC documents as closely as possible here, its is essential that we come up with TG requirements/recommendations that are fullfilling the (legally binding) IRs. And actually INSPIREs' requirements go beyond OGC and hence the OGC paper weren't adapted but taken as a starting point in drafting the TGs (just think of the extended capabilities of the services). So again I call for a solution that references the resource URI (B 1.5), encoded in MD_Identifier here. #49-28 Mar :59 am - Michael Östling - Description updated - Status changed from Submitted to Closed Files Example_Flanders_OperatesOn.xml 35.8 KB 04 Dec 2014 Geraldine Nolf Investigations on coupled resources.docx 20.2 KB 16 Jan 2015 Kristian Senkler MD_IR_and_ISO_ _Copy_for_editing_in_MIWP8_2.2.6Only.doc 1.42 MB 03 Feb 2015 Michael Östling MD_IR_and_ISO_ _Copy_for_editing_in_MIWP8_2.2.6Only-UK-edit-to-repharse-better.doc 1.34 MB 05 Feb 2015 James Reid Overview_DS_DSS_SRV_ObjCat.PNG 126 KB 04 Mar 2015 Geraldine Nolf 11 Dec /15

16