MIWP-8: Metadata - Task #2533 Coupled Resourses

Transcription

1 MIWP-8: Metadata - Task #2533 Coupled Resourses 02 Nov :08 pm - Pawel Soczewski Status: New Start date: 02 Nov 2015 Priority: Normal Due date: Assignee: % Done: 0% Category: Estimated time: 0.00 hour Proposed change or action: Description The using a URL to a metadata record in ISO19139 and by referencing the DataIdentification object with an Xpointer using the # in the URL we will fulfil the requirements of OperatesOn that has the data type MD_DataIdentification. History #1-02 Nov :14 pm - Pawel Soczewski Dear Peter, Many thanks indeed for your additional research. I agree with you and Markus that it is fine to use srv:operateson instead of srv:coupledresource, as already described in the current MD TGs and therefore implying we are using mixed-coupled services. I am fine with allowing, optionally, the use of srv:operateson@uuidref, even though, according to ISO 19108, its use is to refer to a spatial object whereas ISO expects metadata there instead. In this way, organisations already using RS_Identifier.codeSpace (MD_Identifier.codeSpace in the latest ISO 19115) can continue to do so waiting for AP ISO to be re-synched with the latest ISO At the same time, we need to keep srv:operateson@xlink:href mandatory in order to honour XML, ISO and ISO specifications (and we need to add the use of the fragment identifier matching the id attribute of the referred to MD_DataIdentification element as it was in the previous MD TGs). We need also to honour SC11 in the MD TGs which in the latest draft you sent ( v.055 ) is still present: /system/rich/rich_files/rich_files/000/000/376/original/image007.png The sentence shall be instantiated by reference means : 19 Dec /19

2 w.isotc211.org%2f2005%2fgmd&elementsetname=full&id=6c cf5-82cb-6586b2a2aa06"/> Instead of: Kataster Grafikdaten Best regards, Angelo Ing. Angelo Quaglia External Consultant European Commission, DG Joint Research Centre Institute for Environment and Sustainability Digital Earth and Reference Data Unit, T.P. 262 Via E. Fermi, I Ispra (VA) Italy 19 Dec /19

3 Tel: Fax: URL: The views expressed are purely those of the writer and may not in any circumstances be regarded as stating an official position of the European Commission. From: Kochmann, Peter Sent: 29 October :32 To: Cara, Pierluigi (IT); Reid, James (UK); Östling, Michael (SE); de Visser, Ine (NL); Seiler, Martin (Kst. GDI-DE); Rotundo, Antonio (IT); Quaglia, Angelo (JRC); Roos, Eliane (FR); Lutz, Michael (JRC); Senkler, Kristian (con terra); Reznik, Tomas (CZ); Lambois, Marie (FR) Subject: AW: Coupled Resourses - again Dear all, I did some research on SV_CoupledResource in ISO as well. And our German expert on ISO 191xx issues Dr. Markus Seifert told me analogously the following (I hope I ll get it well translated): Data-coupling always works with operateson. In addition to that coupledresource (added by a later amendment) is designated to document a data-coupling for a particular operation of a service! To document the related data source generally (that s what we do with data-service-coupling), operateson is still the right thing. Best regards Peter Kochmann -- Mapping and Surveying Agency of Northrhine-Westphalia c/o Bezirksregierung Köln, Geobasis NRW 19 Dec /19

