Task #2221

MIWP-8 (M) Coupled resource

Added by Michael Östling almost 6 years ago. Updated over 5 years ago.

Status:ClosedStart date:17 Sep 2014
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Proposed change or action:

Description

This section has now been locked for editing and a draft version have been moved into the draft document.
See page:
https://ies-svn.jrc.ec.europa.eu/projects/metadata/wiki/DraftVersionsMIWP-8
Further discussions and comments should be done on the draft

WIKI: https://ies-svn.jrc.ec.europa.eu/projects/metadata/wiki/MIWP-8_(M)_Coupled_resources

The “data-service-coupling” part of the TGs need clarification urgently. The suggested solution is inconsistent and examples are confusing, making use of XML object IDs without any hints/explanation. Suggesting that both, URI or URLs to DataIdentification objects are allowed create a significant confusion for implementers and no justification is given. The task of this group is to provide more context for the purpose of the coupled resource and to provide justification for the coupled resource as well as an outline of the related use cases (as in other parts of the document).

Example_Flanders_OperatesOn.xml Magnifier - Example for Flanders (35.8 KB) Geraldine Nolf, 04 Dec 2014 02:58 pm

Investigations on coupled resources.docx (20.2 KB) Kristian Senkler, 16 Jan 2015 03:46 pm

MD_IR_and_ISO_20131029_Copy_for_editing_in_MIWP8_2.2.6Only.doc - Draft text for chapter 2.2.6 Coupled Resource (1.42 MB) Michael Östling, 03 Feb 2015 04:02 pm

MD_IR_and_ISO_20131029_Copy_for_editing_in_MIWP8_2.2.6Only-UK-edit-to-repharse-better.doc (1.34 MB) James Reid, 05 Feb 2015 11:28 am

Overview_DS_DSS_SRV_ObjCat.PNG (126 KB) Geraldine Nolf, 04 Mar 2015 04:10 pm

940

History

#1 Updated by Michael Östling over 5 years ago

  • Description updated (diff)

#2 Updated by Michael Östling over 5 years ago

 

The version 1.3 published 2013-11-06 of the Technical guidelines contains  updated examples (in section 2.2.6) of this element. (http://inspire.jrc.ec.europa.eu/documents/Metadata/MD_IR_and_ISO_20131029.pdf)

Version 1.2 published 2010-06-16    http://inspire.jrc.ec.europa.eu/documents/Metadata/INSPIRE_MD_IR_and_ISO_v1_2_20100616.pdf
uses
the reference by id as only example eg. <srv:operatesOn xlink:href="http://image2000.jrc.it#image2000_1_nl2_multi"/>

But I'm still not clear on the full definition which is similar in both versions

A unique resource identifier or locator (URL) of the MD_DataIdentification object.

When inspecting metadata in Inspire Geoportal it seems many records is just a plain GetRecordById to a CSW-catalogue services that returns a MD_Metadata object.
 

The example URL in version 1.3 of TG Metadata is:
http://vapxgeodev.jrc.ec.europa.eu/geonetwork/srv/eng/csw?SERVICE=
CSW&VERSION=2.0.2&REQUEST=GetRecordById&ID=f9ee6623-cf4c-11e1-9105-0017085a97ab
&OUTPUTSCHEMA=http://www.isotc211.org/2005/gmd
&ELEMENTSETNAME=full#lakes

Is the intention here that the #lakes in the end of URL  is an anchor to a MD_DataIdentification object ID="Lakes" within the metadatarecord with ID=f9ee6623-cf4c-11e1-9105-0017085a97ab ?

 

I think we also would need an working example how metadata could be registred using only "A unique resource identifier "  If our identifiers where persistant URLs then this should be easier.

But an operates on that uses  "A unique resource identifier"  that is using http:URL as identifier. Is that pointing to the resource itself  and/or the metadata record?

 

 


 

 

#3 Updated by Pawel Soczewski over 5 years ago

I propose two choices:


1) Resource identifier which is "URI dereferencing" according to the Linked Date idea. The Url should be resolvable as a metadata record. Below example of German SDI registry:
Resource Id
https://registry.gdi-de.org/id/de.bund.bkg/DEBKG00M00000100
{ namespace prefix } {namespace} { localid}
Metadata record
http://gdk.gdi-de.org/gdi-de/srv/eng/csw?service=CSW&version=2.0.2&request=GetRecordById&outputschema=csw:

2) Link to metadata record, request of GetRecordById or direct link to metadata file

