Task #2533

Coupled Resourses

Added by Pawel Soczewski over 4 years ago. Updated over 4 years ago.

Status:NewStart date:02 Nov 2015
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
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 Updated by Pawel Soczewski over 4 years ago

 

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 19119 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 19115.

 

At the same time, we need to keep srv:operatesOn@xlink:href mandatory in order to honour XML, ISO 19115 and ISO 19119 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:

 

The sentence “shall be instantiated by reference” means :

 

<srv:operatesOn xlink:href="http://sd.bev.gv.at/at.gv.bev.discovery/srv/de/csw202?service=CSW&amp;request=GetRecordById&amp;version=2.0.2&amp;outputSchema=http%3A%2F%2Fwww.isotc211.org%2F2005%2Fgmd&amp;ElementSetName=full&amp;id=6c316854-5453-4cf5-82cb-6586b2a2aa06"/>

 

Instead of:

 

<srv:operatesOn>

<gmd:MD_DataIdentification>

<gmd:citation>

  <gmd:CI_Citation>

<gmd:title>

<gco:CharacterString>Kataster Grafikdaten</gco:CharacterString>

</gmd:title>

<gmd:date>

 

 

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, 2749.
I-21027 Ispra (VA)
Italy

Tel: +39 347 78 88 492
Fax: +39 0332 78 6325
e-mail: mailto:angelo.quaglia@ext.jrc.ec.europa.eu

URL: http://ies.jrc.ec.europa.eu/SDI/sdi-about-us/staff-profiles/angelo-quaglia.html

 

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 [mailto:peter.kochmann@bezreg-koeln.nrw.de]
Sent: 29 October 2015 11:32
To: psoczewski@gispartner.pl; alejandro@geograma.com; freddy.fierens@jrc.ec.europa.eu; robert.tomas@jrc.ec.europa.eu; 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 19119 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

Dezernat 74 - Geodatenzentrum, Geodateninfrastruktur

D-50606 Cologne

Germany

 

Dienstgebäude: Muffendorfer Str. 19-21, 53177 Bonn

Telefon: +49 (0) 221 - 147 - 4460

Telefax: +49 (0) 221 - 147 - 4874

mailto:peter.kochmann@bezreg-koeln.nrw.de

http://www.bezreg-koeln.nrw.de

 

 

 

 

 

Von: Angelo Quaglia [mailto:angelo.quaglia@ext.jrc.ec.europa.eu]
Gesendet: Dienstag, 27. Oktober 2015 17: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

 

In any case, if SV_ServiceIdentification.operatesOn@xlink:href 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 19118 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

 

 

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, 2749.
I-21027 Ispra (VA)
Italy

Tel: +39 347 78 88 492
Fax: +39 0332 78 6325
e-mail: mailto:angelo.quaglia@ext.jrc.ec.europa.eu

URL: http://ies.jrc.ec.europa.eu/SDI/sdi-about-us/staff-profiles/angelo-quaglia.html

 

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 [mailto:psoczewski@gispartner.pl]
Sent: 27 October 2015 15:57
To: Angelo Quaglia; '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
Subject: Re: Coupled Resourses - again

 

Dear All,
According to ISO 19119 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 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/7
00-236 Warszawa                                                                                                                      

tel. (22) 860 01 92

http://www.gispartner.pl

 

GISPartner  Sp. z o.o.  51-162 Wroc?aw, ul. D?ugosza 60, NIP: 898-20-27-647,
REGON: 932942367, KRS nr 0000173717 Wydzia? VI KRS, Wroc?aw                                                                         
Kapita? zak?adowy 50 000 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 e-mail is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this e-mail 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 e-mail in error, please notify us by telephone or by electronic mail immediately and please delete all copies of this e-mail.

 

W dniu 2015-10-26 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.

 

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

 

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, 2749.
I-21027 Ispra (VA)
Italy

Tel: +39 347 78 88 492
Fax: +39 0332 78 6325
e-mail: mailto:angelo.quaglia@ext.jrc.ec.europa.eu

URL: http://ies.jrc.ec.europa.eu/SDI/sdi-about-us/staff-profiles/angelo-quaglia.html

 

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.

 

 

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.

 

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:        070-279 19 76
ePost:    michael.ostling@metagis.se
SKYPE
:   MichaelOstling
www:     http://www.metagis.se
Adress:   Britsarvsvägen 28a, 791 36 FALUN, Sweden
Org Nr:   556638-7170

 

 

 

#2 Updated by Pawel Soczewski over 4 years ago

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 19118 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 Updated by Peter Kochmann over 4 years ago

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 Updated by Angelo Quaglia over 4 years ago

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 1.0.0

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 should define the Application Domain inside which the value contained in uuidref is unique

 

 

 

#5 Updated by James Reid over 4 years ago

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 Updated by Marie Lambois over 4 years ago

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 Updated by Angelo Quaglia over 4 years ago

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 Updated by James Reid over 4 years ago

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...

#9 Updated by Angelo Quaglia over 4 years ago

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 Updated by Marie Lambois over 4 years ago

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 (http://sourceforge.net/p/catmdedit/feature-requests/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 Updated by Pawel Soczewski over 4 years ago

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:

<gmd:identificationInfo>
        <gmd:MD_DataIdentification uuid="de305d54-75b4-431b-adb2-eb6b9e546014">

        [...]

</gmd:MD_DataIdentification>


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

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 Updated by Peter Kochmann over 4 years ago

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 Updated by Angelo Quaglia over 4 years ago

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: <gmd:identificationInfo>         <gmd:MD_DataIdentification uuid="de305d54-75b4-431b-adb2-eb6b9e546014">         [...] </gmd:MD_DataIdentification> Moreover, according standards it should be the universally unique identifier (UUID) form. For example: de305d54-75b4-431b-adb2-eb6b9e546014. 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 191115/ISO 19119/ISO 19139 are built.

The specification makes <srv:operatesOn xlink:href="http://...#idofMD_DataIdentification"/>

absolutely equivalent to:

<srv:operatesOn>

<gmd:MD_DataIdentification>

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

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 19115-1

 

 

#14 Updated by Angelo Quaglia over 4 years ago

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 Updated by Peter Kochmann over 4 years ago

Angelo Quaglia schrieb:

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.        

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="<path-to-registry>/<URI-from-2.2.5>" into a corresponding GetRecords-command containing the URI from 2.2.5 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 2.2.6 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 Updated by Peter Kochmann over 4 years ago

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 Updated by Angelo Quaglia over 4 years ago

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 19118 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:

 

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 Updated by Antonio Rotundo over 4 years ago

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 Updated by Angelo Quaglia over 4 years ago

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

#20 Updated by Antonio Rotundo over 4 years ago

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 2.2.6 in the draft is conformant to the second option.

I see no other way.

#21 Updated by Pawel Soczewski over 4 years ago

Angelo Quaglia napisa?(a):

The use of xlink:href is governed by specifications and standards upon which ISO 191115/ISO 19119/ISO 19139 are built. The specification makes <srv:operatesOn xlink:href="http://...#idofMD_DataIdentification"/> absolutely equivalent to: <srv:operatesOn> <gmd:MD_DataIdentification> This is one of the two options allowed by ISO AP 1.0.0 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. 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 Updated by Marc Leobet over 4 years ago

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 Updated by Angelo Quaglia over 4 years ago

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 Updated by Angelo Quaglia over 4 years ago

The uuidref attribute can of course be used in addition to the mandatory xlink:href, with the aforementioned caveats.

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 requirement.

@Marc, could you please make explicit the requirement for France?

Also available in: Atom PDF