4 Dezernat 74 - Geodatenzentrum, Geodateninfrastruktur D Cologne Germany Dienstgebäude: Muffendorfer Str , Bonn Telefon: +49 (0) Telefax: +49 (0) mailto:peter.kochmann@bezreg-koeln.nrw.de Von: Angelo Quaglia [mailto:angelo.quaglia@ext.jrc.ec.europa.eu] Gesendet: Dienstag, 27. Oktober :31 An: 'Pawe? Soczewski'; 'Michael Östling'; Martin.Seiler@bkg.bund.de; antonio.rotundo@agid.gov.it; eliane.roos@ign.fr; tomas.reznik@sci.muni.cz ; alejandro@geograma.com; freddy.fierens@jrc.ec.europa.eu; robert.tomas@jrc.ec.europa.eu; 'Ine de Visser'; Kochmann, Peter; 'Michael Lutz'; marc.leobet@developpement-durable.gouv.fr Betreff: RE: Coupled Resourses - again Dear Pawel, An excellent recap. I can conclude that: 1. The MD Regulation seems to have been written having in mind SV_CoupledResource 2. The drafting team of the MD TGs opted instead for SV_ServiceIdentification.operatesOn@xlink:href 3. AP ISO(*) leaves the freedom to choose between SV_ServiceIdentification.operatesOn@uuidref or SV_ServiceIdentification.operatesOn@xlink:href 4. AP ISO(*) requires, in case of tightly or mixed coupled services, the use of SV_CoupledResource in addition to the above 19 Dec /19

5 In any case, if is used, it MUST contain a link to an MD_DataIdentification element of the metadata record of a dataset/series, NOT the HTTP URI of a dataset I would like to add if SV_ServiceIdentification.operatesOn@uuidref is used then according to ISO an application domain must be defined: SV_ServiceIdentification.operatesOn@uuidref The uuidref attribute shall be used to refer to an object within the universe of an application domain. A name server may be used to resolve uuid (*) from AP ISO 1.0.0: 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 SV_ServiceIdentification.operatesOn@uuidref or SV_ServiceIdentification.operatesOn.MD_DataIdentification.citation.CI_Citation.identifier.MD_Identifier.code In the service metadata. If the values of those identifiers match, the linkage between the service and the data metadata is properly described. In the case of a tightly or mixed coupled service instance, the value of SV_ServiceIdentification.operatesOn@uuidref or SV_ServiceIdentification.operatesOn.MD_DataIdentification.citation.CI_Citation.identifier.MD_Identifier.code in the service metadata instance must be identical to the value of SV_ServiceIdentification.coupledResource.SV_CoupledResource.identifier.CharacterString. Catalogue service providers shall ensure that no inconsistencies occur between SV_ServiceIdentification.operatesOn and SV_ServiceIdentification.coupledResource in this case. The MD Regulation says 19 Dec /19

6 Best regards, Angelo Ing. Angelo Quaglia External Consultant European Commission, DG Joint Research Centre Institute for Environment and Sustainability Digital Earth and Reference Data Unit, T.P. 262 Via E. Fermi, I Ispra (VA) Italy Tel: Fax: URL: The views expressed are purely those of the writer and may not in any circumstances be regarded as stating an official position of the European Commission. From: Pawe? Soczewski Sent: 27 October :57 To: Angelo Quaglia; 'Michael Östling'; 'Ine de Visser'; 'Kochmann, Peter'; 'Michael Lutz'; Subject: Re: Coupled Resourses - again Dear All, According to ISO srv:operateson is used to provides information on the datasets that the service operates on. The value of its domain suggests to point to part of a metadata record (MD_DataIdentification). It can be realize by-reference (according CSW ISO AP using uuid) or inline. In practical point of view, a use a URL to a metadata record in ISO19139 and by referencing the DataIdentification object is also correct. However this solution isn't corresponding with IR requiments "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). The coupledresource/sv_coupledresource/identifier is more suitable, because it directly point to resource identifier. In practical point the use of coupledresource is more confusing because define a coupled resource individually for each service's operations is 19 Dec /19