#5 Updated by Martin Seiler over 5 years ago

I'd like to stress the importance of this issue once again. IMHO this is not only a metadata issues, but critical for the overall architecutre of INSPIRE, as this is the glue it relies on! So its important that this is carefully reviewed and improved.

#6 Updated by Martin Seiler over 5 years ago

Regarding the proposals in the wiki:

Regardless of whether encoded in the uuidref or xlink attribut, the identenifier to put here has to be the Uniquie Ressource Identifier and not the fileIdentifier of the metadata record itself!

While I am in favor of using the xlink here, this means essentially that the Unique Ressource Identifier (as provided in the metadata set describing the dataset itself) has to be a resovable URL. Putting GetRecordById requests here is possible, but then implies that the Ressource Identifier is a GetRecordById request itself. This has disadvantages (e.g. long identifiers, CSW URL might change over time, ...).

The identifier could also (and additionally) be placed in the uuidref attribute (not the fileIdentifier). The ISO 19139  schema allows any string here. It does not have to be a uuid.

#7 Updated by Martin Seiler over 5 years ago

Regarding the domain ("A unique resource identifier or locator (URL) of the
MD_DataIdentification object")

I propose to change this to "The unique resource identifier as provided in the metadata record describing the dataset (IR Part B 1.5)"

#8 Updated by Michael Östling over 5 years ago

It would be great if we could show a usecase that shows how the uuidref=<resourceidentifier) are used.

Wouldn't we need the uuidref to be a URI that is possible to dereference as Pawel mentions above or that  the uuidref is a persistant URL.

An other minor comment, when using the HREF to point out a metadatarecord we will normally get a MD_Metadata object in return if we have put files on a WAF.
But in the case of a GetRecordByIDRequest the MD_Metadata will be wrapped in a GetRecordByIDResponse obejct. So the datatypes for the two will differ.
 

 

 

#9 Updated by Martin Seiler over 5 years ago

Michael Östling schrieb:

It would be great if we could show a usecase that shows how the uuidref=<resourceidentifier) are used.  [...]

It might be a good idea to add use cases we target here (and/or explainations) as an introduction to the section 2.2.5 / 2.2.6 as currently done e.g. for section 2.8 or 2.9.

#10 Updated by Pawel Soczewski over 5 years ago

I agree with Martin.  Value of OperatesOn element should point metadata of relevant dataset. Ideally it would be dataset identyfier as a resovable URL but by this time it should allow an alternative value - GetRecordsById request.

According to the Martin's proposal, change the domain of Coupled Resource to "The unique resource identifier as provided in the metadata record describing the dataset (IR Part B 1.5)" and at "Comments" to add "In the case where the unique resource identifier is not a resovable URL should be provide a reference to the metadata record as link to GetRecordsById request".

#11 Updated by Martin Seiler over 5 years ago

Pawel Soczewski schrieb:

I agree with Martin.  Value of OperatesOn element should point metadata of relevant dataset. Ideally it would be dataset identyfier as a resovable URL but by this time it should allow an alternative value - GetRecordsById request. According to the Martin's proposal, change the domain of Coupled Resource to "The unique resource identifier as provided in the metadata record describing the dataset (IR Part B 1.5)" and at "Comments" to add "In the case where the unique resource identifier is not a resovable URL should be provide a reference to the metadata record as link to GetRecordsById request".

This would not be inline with the current CSW ISO AP, this would have to be stated and explained as well so avoid confusion.

#12 Updated by Ine de Visser over 5 years ago

I have some of questions on above discussions;

Can you clearify what not inline is with current CSW ISO AP? is it inline with the new ISO 19115?

If we need to use the GetRecordsById request, should that be a request to a record in the same CSW or another CSW? this is a problem by harvested metadata?

I suggest we do one stap back, to get the things clear;

  1. What are de definitions in the relevant standards, CSW ISO AP, ISO 19115,... and the IR,...
  2. Where should the resource locator point to based on the defenitions in the relevant standards, the dataset or the metadata of that dataset. 
  3. How can we link to that? XLink,UUIDref,...
  4. What is the locator, an URI(resolvable URL) or an UUID, is it applicable, ...
  5. ...

 

#13 Updated by Michael Östling over 5 years ago

I think we have some problems resolving the requirements of both ISO1915 and CSW ISO AP.

I have tried to inspect what's written and understand the consequences.
When studying the CSW ISO API I can see on page 37

