miwp-8: metadata - task #2533 - mig collaboration … any case, if...

MIWP-8 Metadata - Task 2533Coupled Resourses02 Nov 2015 1208 pm - Pawel Soczewski

Status New Start date 02 Nov 2015Priority Normal Due dateAssignee Done 0Category Estimated time 000 hourProposed change or actionDescription

The using a URL to a metadata record in ISO19139 and by referencing the DataIdentification object with an Xpointer using the in theURL we will fulfil the requirements of OperatesOn that has the data type MD_DataIdentification

History1 - 02 Nov 2015 1214 pm - Pawel Soczewski

Dear Peter

Many thanks indeed for your additional research

I agree with you and Markus that it is fine to use srvoperatesOn instead of srvcoupledResource as already described in the current MD TGs andtherefore implying we are using mixed-coupled services

I am fine with allowing optionally the use of srvoperatesOnuuidref even though according to ISO 19108 its use is to refer to a spatial objectwhereas ISO 19119 expects metadata there instead

In this way organisations already using RS_IdentifiercodeSpace (MD_IdentifiercodeSpace in the latest ISO 19115) can continue to do so waitingfor AP ISO to be re-synched with the latest ISO 19115

At the same time we need to keep srvoperatesOnxlinkhref mandatory in order to honour XML ISO 19115 and ISO 19119 specifications (andwe 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 previousMD TGs)We need also to honour SC11 in the MD TGs which in the latest draft you sent (ldquov055rdquo) is still present

systemrichrich_filesrich_files000000376originalimage007png

The sentence ldquoshall be instantiated by referencerdquo means

25 Jun 2018 119

httpsdbevgvatatgvbevdiscoverysrvdecsw202service=CSWamprequest=GetRecordByIdampversion=202ampoutputSchema=http3A2F2Fwwisotc211org2F20052FgmdampElementSetName=fullampid=6c316854-5453-4cf5-82cb-6586b2a2aa06gt

Instead of

Kataster Grafikdaten

hellip

Best regards

Angelo

Ing Angelo Quaglia

External Consultant

European Commission DG Joint Research CentreInstitute for Environment and Sustainability

Digital Earth and Reference Data Unit TP 262

Via E Fermi 2749I-21027 Ispra (VA)Italy

25 Jun 2018 219

Tel +39 347 78 88 492Fax +39 0332 78 6325e-mail mailtoangeloquagliaextjrceceuropaeu

URL httpiesjrceceuropaeuSDIsdi-about-usstaff-profilesangelo-quagliahtml

The views expressed are purely those of the writer and may not in any circumstances be regarded as stating an official position of the EuropeanCommission