7 obligatory. Summing, the coupledresource should be used when there is a need to couple dataset on which the service operates with a specific operation. Regards, pawel Pozdrawiam, Pawe? Soczewski GISPartner Sp. z o.o. ul.?wi?tojerska 5/ Warszawa tel. (22) GISPartner Sp. z o.o Wroc?aw, ul. D?ugosza 60, NIP: , REGON: , KRS nr Wydzia? VI KRS, Wroc?aw Kapita? zak?adowy z? Ta wiadomo?? skierowana jest tylko i wy??cznie do adresata i jest poufna. Je?li wiadomo?? ta dotar?a do osoby, której nazwisko nie widnieje w adresie, oznacza to, i? zosta?a ona wys?ana omy?kowo do innej osoby i?e przegl?danie, rozpowszechnianie lub te? powielanie jej jest zabronione. Je?li otrzymali Pa?stwo t? wiadomo?? przez pomy?k? prosimy nas o tym poinformowa? telefonicznie lub przez poczt? elektroniczn? oraz prosimy o usuni?cie wszelkich kopii wiadomo?ci. The information in this is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, distribution or copying of this message is strictly prohibited. If you have received this in error, please notify us by telephone or by electronic mail immediately and please delete all copies of this . W dniu o 09:41, Angelo Quaglia pisze: Dear All, I stress once more the fact that the current by reference implementation of srv:operateson is correct, even though in the examples the fragment identifier was inexpertly stripped off by the editor of the last revision. 19 Dec /19

8 The element srv:operateson is supposed to contain or point to the metadata describing the dataset(s) the service operates on: The proposed use of uuidref is completely out of place here, in my opinion. It could be that what some people really are after is a way to specify only the identifier of a dataset and not its metadata. Such element exists and it is called srv:coupledresource. I cannot find it in the UML model of ISO First edition It made its appearance in ISO First edition AMENDMENT I do not know why it was operateson instead of coupledresource that was chosen at the time to link a service with its coupled resources but I suspect the reason might be linked with the concept of coupling type of the service (loosely, mixed coupled or tightly). Best regards, Angelo 19 Dec /19

9 Ing. Angelo Quaglia External Consultant European Commission, DG Joint Research Centre Institute for Environment and Sustainability Digital Earth and Reference Data Unit, T.P. 262 Via E. Fermi, I Ispra (VA) Italy Tel: Fax: URL: The views expressed are purely those of the writer and may not in any circumstances be regarded as stating an official position of the European Commission. From: Michael Östling Sent: 25 October : 'Ine de Visser'; 'Kochmann, Peter'; 'Michael Lutz'; Subject: Coupled Resourses - again Dear All, After the discussion on tele-conf last week I need some confirmation on that we are all on same track. Peter, you disagreed that we should do any changes on the current draft regarding the Implementation of Coupled Resources with the element OperatesOn. 19 Dec /19

10 But according to the member-states feedback received (suggesting we should keep the implementation in TG Metadata 3.1) and also our discussions on Malmö I had the impression that we all agreed on that the implementation in TG 3.1 is correct and fully fulfills the requirements for Coupled Resources in Implementing Rules metadata. Using a URL to a metadata record in ISO19139 and by referencing the DataIdentification object with an Xpointer using the # in the URL we will fulfil the requirements of OperatesOn that has the data type MD_DataIdentification. This was also the suggestion for most member states. So we need to restore the current text which requires to register the Unique Resource Identifier The previous discussion have been if the OperatesOn should mandate only have the value for the Unique Resource Identifier or if we also can accept an URL to metadata. We have discussed this in drafts 02 and 03 and also in Lisbon. But the latest arguments as given by Angelo in Malmö is that by giving a reference to the Metadatarecord with URL so that the DataIdenfication object is referenced makes the Mandatory Unique Resource Identifier directly accessible. My conclusion on our discussions are that we should keep the implementation that exists in TG Metadata 3.1 but possibly also add an optional extra attribute where the Unique Resource Identifier could be registered. So can I please from group get your opinions on this. mvh Michael Michael Östling MetaGIS AB Tel: epost: michael.ostling@metagis.se SKYPE: MichaelOstling www: Adress: Britsarvsvägen 28a, FALUN, Sweden Org Nr: Dec /19