A service that is associated with specific datasets or datasetcollections. Service metadata shall describe both the service and the geographic dataset, the latter being defined in accordance with ISO 19115.

CSW ISO AP mandates that metadata for the service (eg a view-service) should contain metadata for both the service and the dataset(s) (having one dataidentification object for each dataset). By this is then clearer to understand why TG Metadata includes the definition:

A unique resource identifier or locator (URL) of the
MD_DataIdentification object


As I see it this is not inline with Inspire TG that demands us to have a separate metadata records for each dataset. A dataset can also exist in mutiple services so including the dataset metadata with the service-metadata is not possible as i see it.

I suggest we go for the solution that is implemented in various membersstates and that is included on WIKI and that also are included as a complete XML-example using both uuidref and xlink:href.

 

 

 

 

 

#14 Updated by Martin Seiler over 5 years ago

Ine de Visser schrieb:

Can you clearify what not inline is with current CSW ISO AP?

The CSW ISO AP demands that operatesOn points to the Unique Ressorce Identifier. A GetRecordById however point to the Id of the metadata record itself (aka fileIdentifier).

I suggest we do one stap back, to get the things clear; What are de definitions in the relevant standards, CSW ISO AP, ISO 19115,... and the IR,... Where should the resource locator point to based on the defenitions in the relevant standards, the dataset or the metadata of that dataset.  How can we link to that? XLink,UUIDref,... What is the locator, an URI(resolvable URL) or an UUID, is it applicable, ... ...  

Good idea. Should be done in the wiki.

 

#15 Updated by Pawel Soczewski over 5 years ago

I've studied annex F of CSW ISO AP - Coupling services with datsets. In it we can see:

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

MD_DataIdentification.citation.CI_Citation.identifier.MD_Identifier.code

for data metadata and one of

 1) SV_ServiceIdentification.operatesOn@uuidref or
 2) SV_ServiceIdentification.operatesOn.MD_DataIdentification.citation.CI_Citation.identifier.MD_Identifier.code

for service metadata. If the values of those identifiers match, the linkage between the
service and the data metadata is properly described.

I understand, that #1 is for byReference and #2 is for inline. 
It is not clear to me whether
uuidref = MD_DataIdentification@uuid (or gmd:MD_Metadata@uuid)
or
uuidref = MD_DataIdentification.citation.CI_Citation.identifier.MD_Identifi
er.code?

If this is the second case, then it demands the construction of Unique Ressorce Identifier (?).

On page 49 of CSW ISO AP there is definition of queryable property OperatesOn:

OperatesOn Identifier of a dataset
tightly coupled with the
service instance.
Identifier MD_Metadata.identificationInfo.SV_Ser
viceIdentification.operatesOn.MD_DataI
dentification.citation.CI_Citation.identifi
er

I'll test how implement this queryable property CSW service (terraCatalog).

 

#16 Updated by Martin Seiler over 5 years ago

Pawel Soczewski schrieb:

I've studied annex F of CSW ISO AP - Coupling services with datsets.

Thanks for digging this out. Just want to point out that the Annex is labeled 'informative'. I.e. this should be seen as a 'a possible way to implement' or recommendation rather than a requirement by the standard.

In it we can see: It is recommended to support the linkage between services and data instances defining equality of: MD_DataIdentification.citation.CI_Citation.identifier.MD_Identifier.code for data metadata and one of  1) SV_ServiceIdentification.operatesOn@uuidref or  2) SV_ServiceIdentification.operatesOn.MD_DataIdentification.citation.CI_Citation.identifier.MD_Identifier.code for service metadata. If the values of those identifiers match, the linkage between the service and the data metadata is properly described. I understand, that #1 is for byReference and #2 is for inline.  It is not clear to me whether uuidref = MD_DataIdentification@uuid (or gmd:MD_Metadata@uuid) or uuidref = MD_DataIdentification.citation.CI_Citation.identifier.MD_Identifi er.code? If this is the second case, then it demands the construction of Unique Ressorce Identifier (?). On page 49 of CSW ISO AP there is definition of queryable property OperatesOn: OperatesOn Identifier of a dataset tightly coupled with the service instance. Identifier MD_Metadata.identificationInfo.SV_Ser viceIdentification.operatesOn.MD_DataI dentification.citation.CI_Citation.identifi er I'll test how implement this queryable property CSW service (terraCatalog).  

