MIWP-8 (M) Coupled resources

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

Ticket: https://ies-svn.jrc.ec.europa.eu/issues/2221

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

 

Members

Ine de Visser
Lars-Inge Arnevik
Martin Seiler
Pawel Soczewski
Kristian Senkler
James Reid
André Schneider
Michael Östling (Group Leader)

Issue analysis

What problems causes current solution ?

INSPIRE technical guidance currently states that coupled resource shall be implemented by reference using XLinking. The value of the XLink attribute, as shown in the INSPIRE technical guidance, is the value of the metadata item Unique Resource Identifier (not to be confused with the W3C URI).

The TG demand the reference to the identifier of an "MD_DataIdentification object" (see 'domain'). Not clear why this is necessary.

According to the IR section 1.6 this reference here is to be given using a namespace/code (i.e. 1.5 Unique resource identifier!).

According to the OGC CSW ISO AP the queryable OperatesOn is mapped to MD_Metadata.identificationInfo.SV_ServiceIdentification.operatesOn.MD_DataIdentification.citation.CI_Citation.identifier

 

 

 

What can be a solution on current problem ?

UK - the UK guidance on encoding is as follows:

The guidance for UK GEMINI2 (the UK geospatial metadata standard) is different. The value of the attribute is always a URL that allows access to an unambiguous metadata instance, which may be: an OGC CS-W GetRecordById request:

 

<gmd:MD_Metadata>
...
<gmd:identificationInfo>
<srv:SV_ServiceIdentification>
...
<srv:operatesOn xlink:href="http://ogcdev.bgs.ac.uk/geonetwork/srv/en/csw?SERVICE=CSW&amp;REQUEST=GetRecordById&amp;ID=9df8df52-d788-37a8-e044-0003ba9b0d98&amp;elementSetName=full&amp;OutputSchema=http://www.isotc211.org/2005/gmd"/>
</srv:SV_ServiceIdentification>
</gmd:identificationInfo>
...
</gmd:MD_Metadata>

OR an address of a metadata instance in a WAF:

<gmd:MD_Metadata>
...
    <gmd:identificationInfo>
        <srv:SV_ServiceIdentification>
        ...
            <srv:operatesOn xlink:href="http://mywaf.com/metadata/dataset.xml"/>
        </srv:SV_ServiceIdentification>
    </gmd:identificationInfo>
...
</gmd:MD_Metadata>

 

 

The obligation on coupled resource is conditional: it is mandatory (in INSPIRE metadata regulations and hence UK GEMINI2) if a linkage to the datasets on which the service operates is available. This is always the case for view services so if the service metadata is about a view service, coupled resource is effectively mandatory. Other types of service, such as transformation, may not be coupled to a data resource so the constraint on the element is not enforced by validation (i.e. XSD schema or Schematron). Implementers may wish to declare a coupled resource for other non-view service types and in these cases the coupled resource will not necessarily be a dataset.

In the Netherlands the relation is only made in the service metadata element coupled resource and is made to the data itself and its metadata.

The attribut uuidref points to the identifier of the dataset and the parameter id in the GetRecordById request in the xlink points to the file identifier of the dataset metadata

In XML;

<srv:operatesOn uuidref="b4c63e7c-b73c-451a-8071-dbc9f28f0148" xlink:href= "http://nationaalgeoregister.nl/geonetwork/srv/en/csw?Service=CSW&
Request=GetRecordById&Version=2.0.2&
id=c7d8d77b-8c47-4309-8c589b12b086407f&
outputSchema=http://www.isotc211.org/2005/gmd&elementSetName=full"/>

Use case and background for the OperatesOn element

This section elaborates some more on the UseCase for this.

Two main usecases are identified. 
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.

B
From the other direction a user have found a dataset and is interested to find service(s) (WMS)
that vizualises this dataset.
The user extracts the resourceIdentifier for the dataset.
The user should then be able to use the resourceIdentifier for the dataset and query the catalogservice
for all services that operates on this dataset (where the operatesOn=<ResourceIdentifier>)

To solve the above two usecases we need two sources of information in the OperatesOn element
For A we need the OperatesOn to point to the URL for metadata .
For B we need the OperatesOn to point to the resourceIdentifier.

This is normally implemented by using the following for each dataset the services operates on.

<srv:operatesOn xlink:href="[GetRecordById url ]" uuidref="[resourceIdentifier for  a dataset]">

xlink:href points to a GetRecordById request in a catalogueserver (CSW).
uuidref has the value of the resourceIdentifer.

 

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

SV_ServiceIdentification.operatesOn@uuidref

or the metadata for the dataset are included by value inside the service-metadata record

SV_ServiceIdentification.operatesOn.MD_DataIdentification.citation.CI_Citation.identifier.MD_Identifier.code

Inspire has a requirement that the dataset should be pointed out by reference (SC.12 in TG metadata.)
Which is better if a dataset are operated by more than one service and that we want to have a separate MD_Metadata record for each dataset.

The default implementation of Geonetwork CSW is mapping the querable parameter OperatesOn to the element SV_ServiceIdentification.operatesOn@uuidref

The minimum requirement for Inspire should indicate that only

<srv:operatesOn uuidref="[resourceIdentifier for  a dataset]">

is needed.


But if using only the uuidref pointing out the  resourceidentifiers for the underlying dataset, there are not a direct way (liek the GetRecordByID-request)  to get metadata for resource.
One solution is to query the catalog with a GetRecords-request  using the resourceIdentifier which is a additional queryable property in CSW ISO AP.
In that way the metadata for each dataset the service operates on can be accessed using only the resourceIdentifier

If instead both GetRecordByID url and the resourceIdentifier is stored then direct access to both the dataset metadata and access through CSW can be supported.

 

So to summarize

<srv:operatesOn uuidref="[resourceIdentifier for  a dataset]">

is probably enough to fulfill the IR
 

<srv:operatesOn xlink:href="[GetRecordById url ]" uuidref="[resourceIdentifier for  a dataset]">

also makes access to dataset metadata easier.

 

 

How does it relate to IR ?

The UK approach  follows INSPIRE technical guidance for view services (see page 22 Implementation Requirement 14).

How will the solution affect existing tools ?

UK - no change

Do all CSW implementation map the operatesOn queryable to the xlink-attribute of the ISO 19139 file?

How will the solution affect existing metadata ?

 

What other issues in MIWG-8 is related to this change ?

This is related to:

https://ies-svn.jrc.ec.europa.eu/projects/metadata/wiki/MIWP-8_(L)_Unique_Resource_Identifier

What other groups within MIG-related workgroups could be linked to this issue ?