11 #2-02 Nov :20 pm - Pawel Soczewski As has already been stated, the domain of OperatesOn must be the MD_DataIdentification object. Michael's proposal is to leave the earlier draft where we implement it with a mandatory xlink:href to the MD_DataIdentification object. In detail it's to use a URL to a metadata record in ISO19139 (GetRecordById) and by referencing the DataIdentification object with an Xpointer. In my opinion it'll fulfil the requirements of OperatesOn that has the data type MD_DataIdentification but I've some doubts doubts as to the CSW services. According CSW ISO AP 1.0 the queryable property operateson is mapping to the MD_Metadata.identificationInfo.SV_ServiceIdentification.operatesOn.MD_DataIdentification.citation.CI_Citation.identifier. I'm afraid that most of CSW server solutions can't resolve the URL to a metadata record and serach a connected metadata file. I think that the practical working of CSW servers is a comparison value of operateson query with value of uuidref or xlink:href attribute of MD_Metadata.identificationInfo.SV_ServiceIdentification.operatesOn object (it should be tested). That's why a very practical use case "the user have found a dataset and is interested to find service that shares this dataset" may be nonexecutable. With this in mind I'm convinced that the Unique Resource Identifier should be mandatory part of OperatesOn. I would suggest a solution based on the results of the previous long discussion on the wiki: - attributes uuidref and xlink:href are obligatory - attribute xlink:href is a URL to a metadata record in ISO19139 (GetRecordById) and by referencing the DataIdentification object with an Xpointer. Possibly if Unique Resource Identifier is a dereferenceable URL, pointing to the metadata record of the resource, that URL could be replace URL of GetRecordById (Peter's proposal) - attribute uuidref has the value of the Unique Resource Identifier I know that using of uuidref attribute isn't commpilant with ISO but I'm afraid hat there is no perfect solution. Mayby only a using in-line the MD_DataIdentification object but it again is contrary to the SC 11. #3-02 Nov :15 pm - Peter Kochmann Thanks to Pawel for his clarification on this! I agree but propose to change the sequence of documenting the two ways in xlink:href. First choice should be to use the unique resource identifier (because this is demanded by IR 1205/2008; In the background a dereferencing must be able to point to the MD_DataIdentifcation-object). Using a CSW-GetRecordById-statement instead containing the fileidentifier and a pointer should be possible but flagged as an alternative (for those not being able to dereference the unique resource identifier and to consider existing implementations). #4-02 Nov :33 pm - Angelo Quaglia Every INSPIRE Technical Guidance Document specifies the position of required metadata elements inside larger documents like, for example, OGC Capabilities Documents or Atom feeds etc. The argument "because this is demanded by IR 1205/2008" can be easily dismissed by saying that compliance with the MD Regulation is achieved by specifying the exact mapping of the metadata element which is: SV_ServiceIdentification.operatesOn.MD_DataIdentification.citation.CI_Citation.identifier.MD_Identifier.code This is one of the two options allowed by ISO AP If some of the existing CSW solutions do not yet fully implement the required standards, then they will have one more reason to complete their implementation. Even putting aside for a moment the appropriateness of use of uuidref with respect to ISO 19108, before proposing to make its use mandatory one 19 Dec /19

12 should define the Application Domain inside which the value contained in uuidref is unique #5-02 Nov :06 pm - James Reid I concur with Michael and Peter that at the very least using a CSW-GetRecordById should be possible and flagged as an acceptable alternative. The maturity of actual CSW tooling may not encourage data providers to adopt a full URI approach and I believe that prgamatically that might be a real impediment for data providers especially those under Annex III. #6-03 Nov :06 pm - Marie Lambois Could you summarize the point of disagreement? It seems to me that evreybody goes on the same direction but maybe I missed the 2 different options. For me a GetRecord or a URI pointing to the metadata is just the same thing: a link to the XML metadata. #7-03 Nov :59 pm - Angelo Quaglia The discussion is about whether to use SV_ServiceIdentification.operatesOn@uuidref or SV_ServiceIdentification.operatesOn.MD_DataIdentification.citation.CI_Citation.identifier.MD_Identifier.code The second option needs to be implemented by reference, i.e. by using SV_ServiceIdentification.operatesOn@xlink:href Some want to make the first option mandatory, others want the second to be kept mandatory. #8-03 Nov :05 pm - James Reid Nicely summarised! FWIW I believe we should make one of them mandatory but let implementers choose which one they can fulfill in practice. I have doubts that many can do option Dec /19