Three more considerations on this: 1. As far as I know the second version is not supported by the ISO 19139 schema. Which would be a problem as then we could not use those for validation anymore 2. uuidref in the related ISO 19139 has the value-domain 'string'. I.e. this can be a uuid, but also a URL (or any other text...) 3. As this annex is informative we could still agree to use xlink here without violating this AP.

 

#17 Updated by Pawel Soczewski over 5 years ago

Martin Seiler napisa?(a):

Three more considerations on this: 1. As far as I know the second version is not supported by the ISO 19139 schema. Which would be a problem as then we could not use those for validation anymore

I just checked, it is supported by the ISO 19139 schema but as written by Michael, inline is not compatible with INSPIRE TG.

#18 Updated by Martin Seiler over 5 years ago

Pawel Soczewski schrieb:

Martin Seiler napisa?(a): Three more considerations on this: 1. As far as I know the second version is not supported by the ISO 19139 schema. Which would be a problem as then we could not use those for validation anymore I just checked, it is supported by the ISO 19139 schema but as written by Michael, inline is not compatible with INSPIRE TG.

Ah, good. Could you point out the section of the schema-file?

#19 Updated by Pawel Soczewski over 5 years ago

<xs:complexType name="SV_ServiceIdentification_Type">
        <xs:complexContent>
            <xs:extension base="gmd:AbstractMD_Identification_Type">
                <xs:sequence>
                    <xs:element name="serviceType" type="gco:GenericName_PropertyType"/>
                    <xs:element name="serviceTypeVersion" type="gco:CharacterString_PropertyType" minOccurs="0" maxOccurs="unbounded"/>
                    <xs:element name="accessProperties" type="gmd:MD_StandardOrderProcess_PropertyType" minOccurs="0"/>
                    <xs:element name="restrictions" type="gmd:MD_Constraints_PropertyType" minOccurs="0"/>
                    <xs:element name="keywords" type="gmd:MD_Keywords_PropertyType" minOccurs="0" maxOccurs="unbounded"/>
                    <xs:element name="extent" type="gmd:EX_Extent_PropertyType" minOccurs="0" maxOccurs="unbounded"/>
                    <xs:element name="coupledResource" type="srv:SV_CoupledResource_PropertyType" minOccurs="0" maxOccurs="unbounded"/>
                    <xs:element name="couplingType" type="srv:SV_CouplingType_PropertyType"/>
                    <xs:element name="containsOperations" type="srv:SV_OperationMetadata_PropertyType" maxOccurs="unbounded"/>
                    <xs:element name="operatesOn" type="gmd:MD_DataIdentification_PropertyType" minOccurs="0" maxOccurs="unbounded"/>
                </xs:sequence>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>

#20 Updated by Pawel Soczewski over 5 years ago

Pawel Soczewski napisa?(a):

 I'll test how implement this queryable property CSW service (terraCatalog).  

I've tested terraCatalog. The queryable proporty operatesOn is implemented as MD_Metadata.identificationInfo.SV_Ser
viceIdentification@xlink:href

#21 Updated by Martin Seiler over 5 years ago

Pawel Soczewski schrieb:

Pawel Soczewski napisa?(a):  I'll test how implement this queryable property CSW service (terraCatalog).   I've tested terraCatalog. The queryable proporty operatesOn is implemented as MD_Metadata.identificationInfo.SV_Ser viceIdentification@xlink:href

Thanks for checking. It seems to be @uuidref in GeoNetwork (v 2.8)

#22 Updated by Ine de Visser over 5 years ago

In my opinion it should be conform the standards, the implementation of those standards should not be leading.

#23 Updated by Kristian Senkler over 5 years ago

Hi all, 

I have written some sections to summarize the problems using different approaches for coupling reosurces. The attached documented tries to identifier the shortcomings of each approach and, hopefully, provides some insight into possible conclusions.

It's far from perfect, so feel free to comment anything that is unclear.

P.S.: If this is not the right place in the Wiki to put such documents, please move it to a more suitable location

#24 Updated by Ine de Visser over 5 years ago

Thanx for this investigation. I have an other option;

use option 1 uuidref in combination with option 2 xlink:href

Pros;

  • in line with the OGC CSW AP ISO spec (uuidref)

  • best practice at the moment (xlink:href)

  • The reference to the dataset is directly given (uuidref)

  • self-contained (xlink:href)

Cons:

  • Not fully compliant with ISO 19118 semantics
  • Bound to conventions regarding stable URLs

#25 Updated by Martin Seiler over 5 years ago