From Kochmann Peter [mailtopeterkochmannbezreg-koelnnrwde]Sent 29 October 2015 1132To psoczewskigispartnerpl alejandrogeogramacom freddyfierensjrceceuropaeu roberttomasjrceceuropaeu Cara Pierluigi (IT)Reid James (UK) Oumlstling Michael (SE) de Visser Ine (NL) Seiler Martin (Kst GDI-DE) Rotundo Antonio (IT) Quaglia Angelo (JRC) RoosEliane (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 19119 as well

And our German expert on ISO 191xx issues Dr Markus Seifert told me analogously the following (I hope Irsquoll get it well translated)

Data-coupling always works with ldquooperatesOnrdquo In addition to that coupledResource (added by a later amendment) is designated to document adata-coupling for a particular operation of a service

To document the related data source generally (thatrsquos what we do with data-service-coupling) operatesOn is still the right thing

Best regards

Peter Kochmann

--

Mapping and Surveying Agency of Northrhine-Westphalia

co Bezirksregierung Koumlln Geobasis NRW

25 Jun 2018 319

Dezernat 74 - Geodatenzentrum Geodateninfrastruktur

D-50606 Cologne

Germany

Dienstgebaumlude Muffendorfer Str 19-21 53177 Bonn

Telefon +49 (0) 221 - 147 - 4460

Telefax +49 (0) 221 - 147 - 4874

mailtopeterkochmannbezreg-koelnnrwde

httpwwwbezreg-koelnnrwde

Von Angelo Quaglia [mailtoangeloquagliaextjrceceuropaeu]Gesendet Dienstag 27 Oktober 2015 1731An Pawe Soczewski Michael Oumlstling MartinSeilerbkgbundde antoniorotundoagidgovit elianeroosignfr tomasreznikscimunicz alejandrogeogramacom freddyfierensjrceceuropaeu roberttomasjrceceuropaeu Ine de Visser Kochmann Peter Michael Lutz marcleobetdeveloppement-durablegouvfrBetreff 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_ServiceIdentificationoperatesOnxlinkhref 3 AP ISO() leaves the freedom to choose between SV_ServiceIdentificationoperatesOnuuidref or SV_ServiceIdentificationoperatesOnxlinkhref 4 AP ISO() requires in case of tightly or mixed coupled services the use of SV_CoupledResource in addition to the above

25 Jun 2018 419

In any case if SV_ServiceIdentificationoperatesOnxlinkhref is used it MUST contain a link to an MD_DataIdentification element of themetadata record of a datasetseries NOT the HTTP URI of a dataset

I would like to add if SV_ServiceIdentificationoperatesOnuuidref is used then according to ISO 19118 an application domain must be defined

SV_ServiceIdentificationoperatesOnuuidref

The ldquouuidrefrdquo attribute shall be used to refer to an object within the universe of an application domain A name server may be used to resolveldquouuidrdquo

() from AP ISO 100

It is recommended to support the linkage between services and data instances defining equality of

MD_DataIdentificationcitationCI_CitationidentifierMD_Identifiercode for data metadata and one of

middot SV_ServiceIdentificationoperatesOnuuidref or

middot SV_ServiceIdentificationoperatesOnMD_DataIdentificationcitationCI_CitationidentifierMD_Identifiercode

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



in the service metadata instance must be identical to the value of

SV_ServiceIdentificationcoupledResourceSV_CoupledResourceidentifierCharacterString

Catalogue service providers shall ensure that no inconsistencies occur between SV_ServiceIdentificationoperatesOn andSV_ServiceIdentificationcoupledResource in this case

The MD Regulation says

25 Jun 2018 519

Best regards

Angelo

Ing Angelo Quaglia

External Consultant







From Pawe Soczewski [mailtopsoczewskigispartnerpl]Sent 27 October 2015 1557To Angelo Quaglia Michael Oumlstling MartinSeilerbkgbundde antoniorotundoagidgovit elianeroosignfr tomasreznikscimunicz alejandrogeogramacom freddyfierensjrceceuropaeu roberttomasjrceceuropaeu Ine de Visser Kochmann Peter Michael Lutz marcleobetdeveloppement-durablegouvfrSubject Re Coupled Resourses - again

Dear AllAccording to ISO 19119 srvoperatesOn is used to provides information on the datasets thatthe service operates on The value of its domain suggests to point to part of a metadata record (MD_DataIdentification) It can be realizeby-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 byreferencing the DataIdentification object is also correct However this solution isnt corresponding with IR requiments Coupled resource - If theresource is a spatial data service this metadata element identifies where relevant the target spatial data set(s) of the service through their uniqueresource identifiers (URI) The coupledResourceSV_CoupledResourceidentifier is more suitable because it directly point to resource identifierIn practical point the use of coupledResource is more confusing because define a coupled resource individually for each services operations is

25 Jun 2018 619

obligatorySumming the coupledResource should be used when there is a need to couple dataset on which the service operates with a specific operation

Regardspawel

Pozdrawiam

Pawe Soczewski

GISPartner Sp z ooul witojerska 5700-236Warszawa

tel (22) 860 01 92

httpwwwgispartnerpl

GISPartner Sp z oo 51-162 Wrocaw ul Dugosza 60 NIP 898-20-27-647REGON 932942367 KRS nr 0000173717 Wydzia VI KRSWrocaw Kapita zakadowy 50 000 z

Ta wiadomo skierowana jest tylko i wycznie do adresata i jest poufna Jeli wiadomo ta dotara do osoby ktoacuterej nazwisko nie widnieje wadresie oznacza to i zostaa ona wysana omykowo do innej osoby i e przegldanie rozpowszechnianie lub te powielanie jej jestzabronione Jeli otrzymali Pastwo t wiadomo przez pomyk prosimy nas o tym poinformowa telefonicznie lub przez poczt elektronicznoraz prosimy o usunicie wszelkich kopii wiadomoci

The information in this e-mail is intended only for the personal and confidential use of the recipient(s) named above If the reader of this e-mail isnot the intended recipient or an agent responsible for delivering it to the intended recipient you are hereby notified that you have received thisdocument in error and that any review distribution or copying of this message is strictly prohibited If you have received this e-mail in error pleasenotify us by telephone or by electronic mail immediately and please delete all copies of this e-mail

W dniu 2015-10-26 o 0941 Angelo Quaglia pisze

Dear All

I stress once more the fact that the current ldquoby referencerdquo implementation of srvoperatesOn is correct even though in the examples thefragment identifier was inexpertly stripped off by the editor of the last revision

25 Jun 2018 719

The element srvoperatesOn 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 ldquosrvcoupledResourcerdquo

I cannot find it in the UML model of ISO 19119 -First edition 2005-02-15

It made its appearance in ISO 19119 -First edition 2005-02-15 - AMENDMENT 1 - 2008-05-01

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 Isuspect the reason might be linked with the concept of coupling type of the service (loosely mixed coupled or tightly)

Best regards

Angelo

25 Jun 2018 819

Ing Angelo Quaglia

External Consultant







From Michael Oumlstling [mailtomichaelostlingmetagisse]Sent 25 October 2015 1619ToMartinSeilerbkgbundde antoniorotundoagidgovit elianeroosignfr psoczewskigispartnerpl tomasreznikscimunicz alejandrogeogramacom angeloquagliaextjrceceuropaeu freddyfierensjrceceuropaeu roberttomasjrceceuropaeu Ine deVisser Kochmann Peter Michael Lutz marcleobetdeveloppement-durablegouvfrSubject 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 elementOperatesOn

25 Jun 2018 919

But according to the member-states feedback received (suggesting we should keep the implementation in TG Metadata 31) and also ourdiscussions on Malmouml I had the impression that we all agreed on thatthe implementation in TG 31 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 willfulfil 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 canaccept 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 Malmouml is that by giving a reference to the Metadatarecord with URL so that the DataIdenficationobject is referencedmakes the Mandatory Unique Resource Identifier directly accessible

My conclusion on our discussions are that we should keep the implementation that exists in TG Metadata 31 but possibly also add an optionalextra attribute where the Unique Resource Identifier could be registered

So can I please from group get your opinions on this

mvhMichael------------------------------------------------------------------

Michael Oumlstling

MetaGIS ABTel 070-279 19 76ePost michaelostlingmetagisseSKYPE MichaelOstlingwww httpwwwmetagisseAdress Britsarvsvaumlgen 28a 791 36 FALUN SwedenOrg Nr 556638-7170

25 Jun 2018 1019

2 - 02 Nov 2015 1220 pm - Pawel Soczewski

As has already been stated the domain of OperatesOn must be the MD_DataIdentification object Michaels proposal is to leave the earlier draft wherewe implement it with a mandatory xlinkhref to the MD_DataIdentification object In detail its to use a URL to a metadata record in ISO19139(GetRecordById) and by referencing the DataIdentification object with an Xpointer In my opinion itll fulfil the requirements of OperatesOn that has thedata type MD_DataIdentification but Ive some doubts doubts as to the CSW services According CSW ISO AP 10 the queryable property operatesOnis mapping to the MD_MetadataidentificationInfoSV_ServiceIdentificationoperatesOnMD_DataIdentificationcitationCI_Citationidentifier Im afraidthat most of CSW server solutions cant resolve the URL to a metadata record and serach a connected metadata file I think that the practical workingof CSW servers is a comparison value of operatesOn query with value of uuidref or xlinkhref attribute ofMD_MetadataidentificationInfoSV_ServiceIdentificationoperatesOn object (it should be tested) Thats why a very practical use case the user havefound a dataset and is interested to find service that shares this dataset may be nonexecutable

With this in mind Im convinced that the Unique Resource Identifier should be mandatory part of OperatesOn I would suggest a solution based on theresults of the previous long discussion on the wiki - attributes uuidref and xlinkhref are obligatory - attribute xlinkhref is a URL to a metadata record in ISO19139 (GetRecordById) and by referencing the DataIdentification object with an XpointerPossibly if Unique Resource Identifier is a dereferenceable URL pointing to the metadata record of the resource that URL could be replace URL ofGetRecordById (Peters proposal) - attribute uuidref has the value of the Unique Resource Identifier I know that using of uuidref attribute isnt commpilant with ISO 19118 but Im afraid hat there is no perfect solution Mayby only a using in-line theMD_DataIdentification object but it again is contrary to the SC 11

3 - 02 Nov 2015 0215 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 xlinkhref First choice should be to use the unique resource identifier(because this is demanded by IR 12052008 In the background a dereferencing must be able to point to the MD_DataIdentifcation-object) Using aCSW-GetRecordById-statement instead containing the fileIdentifier and a pointer should be possible but flagged as an alternative (for those not beingable to dereference the unique resource identifier and to consider existing implementations)

4 - 02 Nov 2015 0233 pm - Angelo Quaglia

Every INSPIRE Technical Guidance Document specifies the position of required metadata elements inside larger documents like for example OGCCapabilities Documents or Atom feeds etc

The argument because this is demanded by IR 12052008 can be easily dismissed by saying that compliance with the MD Regulation is achieved byspecifying the exact mapping of the metadata element which is

SV_ServiceIdentificationoperatesOnMD_DataIdentificationcitationCI_CitationidentifierMD_Identifiercode

This is one of the two options allowed by ISO AP 100

If some of the existing CSW solutions do not yet fully implement the required standards then they will have one more reason to complete theirimplementation

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

25 Jun 2018 1119

should define the Application Domain inside which the value contained in uuidref is unique

5 - 02 Nov 2015 0306 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 Thematurity of actual CSW tooling may not encourage data providers to adopt a full URI approach and I believe that prgamatically that might be a realimpediment for data providers especially those under Annex III

6 - 03 Nov 2015 0406 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 differentoptions

For me a GetRecord or a URI pointing to the metadata is just the same thing a link to the XML metadata


The discussion is about whether to use



The second option needs to be implemented by reference ie by using SV_ServiceIdentificationoperatesOnxlinkhref

Some want to make the first option mandatory others want the second to be kept mandatory

8 - 03 Nov 2015 0505 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 havedoubts that many can do option 2

25 Jun 2018 1219


James Reid wroteNicely summarised FWIW I believe we should make one of them mandatory but let implementers choose which one they can fulfill in practice Ihave 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


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 (httpsourceforgenetpcatmdeditfeature-requests2 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 thanin an INSPIRE infrastructure Moreover option 1 makes necessary to have uuid metadata identifier which is not mandatory in the TG From what Ihave seen the uuidref does not seem to be the resource identifier but more the fileidentifier so it does not have any added value concerning themention of the resource identifier

11 - 04 Nov 2015 0940 am - Pawel Soczewski

Angelo Quaglia napisa(a)The discussion is about whether to use middot SV_ServiceIdentificationoperatesOnuuidref or middot SV_ServiceIdentificationoperatesOnMD_DataIdentificationcitationCI_CitationidentifierMD_Identifiercode The second option needs to beimplemented by reference ie by using SV_ServiceIdentificationoperatesOnxlinkhref Some want to make the first option mandatory otherswant the second to be kept mandatory

I think that choose isnt obvious ( We still need to remember IR requirement Coupled resourceIf 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 doesnt point to metadata identifier or unique resource identifiers It points to uuid ofMD_DataIdentification object Example

[]

25 Jun 2018 1319

Moreover according standards it should be the universally unique identifier (UUID) form For example de305d54-75b4-431b-adb2-eb6b9e546014

Option 1 (SV_ServiceIdentificationoperatesOnMD_DataIdentificationcitationCI_CitationidentifierMD_Identifiercode)We must embed in services metadata record min citation (title date identifiercode) abstract and language elements of MD_DataIdentification objectfrom dataset metadata record

Option 2 (xlinkhref)To may mind using of xlinkhref is not provided as CSW ISO AP According XML standards a its value should be URL to online resource for exampleGetRecordById Im afraid that most of CSW server solutions cant 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 servicesthat operate on a dataset is a option 1 with embed MD_DataIdentification object But the issue is nobody do it so far new services metadata recordits more extensive and its 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 xlinkhref and at the same timeprovides the functionality to search of services that operate on a dataset without resolve the URL to a metadata record

12 - 04 Nov 2015 1059 am - Peter Kochmann

Angelo Quaglia schriebIn any case they have to populate the MetadataURL element for each layer declared inside OGC WMS View Services If they can put the valuethere they can certainly put the same value also here

Its not a question of having the MetadataURL or having not Of course its present and known And by the way in the WMS capabilities the identifier ofthe resource is documented at each relevant layer as well If they can put the value there

13 - 04 Nov 2015 1128 am - Angelo Quaglia

Pawel Soczewski wroteI think that choose isnt obvious ( We still need to remember IR requirement Coupled resource If the resource is a spatial data service thismetadata 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 doesnt point to metadata identifier or unique resource identifiers Itpoints to uuid of MD_DataIdentification object Example [] Moreover according standards it should be the universally uniqueidentifier (UUID) form For example de305d54-75b4-431b-adb2-eb6b9e546014 Option 1(SV_ServiceIdentificationoperatesOnMD_DataIdentificationcitationCI_CitationidentifierMD_Identifiercode) We must embed in servicesmetadata record min citation (title date identifiercode) abstract and language elements of MD_DataIdentification object from dataset metadatarecord Option 2 (xlinkhref) To may mind using of xlinkhref is not provided as CSW ISO AP According XML standards a its value should be URLto online resource for example GetRecordById Im afraid that most of CSW server solutions cant resolve the URL to a metadata record andserach a connected metadata file ( In concussion in my opinion the solution fully compliant with current standards (ISO19119 CSW ISO AP) andproviding practical search of services that operate on a dataset is a option 1 with embed MD_DataIdentification object But the issue is nobody doit so far new services metadata record its more extensive and its by reference according SC11 in the MD TGs The very good solution is aGerman variant where resource identifier is a dereferenceable URL This allows using xlinkhref and at the same time provides the functionality tosearch of services that operate on a dataset without resolve the URL to a metadata record

xlinkhref

The use of xlinkhref is governed by specifications and standards upon which ISO 191115ISO 19119ISO 19139 are built

The specification makes httpidofMD_DataIdentificationgt

absolutely equivalent to

25 Jun 2018 1419



uuidref

Indeed option 1 (uuidref) is the uuid of MD_DataIdentification exactly like the fragment identifier of xlinkhref

Even putting aside for a moment the appropriateness of use of uuidref with respect to ISO 19108 before proposing to make its use mandatory oneshould 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 toMD_Identifier in ISO 19115-1


Peter Kochmann wroteAngelo Quaglia schrieb In any case they have to populate the MetadataURL element for each layer declared inside OGC WMS View Services Ifthey can put the value there they can certainly put the same value also here Its not a question of having the MetadataURL or having not Ofcourse its present and known And by the way in the WMS capabilities the identifier of the resource is documented at each relevant layer as wellIf they can put the value there

So I understand that populating the xlinkhref 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 abcd 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 beenindexed by their uuid attribute

Of course uuid attribute values must be unique across all metadata documents


Angelo Quaglia schriebThe discussion is about whether to use middot SV_ServiceIdentificationoperatesOnuuidref or middot

25 Jun 2018 1519

SV_ServiceIdentificationoperatesOnMD_DataIdentificationcitationCI_CitationidentifierMD_Identifiercode The second option needs to beimplemented by reference ie by using SV_ServiceIdentificationoperatesOnxlinkhref Some want to make the first option mandatory otherswant the second to be kept mandatory

Firstly to my point of view the discussion still is on using the unique resource identifier (from 225 what is given in IR MD) or a URL of the metadatarecord (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 xlinkhref= into a corresponding GetRecords-command containing the URI from225 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 thatthe latest draft in chapter 226 might be too restrictive

So I see no other way than to leave it open Use of URI (similar to the one in 225) might be mostly in line with IR MD but for fulfilling technicalrequirements (CSW AP ISO ISO 19119) a GetRecordByID-command containing the fileIdentifier (similar to MetadataURL in WMS capabilities) mightbe useful if URI (225) cant 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


Angelo Quaglia schriebc) How will a client be able to resolve the id and retrieve the MD_DataIdentification element once the metadata is outside the catalogue it camefrom

In German registry the namespace (first part of URI in 225) or leading characters of the code part can be dedicated to a particular CSW Thereforethe resolving also gives the chance to access particular local catalogues


Pawel Soczewski wroteAs has already been stated the domain of OperatesOn must be the MD_DataIdentification object Michaels proposal is to leave the earlier draftwhere we implement it with a mandatory xlinkhref to the MD_DataIdentification object In detail its to use a URL to a metadata record in ISO19139(GetRecordById) and by referencing the DataIdentification object with an Xpointer In my opinion itll fulfil the requirements of OperatesOn that hasthe data type MD_DataIdentification but Ive some doubts doubts as to the CSW services According CSW ISO AP 10 the queryable propertyoperatesOn is mapping to theMD_MetadataidentificationInfoSV_ServiceIdentificationoperatesOnMD_DataIdentificationcitationCI_Citationidentifier Im afraid that most of

CSW server solutions cant 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 xlinkhref attribute of

MD_MetadataidentificationInfoSV_ServiceIdentificationoperatesOn object (it should be tested) Thats why a very practical use case theuser have found a dataset and is interested to find service that shares this dataset may be nonexecutable With this in mind Im convinced that theUnique Resource Identifier should be mandatory part of OperatesOn I would suggest a solution based on the results of the previous longdiscussion on the wiki - attributes uuidref and xlinkhref are obligatory - attribute xlinkhref 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 dereferenceableURL pointing to the metadata record of the resource that URL could be replace URL of GetRecordById (Peters proposal) - attribute uuidref hasthe value of the Unique Resource Identifier I know that using of uuidref attribute isnt commpilant with ISO 19118 but Im afraid hat there is noperfect 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 factthat a Spatial Dataset can have multiple Unique Resource Identifiers which would play the role of synonyms when a new identification scheme isintroduced

25 Jun 2018 1619

systemrichrich_filesrich_files000000378originalmail33png

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 therefor a dataset and decides to update also the uuid of the MD_DataIdentification elements what happens to already existing service metadata pointingto the datasets

In order to be aware of the synonyms a CSW would need to analyse the dataset metadata anyway

18 - 04 Nov 2015 0559 pm - Antonio Rotundo

Even seen the last post by Angelo (the multiplicity of the Unique Resource Identifier for a dataset could be gt1 on the base of IR) I agree with the latestproposal of Peter (15) ie to leave the choice open an URI (as in 225) or a URL to the metadata record through a GetRecordById request


It is of course fine to express a preference but open issues have to be addressed


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 xlinkhref (see SC11 in 12) - to reference the resource identifier of dataset (given as URI see 225) 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 beprovided 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 226 in the draft is conformant to the second option

I see no other way


Angelo Quaglia napisa(a)The use of xlinkhref is governed by specifications and standards upon which ISO 191115ISO 19119ISO 19139 are built The specification makeshttpidofMD_DataIdentificationgt absolutely equivalent to This is one of the two options allowed by ISO AP 100 If some of the existing CSWsolutions 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 xlinkhref is permitted by ISO19139 but I am of the opinion that in the CSW ISO AP doesnt specify the use of xlinkhrefespecially for operatesOn The Annex F descibes how implement a coupling between service instance and dataset instance and there isnt xlinkhref

25 Jun 2018 1719

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 whichwould 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 xlinkhref with reference to meatadata record (GetRecordByIdrequest 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 cant resolve the URL to a metadata record and serach a connected metadata file especiallyfrom other CSW Of course we can force them to implement it but later these new software versions will have to be implemented in manyadministrations what may involve considerable costs It also must be taken into consideration

22 - 06 Nov 2015 0937 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 Malmoumland 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 thegroup 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 theproposed 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 ownvalidation 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 betweensolutions (I am kidding)


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


The uuidref attribute can of course be used in addition to the mandatory xlinkhref with the aforementioned caveats

25 Jun 2018 1819

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 thecoupled resource

It is usually better to explicitly formulate any specific requirement

Marc could you please make explicit the requirement for France

25 Jun 2018 1919

httpsdbevgvatatgvbevdiscoverysrvdecsw202service=CSWamprequest=GetRecordByIdampversion=202ampoutputSchema=http3A2F2Fwwisotc211org2F20052FgmdampElementSetName=fullampid=6c316854-5453-4cf5-82cb-6586b2a2aa06gt

Instead of

Kataster Grafikdaten

hellip

Best regards

Angelo

Ing Angelo Quaglia

External Consultant




25 Jun 2018 219





Dear all





Best regards

Peter Kochmann

--



25 Jun 2018 319


D-50606 Cologne

Germany


Telefon +49 (0) 221 - 147 - 4460

Telefax +49 (0) 221 - 147 - 4874




Dear Pawel

An excellent recap


25 Jun 2018 419





() from AP ISO 100













25 Jun 2018 519

Best regards

Angelo

Ing Angelo Quaglia

External Consultant









25 Jun 2018 619


Regardspawel

Pozdrawiam

Pawe Soczewski


tel (22) 860 01 92

httpwwwgispartnerpl





Dear All


25 Jun 2018 719








Best regards

Angelo

25 Jun 2018 819

Ing Angelo Quaglia

External Consultant








Dear All



25 Jun 2018 919










mvhMichael------------------------------------------------------------------

Michael Oumlstling


25 Jun 2018 1019














25 Jun 2018 1119


5 - 02 Nov 2015 0306 pm - James Reid











8 - 03 Nov 2015 0505 pm - James Reid


25 Jun 2018 1219














[]

25 Jun 2018 1319











xlinkhref




25 Jun 2018 1419



uuidref
















25 Jun 2018 1519















25 Jun 2018 1619















I see no other way




25 Jun 2018 1719






Dear colleagues











25 Jun 2018 1819




25 Jun 2018 1919





Dear all





Best regards

Peter Kochmann

--



25 Jun 2018 319


D-50606 Cologne

Germany


Telefon +49 (0) 221 - 147 - 4460

Telefax +49 (0) 221 - 147 - 4874




Dear Pawel

An excellent recap


25 Jun 2018 419





() from AP ISO 100













25 Jun 2018 519

Best regards

Angelo

Ing Angelo Quaglia

External Consultant









25 Jun 2018 619


Regardspawel

Pozdrawiam

Pawe Soczewski


tel (22) 860 01 92

httpwwwgispartnerpl





Dear All


25 Jun 2018 719








Best regards

Angelo

25 Jun 2018 819

Ing Angelo Quaglia

External Consultant








Dear All



25 Jun 2018 919










mvhMichael------------------------------------------------------------------

Michael Oumlstling


25 Jun 2018 1019














25 Jun 2018 1119


5 - 02 Nov 2015 0306 pm - James Reid











8 - 03 Nov 2015 0505 pm - James Reid


25 Jun 2018 1219














[]

25 Jun 2018 1319











xlinkhref




25 Jun 2018 1419



uuidref
















25 Jun 2018 1519















25 Jun 2018 1619















I see no other way




25 Jun 2018 1719






Dear colleagues











25 Jun 2018 1819




25 Jun 2018 1919


D-50606 Cologne

Germany


Telefon +49 (0) 221 - 147 - 4460

Telefax +49 (0) 221 - 147 - 4874




Dear Pawel

An excellent recap


25 Jun 2018 419





() from AP ISO 100













25 Jun 2018 519

Best regards

Angelo

Ing Angelo Quaglia

External Consultant









25 Jun 2018 619


Regardspawel

Pozdrawiam

Pawe Soczewski


tel (22) 860 01 92

httpwwwgispartnerpl





Dear All


25 Jun 2018 719








Best regards

Angelo

25 Jun 2018 819

Ing Angelo Quaglia

External Consultant








Dear All



25 Jun 2018 919










mvhMichael------------------------------------------------------------------

Michael Oumlstling


25 Jun 2018 1019














25 Jun 2018 1119


5 - 02 Nov 2015 0306 pm - James Reid











8 - 03 Nov 2015 0505 pm - James Reid


25 Jun 2018 1219














[]

25 Jun 2018 1319











xlinkhref




25 Jun 2018 1419



uuidref
















25 Jun 2018 1519















25 Jun 2018 1619















I see no other way




25 Jun 2018 1719






Dear colleagues











25 Jun 2018 1819




25 Jun 2018 1919





() from AP ISO 100













25 Jun 2018 519

Best regards

Angelo

Ing Angelo Quaglia

External Consultant









25 Jun 2018 619


Regardspawel

Pozdrawiam

Pawe Soczewski


tel (22) 860 01 92

httpwwwgispartnerpl





Dear All


25 Jun 2018 719








Best regards

Angelo

25 Jun 2018 819

Ing Angelo Quaglia

External Consultant








Dear All



25 Jun 2018 919










mvhMichael------------------------------------------------------------------

Michael Oumlstling


25 Jun 2018 1019














25 Jun 2018 1119


5 - 02 Nov 2015 0306 pm - James Reid











8 - 03 Nov 2015 0505 pm - James Reid


25 Jun 2018 1219














[]

25 Jun 2018 1319











xlinkhref




25 Jun 2018 1419



uuidref
















25 Jun 2018 1519















25 Jun 2018 1619















I see no other way




25 Jun 2018 1719






Dear colleagues











25 Jun 2018 1819




25 Jun 2018 1919

Best regards

Angelo

Ing Angelo Quaglia

External Consultant









25 Jun 2018 619


Regardspawel

Pozdrawiam

Pawe Soczewski


tel (22) 860 01 92

httpwwwgispartnerpl





Dear All


25 Jun 2018 719








Best regards

Angelo

25 Jun 2018 819

Ing Angelo Quaglia

External Consultant








Dear All



25 Jun 2018 919










mvhMichael------------------------------------------------------------------

Michael Oumlstling


25 Jun 2018 1019














25 Jun 2018 1119


5 - 02 Nov 2015 0306 pm - James Reid











8 - 03 Nov 2015 0505 pm - James Reid


25 Jun 2018 1219














[]

25 Jun 2018 1319











xlinkhref




25 Jun 2018 1419



uuidref
















25 Jun 2018 1519















25 Jun 2018 1619















I see no other way




25 Jun 2018 1719






Dear colleagues











25 Jun 2018 1819




25 Jun 2018 1919


Regardspawel

Pozdrawiam

Pawe Soczewski


tel (22) 860 01 92

httpwwwgispartnerpl





Dear All


25 Jun 2018 719








Best regards

Angelo

25 Jun 2018 819

Ing Angelo Quaglia

External Consultant








Dear All



25 Jun 2018 919










mvhMichael------------------------------------------------------------------

Michael Oumlstling


25 Jun 2018 1019














25 Jun 2018 1119


5 - 02 Nov 2015 0306 pm - James Reid











8 - 03 Nov 2015 0505 pm - James Reid


25 Jun 2018 1219














[]

25 Jun 2018 1319











xlinkhref




25 Jun 2018 1419



uuidref
















25 Jun 2018 1519















25 Jun 2018 1619















I see no other way




25 Jun 2018 1719






Dear colleagues











25 Jun 2018 1819




25 Jun 2018 1919








Best regards

Angelo

25 Jun 2018 819

Ing Angelo Quaglia

External Consultant








Dear All



25 Jun 2018 919










mvhMichael------------------------------------------------------------------

Michael Oumlstling


25 Jun 2018 1019














25 Jun 2018 1119


5 - 02 Nov 2015 0306 pm - James Reid











8 - 03 Nov 2015 0505 pm - James Reid


25 Jun 2018 1219














[]

25 Jun 2018 1319











xlinkhref




25 Jun 2018 1419



uuidref
















25 Jun 2018 1519















25 Jun 2018 1619















I see no other way




25 Jun 2018 1719






Dear colleagues











25 Jun 2018 1819




25 Jun 2018 1919

Ing Angelo Quaglia

External Consultant








Dear All



25 Jun 2018 919










mvhMichael------------------------------------------------------------------

Michael Oumlstling


25 Jun 2018 1019














25 Jun 2018 1119


5 - 02 Nov 2015 0306 pm - James Reid











8 - 03 Nov 2015 0505 pm - James Reid


25 Jun 2018 1219














[]

25 Jun 2018 1319











xlinkhref




25 Jun 2018 1419



uuidref
















25 Jun 2018 1519















25 Jun 2018 1619















I see no other way




25 Jun 2018 1719






Dear colleagues











25 Jun 2018 1819




25 Jun 2018 1919










mvhMichael------------------------------------------------------------------

Michael Oumlstling


25 Jun 2018 1019














25 Jun 2018 1119


5 - 02 Nov 2015 0306 pm - James Reid











8 - 03 Nov 2015 0505 pm - James Reid


25 Jun 2018 1219














[]

25 Jun 2018 1319











xlinkhref




25 Jun 2018 1419



uuidref
















25 Jun 2018 1519















25 Jun 2018 1619















I see no other way




25 Jun 2018 1719






Dear colleagues











25 Jun 2018 1819




25 Jun 2018 1919














25 Jun 2018 1119


5 - 02 Nov 2015 0306 pm - James Reid











8 - 03 Nov 2015 0505 pm - James Reid


25 Jun 2018 1219














[]

25 Jun 2018 1319











xlinkhref




25 Jun 2018 1419



uuidref
















25 Jun 2018 1519















25 Jun 2018 1619















I see no other way




25 Jun 2018 1719






Dear colleagues











25 Jun 2018 1819




25 Jun 2018 1919


5 - 02 Nov 2015 0306 pm - James Reid











8 - 03 Nov 2015 0505 pm - James Reid


25 Jun 2018 1219














[]

25 Jun 2018 1319











xlinkhref




25 Jun 2018 1419



uuidref
















25 Jun 2018 1519















25 Jun 2018 1619















I see no other way




25 Jun 2018 1719






Dear colleagues











25 Jun 2018 1819




25 Jun 2018 1919














[]

25 Jun 2018 1319











xlinkhref




25 Jun 2018 1419



uuidref
















25 Jun 2018 1519















25 Jun 2018 1619















I see no other way




25 Jun 2018 1719






Dear colleagues











25 Jun 2018 1819




25 Jun 2018 1919











xlinkhref




25 Jun 2018 1419



uuidref
















25 Jun 2018 1519















25 Jun 2018 1619















I see no other way




25 Jun 2018 1719






Dear colleagues











25 Jun 2018 1819




25 Jun 2018 1919



uuidref
















25 Jun 2018 1519















25 Jun 2018 1619















I see no other way




25 Jun 2018 1719






Dear colleagues











25 Jun 2018 1819




25 Jun 2018 1919















25 Jun 2018 1619















I see no other way




25 Jun 2018 1719






Dear colleagues











25 Jun 2018 1819




25 Jun 2018 1919















I see no other way




25 Jun 2018 1719






Dear colleagues











25 Jun 2018 1819




25 Jun 2018 1919






Dear colleagues











25 Jun 2018 1819




25 Jun 2018 1919




25 Jun 2018 1919