13 #9-03 Nov :20 pm - Angelo Quaglia James Reid wrote: Nicely summarised! FWIW I believe we should make one of them mandatory but let implementers choose which one they can fulfill in practice. I have doubts that many can do option 2... In any case, they have to populate the MetadataURL element for each layer declared inside OGC WMS View Services. If they can put the value there, they can certainly put the same value also here. #10-03 Nov :00 pm - Marie Lambois Thanks Angelo I understand it better now. I have never seen any implementation of option 1 (uuidref). What is recommended in France is option 2. I do not unterstand why option 1 would be easier to implement. It seems that software mostly support option 2 ( Geonetwork implements both). My opinion is then: There is no need to forbid option 1 (it can be used in combination with option 2) but it will be useful in an internal catalog more than in an INSPIRE infrastructure. Moreover, option 1 makes necessary to have uuid metadata identifier, which is not mandatory in the TG. From what I have seen the uuidref does not seem to be the resource identifier but more the fileidentifier so it does not have any added value concerning the mention of the resource identifier. #11-04 Nov :40 am - Pawel Soczewski Angelo Quaglia napisa?(a): The discussion is about whether to use SV_ServiceIdentification.operatesOn@uuidref or SV_ServiceIdentification.operatesOn.MD_DataIdentification.citation.CI_Citation.identifier.MD_Identifier.code The second option needs to be implemented by reference, i.e. by using SV_ServiceIdentification.operatesOn@xlink:href Some want to make the first option mandatory, others want the second to be kept mandatory. I think that choose isn't obvious :( We still need to remember IR requirement: 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). Option 1 (uuidref) As is explained Kristian on the wiki, according ISO19108 uuidref doesn't point to metadata identifier or unique resource identifiers. It points to uuid of MD_DataIdentification object. Example: [...] 19 Dec /19

14 Moreover, according standards it should be the universally unique identifier (UUID) form. For example: de305d54-75b4-431b-adb2-eb6b9e Option 1 (SV_ServiceIdentification.operatesOn.MD_DataIdentification.citation.CI_Citation.identifier.MD_Identifier.code) We must embed in service's metadata record min citation (title, date, identifier/code), abstract and language elements of MD_DataIdentification object from dataset metadata record. Option 2 (xlink:href) To may mind using of xlink:href is not provided as CSW ISO AP. According XML standards a its value should be URL to online resource, for example GetRecordById. I'm afraid that most of CSW server solutions can't resolve the URL to a metadata record and serach a connected metadata file :( In concussion, in my opinion the solution fully compliant with current standards (ISO19119, CSW ISO AP) and providing practical search of services that operate on a dataset is a option 1 with embed MD_DataIdentification object. But the issue is nobody do it so far, "new" service's metadata record it's more extensive and it's "by reference" according SC11 in the MD TGs. The very good solution is a German variant, where resource identifier is a dereferenceable URL. This allows using xlink:href and at the same time provides the functionality to search of services that operate on a dataset without resolve the URL to a metadata record. #12-04 Nov :59 am - Peter Kochmann Angelo Quaglia schrieb: In any case, they have to populate the MetadataURL element for each layer declared inside OGC WMS View Services. If they can put the value there, they can certainly put the same value also here. It's not a question of having the MetadataURL or having not. Of course it's present and known. And by the way in the WMS capabilities the identifier of the resource is documented at each relevant layer as well. If they can put the value there... #13-04 Nov :28 am - Angelo Quaglia Pawel Soczewski wrote: I think that choose isn't obvious :( We still need to remember IR requirement: 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). Option 1 (uuidref) As is explained Kristian on the wiki, according ISO19108 uuidref doesn't point to metadata identifier or unique resource identifiers. It points to uuid of MD_DataIdentification object. Example: [...] Moreover, according standards it should be the universally unique identifier (UUID) form. For example: de305d54-75b4-431b-adb2-eb6b9e Option 1 (SV_ServiceIdentification.operatesOn.MD_DataIdentification.citation.CI_Citation.identifier.MD_Identifier.code) We must embed in service's metadata record min citation (title, date, identifier/code), abstract and language elements of MD_DataIdentification object from dataset metadata record. Option 2 (xlink:href) To may mind using of xlink:href is not provided as CSW ISO AP. According XML standards a its value should be URL to online resource, for example GetRecordById. I'm afraid that most of CSW server solutions can't resolve the URL to a metadata record and serach a connected metadata file :( In concussion, in my opinion the solution fully compliant with current standards (ISO19119, CSW ISO AP) and providing practical search of services that operate on a dataset is a option 1 with embed MD_DataIdentification object. But the issue is nobody do it so far, "new" service's metadata record it's more extensive and it's "by reference" according SC11 in the MD TGs. The very good solution is a German variant, where resource identifier is a dereferenceable URL. This allows using xlink:href and at the same time provides the functionality to search of services that operate on a dataset without resolve the URL to a metadata record. xlink:href The use of xlink:href is governed by specifications and standards upon which ISO /ISO 19119/ISO are built. The specification makes absolutely equivalent to: 19 Dec /19