From the wiki:

 

When checking in CSW ISO APi 2.0.2 how this value should be implemented
There are two possibilities where either the dataset is pointed out by reference

Note: This is a recommendation from the informative annex F. So providing the URI only in @xlink should be sufficient. It should just be mandatory that the URI provided in @xlink is dereferenceable. Having dereferenceable URIs here would satisfy both use cases, e.g. with a redirect to the metadata record.

#26 Updated by Martin Seiler over 5 years ago

From the wiki:

<srv:operatesOn xlink:href="[GetRecordById url ]" uuidref="[resourceIdentifier for  a dataset]">
What is the justification for xlink:href=[GetRecordById url]? A reference to a metadata record should be sufficient. This could be a GetRecordById or a static XML on a web server or a redirect to either of them.

#27 Updated by Martin Seiler over 5 years ago

From the wiki:

Use Case A:

You are a user and finds metadata for a service (WMS)
You then want to evaluate the service
and  read metadata for the datasets that this services works on.

This use case can be realized with the same approach as in UC B: Extract the URIs from the operatesOn elements and query the CSW for respective data sets.

 

#28 Updated by Michael Östling over 5 years ago

I have updated a DRAFT document after our last meeting and reading the document by Kristian S (excellent description of the case).
Just so we can push our discussions forward. There are as it looks like no perfect solution.
We have to do the best also handling the situation for all existing metadata (that is already now using and have been adviced to use xlink:href). '

I have tried to modify the text according to this.

In the attached doc only chapter 2.2.6 Coupled resource is modified.

I have modified the text to only have uuidref as mandatory element and giving recommendation to use xlink:href to point out the metadatarecord.


It is correct as you mention above Martin that if the resource identifier is dereferenceable then we should not not need the xlink:href.
But since we are not there (yet). I think its good to also recommend the xlink:href.

But we see here the importance of the task of working with persistant and dereferenceable identifiers 

#29 Updated by Michael Östling over 5 years ago

Martin,
Can you elaborate on this comment? I'm not sure I follow you here.

"Note: This is a recommendation from the informative annex F. So providing the URI only in @xlink should be sufficient. It should just be mandatory that the URI provided in @xlink is dereferenceable. Having dereferenceable URIs here would satisfy both use cases, e.g. with a redirect to the metadata record. "

 

Do you mean that a dereferenceable URI in @xlink would be enough and that no uuidref would be needed ?
Do you mean a URI where the resource identifier is included as an argument.
I think we must include the resource identifier in the OperatesOn some how,
since IR specifies the need for actually specifying the resource identifier.

Can you give an example of how you would write in case you could handle all your identifiers without limitations.
How would an dereferenceable  URI look line in OperatesOn

#30 Updated by Marc Leobet over 5 years ago

Dear colleagues,

after investigation, I bring back to you two answers to the questions asked by Michaël :

 
> Are there a queryable in their CSW for OperatesOn and ResourceIdentifier?
Yes, as indicated in the getCapabilities : http://www.geocatalogue.fr/api-public/inspire/servicesRest?version=2.0.2&service=CSW&REQUEST=GetCapabilities

> What are they mapped to ?
OperatesOn does not point toward xlinkhref but uuidref. We have the project to add this functionnality in our future CSW.
ResourceIdentifier points toward the resource ID of the dataset (MD_Identifier ou RS_Identifier).

 

#31 Updated by James Reid over 5 years ago

I have modified slightly Micahels draft text for 2.2.6 to better phrase things in English. I have left the existing logic the same.

#32 Updated by Michael Östling over 5 years ago

Martin Seiler wrote:

From the wiki: <srv:operatesOn xlink:href="[GetRecordById url ]" uuidref="[resourceIdentifier for a dataset]"> What is the justification for xlink:href=[GetRecordById url]? A reference to a metadata record should be sufficient. This could be a GetRecordById or a static XML on a web server or a redirect to either of them.

Yes correct, any URL to a XML could be ok.
Have though to discuss what class the URL shoudl point to:
- In case we call a GetRecordID we get a GetREcordBYID-response with MD_Metadata embedded
- In case we call a GetRecords we get a GetRecords response ? with MD_Metadata embedded
- In case point to a xml-file we would point directly to a MD_Metadata class

 

#33 Updated by Michael Östling over 5 years ago

Pawel Soczewski wrote:

Pawel Soczewski napisa?(a):  I'll test how implement this queryable property CSW service (terraCatalog).   I've tested terraCatalog. The queryable proporty operatesOn is implemented as MD_Metadata.identificationInfo.SV_Ser viceIdentification@xlink:href

I guess you mean MD_Metadata.identificationInfo.SV_ServiceIdentification.OperatesOn@xlink:href

#34 Updated by Kristian Senkler over 5 years ago

I'm still not convinced that using the GetRecordById approach is suitable in terms of the requirements of the IR. The IR clearly states to reference related documents using unique resource identifier(s). GetRecordById uses the identifier of the metadata document, which is a totally different thing.

I think it is sufficient to use uuidref (even though it is not fully ISO compliant) or, as an alternative, use xlink@href in combination with a GetRecords request that utilizes the resource identifier. Hence, the latter approach calls for setting the HTTP GET operation for a GetRecords as mandatory within INSPIRE. The CSW spec specifies HTTP GET being optional only.

#35 Updated by Michael Östling over 5 years ago

Som background info on CSW queryables:

In terraCatalog OperatesON is mapped against @xlink:href (but can be configured to use uuidref instead, or even both uuidref and xlink@href. )
In Geonetwork 2.8 and 2.10 it mapped against @uuidref (but can be configured to use both uuidref and xlink:href)
In Geonetwork 3.0 it mapped against both @xlink:href and @uuidref

Do we have any other catalogues we can get info on?
ESRI Geoportal ?
DEGREE ?
 

This is just to get some info on current practices.

#36 Updated by Kristian Senkler over 5 years ago

One word on terra.catalag: operatesOn it is mapped to xlink@href by default, but you can configure it to use uuidref instead, or even both uuidref and xlink@href. 

#37 Updated by Michael Östling over 5 years ago

Kristian Senkler wrote:

I'm still not convinced that using the GetRecordById approach is suitable in terms of the requirements of the IR. The IR clearly states to reference related documents using unique resource identifier(s). GetRecordById uses the identifier of the metadata document, which is a totally different thing. I think it is sufficient to use uuidref (even though it is not fully ISO compliant) or, as an alternative, use xlink@href in combination with a GetRecords request that utilizes the resource identifier. Hence, the latter approach calls for setting the HTTP GET operation for a GetRecords as mandatory within INSPIRE. The CSW spec specifies HTTP GET being optional only.

Ok, If we can change TG for discovery service then it should be fine for me.
But if we use uuidref then this identifier has to be an URL or anyhow an URI that be dereferenced, right ?
Otherwise the system can not find the resource.

So we should end up with uuidref as required and xlink:href to a getrecords request as recommended or should we either of them as requirement ?

We still have an issue to handle with getRecordsByID. That is the currently recommended solution in TG and that is I think what most countries have implemented.
To remove an existing recommendation needs some dicussions in MIG in think.

#38 Updated by Martin Seiler over 5 years ago

Kristian Senkler schrieb:

I'm still not convinced that using the GetRecordById approach is suitable in terms of the requirements of the IR. The IR clearly states to reference related documents using unique resource identifier(s). GetRecordById uses the identifier of the metadata document, which is a totally different thing. I think it is sufficient to use uuidref (even though it is not fully ISO compliant) or, as an alternative, use xlink@href in combination with a GetRecords request that utilizes the resource identifier. Hence, the latter approach calls for setting the HTTP GET operation for a GetRecords as mandatory within INSPIRE. The CSW spec specifies HTTP GET being optional only.

I agree. This would only be in line with the IR if the Unique Resource Identifier would be the full GetRecordById request itself.

#39 Updated by Martin Seiler over 5 years ago

Michael Östling schrieb:

But if we use uuidref then this identifier has to be an URL or anyhow an URI that be dereferenced, right ? Otherwise the system can not find the resource. So we should end up with uuidref as required and xlink:href to a getrecords request as recommended or should we either of them as requirement ? We still have an issue to handle with getRecordsByID. That is the currently recommended solution in TG and that is I think what most countries have implemented. To remove an existing recommendation needs some dicussions in MIG in think.

Well, the the described use cases can be accomplished simply with a second CSW request searching for datasets / services with Unique Resource Identifiers.

While it is useful and desirebale that the metadata sets can be directly accessed (through dereferenceable identifiers) I still don't see where the solid requirement in the context of INSPIRE is comming from.

#40 Updated by Pawel Soczewski over 5 years ago

Hi all, over the last few weeks, I was very busy but now I have carefully read the current discussion and I have the following conclusions.