15 This is one of the two options allowed by ISO AP If some of the existing CSW solutions do not yet fully implement the required standards, then they will have one more reason to complete their implementation. uuidref Indeed, option 1 (uuidref) is the uuid of MD_DataIdentification exactly like the fragment identifier of xlink:href. Even putting aside for a moment the appropriateness of use of uuidref with respect to ISO 19108, before proposing to make its use mandatory one should define the Application Domain inside which the value contained in uuidref is unique. a) uuidref was thought for pointing to features and not metadata elements b) Which is the Application Domain once all metadata doucments are inside the INSPIRE Geoportal c) How will a client be able to resolve the id and retrieve the MD_DataIdentification element once the metadata is outside the catalogue it came from? d) Some organizations prefer to partition their codes with namespaces and for that reason the namespace information has been added to MD_Identifier in ISO #14-04 Nov :39 am - Angelo Quaglia Peter Kochmann wrote: Angelo Quaglia schrieb: In any case, they have to populate the MetadataURL element for each layer declared inside OGC WMS View Services. If they can put the value there, they can certainly put the same value also here. It's not a question of having the MetadataURL or having not. Of course it's present and known. And by the way in the WMS capabilities the identifier of the resource is documented at each relevant layer as well. If they can put the value there... So, I understand that populating the xlink:href is not a problem. That is anyway required by SC11 in the MD TGs (including the draft). If you want to optionally use uuidref, that is fine for me but first try to answer points a,b,c,d in my answer to Pawel. I think it would not be a problem to add a rule for clients like: if uuidref is there, then the client must first try to search all MD_DataIdentification objects harvested (from the same catalogue?), which must have been indexed by their uuid attribute. Of course uuid attribute values must be unique across all metadata documents. #15-04 Nov :53 am - Peter Kochmann Angelo Quaglia schrieb: The discussion is about whether to use SV_ServiceIdentification.operatesOn@uuidref or 19 Dec /19