From Kristian's document:

1.    Semantically, it is not correct to use the attribute @uuidref that way. As per ISO 19118, A.5.5.2, “[…] The “uuidref” attribute shall be used to refer to an object within the universe of an application domain. […]”. By example, this means that an elements defined as: 
<first id="i05" uuid="dce:F6A120B3"> … </first>
can be referenced elsewhere by a new element like this: 
<second uuidref="dce:F6A120B3"/>
Hence, the approach given above links a “uuidref” attribute with the element value of an identifier class, which is not correct.

In my opinion there isn't inconsistencies in "by reference" approach (SV_ServiceIdentification.operatesOn@uuidref) from annex F of CSW AP ISO.
According with ISO 19118 encoding of reference to dataset metadata record should be following:

<srv:SV_ServiceIdentification>
    <srv:operatesOn uuidref="abc:16"
</srv:SV_ServiceIdentification>
refer to
<gmd:MD_DataIdentification>
    <gmd:MD_Identifier uuid="abc:16">
        <gmd:code>
            <gco:CharacterString>PL.ZIPGUS.312.SU</gco:CharacterString>
        </gmd:code>
    </gmd:MD_Identifier>
</gmd:MD_DataIdentification>

According with ISO 19118 if you want to refer to objects that are located in other datasets use attribute "uriref" (URI). 
In ISO 19139 the implementation of the above issues is slightly modified from that in ISO 19118 in order to be more consistent with ISO 19136. The gco:ObjectReference attributeGroup contains a reference to the xlink:simpleLink attributeGroup, plus the definition of an XML attribute named uuidref of type xs:string. According ISO 19136 the xlink:href attribute is used to build reference to feature.


Using the xlink:href to encoding references is the best practice at the moment.

#41 Updated by Pawel Soczewski over 5 years ago

My proposal is only to use xlink:href approach using a unique resource identifier. The unique resource identifier should be encoded URI (URL). Dereferenceable  URI is desirable but not required.

Pros: 
•    in line with the OGC CSW AP ISO spec (byReference)
•    compliant with ISO 19118 and ISO 19139 semantic (using xlink:href to refer to objects)
•    compliant with INSPIRE IR (unique resource identifier)
•    best practice to encoding references

Cons: 
•    Bound to conventions regarding stable URLs
•    not in line with best practice at the moment (GetRecordById)

•    not all unique resource identifiers are compilant with URI(URL) schema

#42 Updated by Geraldine Nolf over 5 years ago

For your information:

In the branch of our GeoNetwork node (Flanders - Belgium) we use too both uuidref (to the resource identifier of the dataset) and xlink:href (to the metadata file, via the CSW Request GetRecordByID and the metadata fileIdentifier).

Example:

- service itself: https://metadata.geopunt.be/zoekdienst/apps/tabsearch/?uuid=093b6255-04e0-69c0-0b24-6fab-6a7a-3ebf-fbc26313

- operatesOn: f.e.

<srv:operatesOn uuidref="0574c388-20a4-4e1a-9e8d-fca40001c917" xlink:href="http://metadata.agiv.be/zoekdienst/srv/en/csw?Service=CSW&amp;version=2.0.2&amp;Request=GetRecordById&amp;outputschema=http://www.isotc211.org/2005/gmd&amp;elementSetName=full&amp;id=8ac7a847-c322-4a60-ac77-42c3064d1392"/>
<srv:operatesOn uuidref="0574c388-20a4-4e1a-9e8d-fca40001c917" xlink:href="http://metadata.agiv.be/zoekdienst/srv/en/csw?Service=CSW&amp;version=2.0.2&amp;Request=GetRecordById&amp;outputschema=http://www.isotc211.org/2005/gmd&amp;elementSetName=full&amp;id=8ac7a847-c322-4a60-ac77-42c3064d1392"/>
 

Once I had made a slide in PowerPoint to help our data providers. I'll upload it hereby.

Geraldine

#43 Updated by Pawel Soczewski over 5 years ago

I've read carefully the mail from Michel and I thought about the issue again. My proposal from post#41 covers the path d. In my opinion it'll be ideally, unique resource identifier should be dereferenceable URL (in HTTP schema). However, if we would have imposed such a requirement would fall into this scenario d. There will not always be affect only the metadata eg. in Poland resource id (not compliant with URL scheme) is a part of external object id and format and structure of identifier are regulated by law. If they change resource id, should change object id and this is inconsistent with the article 9 of CR "The external object identifier for the unique identification of spatial objects shall not be changed during the life-cycle of a spatial object."

That's why most appropriate proposal from post #21 will be (path b) with two options:
option 1
uuidref - unique resource id
xlink:href - GetRecordById

option 2
if resource id is dereferenceable URL
xlink:href - unique resource id

Using the GetRecords operation may cause additional costs for the MS eg. in Poland is popular terraCatalog and it don't support this operation by GET binding.

#44 Updated by Martin Seiler over 5 years ago

Pawel Soczewski schrieb:

I've read carefully the mail from Michel and I thought about the issue again. My proposal from post#41 covers the path d. In my opinion it'll be ideally, unique resource identifier should be dereferenceable URL (in HTTP schema). However, if we would have imposed such a requirement would fall into this scenario d. There will not always be affect only the metadata eg. in Poland resource id (not compliant with URL scheme) is a part of external object id and format and structure of identifier are regulated by law. If they change resource id, should change object id and this is inconsistent with the article 9 of CR "The external object identifier for the unique identification of spatial objects shall not be changed during the life-cycle of a spatial object." That's why most appropriate proposal from post #21 will be (path b) with two options: option 1 uuidref - unique resource id xlink:href - GetRecordById option 2 if resource id is dereferenceable URL xlink:href - unique resource id Using the GetRecords operation may cause additional costs for the MS eg. in Poland is popular terraCatalog and it don't support this operation by GET binding.

 

Which email are you reffering to? @Michael: please make sure to keep the technical discussion on issues here. Its not traceable otherwise...

#45 Updated by Martin Seiler over 5 years ago

I still don't see consensus here. In the suggested update acutally both, uuidref and xlink, point to the fileIdentifier. However, we need a reference to the Resource Identifier here.

#46 Updated by Pawel Soczewski over 5 years ago

Martin Seiler napisa?(a):

Pawel Soczewski schrieb: I've read carefully the mail from Michel and I thought about the issue again. My proposal from post#41 covers the path d. In my opinion it'll be ideally, unique resource identifier should be dereferenceable URL (in HTTP schema). However, if we would have imposed such a requirement would fall into this scenario d. There will not always be affect only the metadata eg. in Poland resource id (not compliant with URL scheme) is a part of external object id and format and structure of identifier are regulated by law. If they change resource id, should change object id and this is inconsistent with the article 9 of CR "The external object identifier for the unique identification of spatial objects shall not be changed during the life-cycle of a spatial object." That's why most appropriate proposal from post #21 will be (path b) with two options: option 1 uuidref - unique resource id xlink:href - GetRecordById option 2 if resource id is dereferenceable URL xlink:href - unique resource id Using the GetRecords operation may cause additional costs for the MS eg. in Poland is popular terraCatalog and it don't support this operation by GET binding.   Which email are you reffering to? @Michael: please make sure to keep the technical discussion on issues here. Its not traceable otherwise...

It was e-mail from 04-03-2015 to all member of group.

#47 Updated by Martin Seiler over 5 years ago

Pawel Soczewski schrieb:

It was e-mail from 04-03-2015 to all member of group.

Thanks!

#48 Updated by Martin Seiler over 5 years ago

The proposed solution (uuidref=fileIdentifier is mandatory, xlink=GetRecordById optional) is - in my opinion -  not fullfilling  the requirements of the Metadata IR (1205/2008) as they (both) reference the fileIdentifier of the metadata record itself and not the resource. B 1.6 demands a URI here:

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

And it goes on with even repeating the requirements of the (basic) URI design from B 1.5:

The value domain of this metadata element is a mandatory character string code, generally assigned by the data
owner, and a character string namespace uniquely identifying the context of the identifier code (for example, the
data owner).

In the MIWP-8 calls we learned that the OGC ISO AP is not in all parts very well written or even inconsistent. However, while we should follow the OGC documents as closely as possible here, its is essential that we come up with TG requirements/recommendations that are fullfilling the (legally binding) IRs. And actually INSPIREs' requirements go beyond OGC and hence the OGC paper weren't adapted but taken as a starting point in drafting the TGs (just think of the extended capabilities of the services).

So again I call for a solution that references the resource URI (B 1.5), encoded in MD_Identifier here.

 

#49 Updated by Michael Östling over 5 years ago

  • Description updated (diff)
  • Status changed from Submitted to Closed

Also available in: Atom PDF