16 SV_ServiceIdentification.operatesOn.MD_DataIdentification.citation.CI_Citation.identifier.MD_Identifier.code The second option needs to be implemented by reference, i.e. by using Some want to make the first option mandatory, others want the second to be kept mandatory. Firstly to my point of view the discussion still is on using the unique resource identifier (from 2.2.5; what is given in IR MD) or a URL of the metadata record (which is technical necessary to access the MD_DataIdentification object; what is given by ISO 19119). Taking into account that (1) not everybody will be able to resolve xlink:href="/" into a corresponding GetRecords-command containing the URI from as the argument to search and taking into account as well that (2) a majority of member states voted for keeping the current solution I see that the latest draft in chapter might be too restrictive. So I see no other way than to leave it open: Use of URI (similar to the one in 2.2.5) might be mostly in line with IR MD, but for fulfilling technical requirements (CSW AP ISO, ISO 19119) a GetRecordByID-command containing the fileidentifier (similar to MetadataURL in WMS capabilities) might be useful if URI (2.2.5) can't be resolved. The term "mandatory" should then be used only to demand the access on the MD_DataIdentification object, taking any way for achieving that. #16-04 Nov :58 am - Peter Kochmann Angelo Quaglia schrieb: c) How will a client be able to resolve the id and retrieve the MD_DataIdentification element once the metadata is outside the catalogue it came from? In German registry the namespace (first part of URI in 2.2.5) or leading characters of the code part can be dedicated to a particular CSW. Therefore the resolving also gives the chance to access particular local catalogues. #17-04 Nov :01 pm - Angelo Quaglia Pawel Soczewski wrote: As has already been stated, the domain of OperatesOn must be the MD_DataIdentification object. Michael's proposal is to leave the earlier draft where we implement it with a mandatory xlink:href to the MD_DataIdentification object. In detail it's to use a URL to a metadata record in ISO19139 (GetRecordById) and by referencing the DataIdentification object with an Xpointer. In my opinion it'll fulfil the requirements of OperatesOn that has the data type MD_DataIdentification but I've some doubts doubts as to the CSW services. According CSW ISO AP 1.0 the queryable property operateson is mapping to the MD_Metadata.identificationInfo.SV_ServiceIdentification.operatesOn.MD_DataIdentification.citation.CI_Citation.identifier. I'm afraid that most of CSW server solutions can't resolve the URL to a metadata record and serach a connected metadata file. I think that the practical working of CSW servers is a comparison value of operateson query with value of uuidref or xlink:href attribute of MD_Metadata.identificationInfo.SV_ServiceIdentification.operatesOn object (it should be tested). That's why a very practical use case "the user have found a dataset and is interested to find service that shares this dataset" may be nonexecutable. With this in mind I'm convinced that the Unique Resource Identifier should be mandatory part of OperatesOn. I would suggest a solution based on the results of the previous long discussion on the wiki: - attributes uuidref and xlink:href are obligatory - attribute xlink:href is a URL to a metadata record in ISO19139 (GetRecordById) and by referencing the DataIdentification object with an Xpointer. Possibly if Unique Resource Identifier is a dereferenceable URL, pointing to the metadata record of the resource, that URL could be replace URL of GetRecordById (Peter's proposal) - attribute uuidref has the value of the Unique Resource Identifier I know that using of uuidref attribute isn't commpilant with ISO but I'm afraid hat there is no perfect solution. Mayby only a using in-line the MD_DataIdentification object but it again is contrary to the SC 11. If the one in bold is the main reason why some are pushing for the uuidref solution, I think it needs to be explained how it can properly handle the fact that a Spatial Dataset can have multiple Unique Resource Identifiers, which would play the role of synonyms when a new identification scheme is introduced: 19 Dec /19

17 /system/rich/rich_files/rich_files/000/000/378/original/mail33.png In that case, which is the identifier that needs to be used as uuid and uuidref? The first, the last and based on what order? Say that an Organisation decides to change the Unique Resource Identifier scheme and adds a Unique Resource Identifier to the one(s) already there for a dataset, and decides to update also the uuid of the MD_DataIdentification elements, what happens to already existing service metadata pointing to the datasets? In order to be aware of the synonyms, a CSW would need to analyse the dataset metadata anyway. #18-04 Nov :59 pm - Antonio Rotundo Even seen the last post by Angelo (the multiplicity of the Unique Resource Identifier for a dataset could be >1 on the base of IR), I agree with the latest proposal of Peter (#15), i.e. to leave the choice open: an URI (as in 2.2.5) or a URL to the metadata record through a GetRecordById request. #19-04 Nov :02 pm - Angelo Quaglia It is of course fine to express a preference, but open issues have to be addressed. #20-04 Nov :55 pm - Antonio Rotundo I explain better my preference, trough an attempt of the new wording of the requirement: The property shall be implemented by reference using the XML attribute xlink:href (see SC11 in 1.2): - to reference the resource identifier of dataset (given as URI, see 2.2.5), if the URI is a dereferenceable URL; - to reference the metadata record through a GetRecordById request, if the URI is not a dereferenceable URL. In that case, the URI shall be provided through a uuidref attribute in the same XML tag. With respect to the proposal of Peter, I think, I foreseen the use of additional uuidref attribute in the second option. The third XML example in in the draft is conformant to the second option. I see no other way. #21-05 Nov :43 pm - Pawel Soczewski Angelo Quaglia napisa?(a): The use of xlink:href is governed by specifications and standards upon which ISO /ISO 19119/ISO are built. The specification makes absolutely equivalent to: This is one of the two options allowed by ISO AP If some of the existing CSW solutions do not yet fully implement the required standards, then they will have one more reason to complete their implementation. I know that the use of xlink:href is permitted by ISO19139 but I am of the opinion that in the CSW ISO AP doesn't specify the use of xlink:href, especially for operateson. The Annex F descibes how implement a coupling between service instance and dataset instance and there isn't xlink:href. 19 Dec /19

18 However, regardless of this I am not supporter of the use of uuidref in "pure" ISO. Angelo Quaglia napisa?(a): I think it needs to be explained how it can properly handle the fact that a Spatial Dataset can have multiple Unique Resource Identifiers, which would play the role of synonyms when a new identification scheme is introduced. I agree that is issue. With this in mind, I agree that the only sensible solution is to use xlink:href with reference to meatadata record (GetRecordById request or dereferenceable URI) with xpointer to MD_DataIdentification. The use a uuidref with URI becomes unfounded. I stress, however once again that most of CSW servers can't resolve the URL to a metadata record and serach a connected metadata file, especially from other CSW. Of course we can force them to implement it but later these new software versions will have to be implemented in many administrations what may involve considerable costs. It also must be taken into consideration. #22-06 Nov :37 am - Marc Leobet Dear colleagues, I keep an eye on your exchanges and I worry about what seems to be an endless discussion. I thought we solve most - in fact, all - issues in Malmö, and I was very happy to saw the group reaching a consensus. I do not understand what happened. I would like to stress that, from my point of view, the true goal is not the technical guidelines : we will obviously get one, anyhow. The main value of the group is to bring a solution to be able to developp a European validator. To agree on it, I believe that Member states would need to fully trust the proposed solution, and the experts consensus is the key. Without that consensus, which could ask for compromises between experts and, after, between MS, there is a huge risk to let each MS with its own validation engine. That means, no European compliancy, and no full interoperability. It would be nice if we could hear a consensual proposal in Roma, in first days of December. Without it, could I propose to flip a coin to choose between solutions? (I am kidding!) #23-06 Nov :18 pm - Angelo Quaglia It is important to ensure that technical choices are respectful of the embraced standards and the legislation. This subject is technical and as group members leave the group and new ones join, sometimes the discussion needs to be restarted. When discussing orally, critical aspects are easily overlooked and a thorough technical review is always necessary. #24-06 Nov :34 pm - Angelo Quaglia The uuidref attribute can of course be used in addition to the mandatory xlink:href, with the aforementioned caveats. 19 Dec /19

19 A requirement can be added to the Technical Guidance saying that clients will have to try to use first the value of uuidref, when present, to resolve the coupled resource. It is usually better to explicitly formulate any specific could you please make explicit the requirement for France? 19 Dec /19

20