Part B - Remapping of Extended Capabilities - About Metadata Point of Contact

AntoRot commented 2 years ago

As some information about the network service will be moved to the data set metadata with the simplification approach, then it is reasonable to assume that the metadata point of contact for the service is the one provided in the data set metadata.

MarieLambois commented 2 years ago

Yes, in general metadata about metadata should be the one from the dataset metadata.

jescriu commented 2 years ago

Dear @AntoRot,

Thank you for your proposal.

Just a question. When you write 'is the one provided in the data set metadata' you mean the metadata element:

'MD_Metadata > contact', or;
'MD_Metadata > identificationInfo > MD_DataIdentification > pointOfContact'.

Can you confirm?

heidivanparys commented 2 years ago

As some information about the network service will be moved to the data set metadata with the simplification approach, then it is reasonable to assume that the metadata point of contact for the service is the one provided in the data set metadata.

I would actually expect that a common use case is that the operation of the service has been delegated to a third party, implying

that the metadata point of contact of the service is the same as the responsible party for the service
that the metadata point of contact of the service is not the same as the metadata point of contact of the dataset

This is also what I meant with my suggestion of last meeting:

Metadata Point of contact: @heidivanparys suggested that this element should be probably discarded, because if there is no external ISO 19139 service metadada then the metadata you have are just the information provided in the Capabilities document of the service. Therefore, in this case the point of contact would be the same as the service provider. This should be taken into account when searching for the suitable standard elements from the Capabilities document to be mapped to to the Metadata Point of contact.

For an example, see the Danish Cadastral Parcels dataset and associated services on https://inspire-geoportal.ec.europa.eu/download_details.html?view=downloadDetails&resourceId=%2FINSPIRE-6e8353b4-de80-11e7-a188-52540023a883_20210925-085902%2Fservices%2F1%2FPullResults%2F221-240%2Fdatasets%2F14&expandedSection=metadata

The Capabilities of the WMS:

  <Service>
    <Name>WMS</Name>
    <Title>Cadastral Parcels</Title>
    <Abstract>Cadastral Parcels INSPIRE View Service</Abstract>
    <KeywordList>
      <Keyword>view</Keyword>
      <Keyword>infoMapAccessService</Keyword>
      <Keyword>Cadastral Parcels</Keyword>
    </KeywordList>
    <OnlineResource xlink:href="https://api.dataforsyningen.dk/cp_inspire?ignoreillegallayers=TRUE&amp;transparent=TRUE&amp;" xlink:type="simple"/>
    <ContactInformation>
      <ContactPersonPrimary>
        <ContactPerson/>
        <ContactOrganization>The Danish Agency for Data Supply and Efficiency</ContactOrganization>
      </ContactPersonPrimary>
      <ContactPosition/>
      <ContactAddress>
        <AddressType>postal</AddressType>
        <Address>Rentemestervej 8</Address>
        <City>København NV</City>
        <StateOrProvince/>
        <PostCode>2400</PostCode>
        <Country>Denmark</Country>
      </ContactAddress>
      <ContactVoiceTelephone>+45 7876 8792</ContactVoiceTelephone>
      <ContactElectronicMailAddress>support@sdfe.dk</ContactElectronicMailAddress>
    </ContactInformation>
    <Fees>Contact The Danish Agency for Data Supply and Efficiency</Fees>
    <AccessConstraints>Requires username on Kortforsyningen</AccessConstraints>
  </Service>

So I would propose that for WMSs, /WMS_Capabilities/Service/ContactInformation/ContactPersonPrimary/ContactOrganization and /WMS_Capabilities/Service/ContactInformation/ContactElectronicMailAddress together are both metadata point of contact as well as responsible party for the service, as it will be the responsible party that fills these things out, and therefore is the metadata point of contact as well. Something similar would apply for WFSs (the scheme is a bit different, I would have to look up the exact paths).

jescriu commented 2 years ago

The approach proposed by @heidivanparys looks like quite sensible to me, especially in case of decentralized SDI scenarios. Pointing directly at the details of the service provider included in the Capabilities Document of the service seems a good idea. Look forward to completing the proposal for the WFS case.

@AntoRot and @MarieLambois, do you agree with this approach?

MarieLambois commented 2 years ago

Yes. To be honest I think that both the solution of @AntoRot and @heidivanparys make sense. At the end, in any cases the user has what he needs in terms of person to contact so any solution is OK for me.

idevisser commented 2 years ago

@heidivanparys proposal is best suited to the NL situation

heidivanparys commented 2 years ago

For WMS 1.3 (XML schema):

Metadata Point of Contact - organisation name: WMS_Capabilities/Service/ContactInformation/ContactPersonPrimary/ContactOrganization
Metadata Point of Contact - e-mail: WMS_Capabilities/Service/ContactInformation/ContactElectronicMailAddress

  <ContactInformation>
    <ContactPersonPrimary>
      <ContactOrganization>organisation name</ContactOrganization>
    </ContactPersonPrimary>
    <ContactElectronicMailAddress>contact@myorg.eu</ContactElectronicMailAddress>
  </ContactInformation>

For WFS 2.0, that uses the OWS 1.1 schemas (see also http://docs.opengeospatial.org/is/09-025r2/09-025r2.html#23):

Metadata Point of Contact - organisation name: WFS_Capabilities/ows:ServiceProvider/ows:ProviderName
Metadata Point of Contact - e-mail: WFS_Capabilities/ows:ServiceProvider/ows:ServiceContact/ows:ContactInfo/ows:Address/ows:ElectronicMailAddress

<ows:ServiceProvider>
    <ows:ProviderName>organisation name</ows:ProviderName>
    <ows:ServiceContact>
        <ows:ContactInfo>
            <ows:Address>
                <ows:ElectronicMailAddress>contact@myorg.eu</ows:ElectronicMailAddress>
            </ows:Address>
        </ows:ContactInfo>
    </ows:ServiceContact>
</ows:ServiceProvider>

AntoRot commented 2 years ago

Dear @jescriu,

About your question:

Just a question. When you write 'is the one provided in the data set metadata' you mean the metadata element:
* 'MD_Metadata > contact', or;

* 'MD_Metadata > identificationInfo > MD_DataIdentification > pointOfContact'.
Can you confirm?

as we are discussing about metadata point of contact, I was referring to MD_Metadata > contact'.

AntoRot commented 2 years ago

About @heidivanparys proposal, I hadn't considered the service provider (in the GetCapabilities document) as that element is already mapped to the responsible organisation (see table at page 67 in INSPIRE NS - Download Service TG and table at page 21 in INSPIRE NS - View Service TG).

Furthermore, as some service metadata elements are moved to the data set metadata record, assuming that the metadata point of contact for the service is the same of the data set makes more sense to me (also in order to have specific elements to document both parties - responsible organisation and metadata point of contact - in case they are not the same, if a such use case is valid).

Nevertheless, in order to reach a consensus, I agree with @MarieLambois that both solutions could be OK.

heidivanparys commented 2 years ago

About @heidivanparys proposal, I hadn't considered the service provider (in the GetCapabilities document) as that element is already mapped to the responsible organisation (see table at page 67 in INSPIRE NS - Download Service TG and table at page 21 in INSPIRE NS - View Service TG).

I am aware of that, that those elements are already mapped to the responsible organisation. My reasoning is that the role as responsible organisation and as metadata point of contact would be filled by the same organisation – even the same person – in the case where the only metadata of the service is in the GetCapabilities (at least in the use cases I know of)

Furthermore, as some service metadata elements are moved to the data set metadata record, assuming that the metadata point of contact for the service is the same of the data set makes more sense to me (also in order to have specific elements to document both parties - responsible organisation and metadata point of contact - in case they are not the same, if a such use case is valid).

I agree that then there are specific elements to document both (different) service responsible organisation and service metadata point of contact. But the downside would be that it would not be possible to distinguish between the dataset metadata point of contact and the service metadata point of contact.

Nevertheless, in order to reach a consensus, I agree with @MarieLambois that both solutions could be OK.

Perhaps it is also important to highlight for the MIG-T that the mapping only affects the code behind the INSPIRE Geoportal. It does not affect the information that the service provider has to fill out in the GetCapabilities and the data provider in the national geoportal.

jescriu commented 2 years ago

Dear @jescriu,

About your question:
Just a question. When you write 'is the one provided in the data set metadata' you mean the metadata element:

* 'MD_Metadata > contact', or;

* 'MD_Metadata > identificationInfo > MD_DataIdentification > pointOfContact'.

Can you confirm?
as we are discussing about metadata point of contact, I was referring to MD_Metadata > contact'.

Thank you @AntoRot . This would help everybody reading correctly the thread.

LauraAlemany commented 2 years ago

In Spain it is very common that the contact for the service in not the same as the contact for the data set. Therefore, it is not possible for us to assume that the metadata point of contact for the service is the one provided in the data set metadata.

We agree with the proposal of @heidivanparys regarding WMS and WFS. The provider of the service is the responsible for making the GetCapabilities, i.e the metadata or description of the service.

MarieLambois commented 2 years ago

In fact it is really a matter of thinking. Since some service metadata elements will be hosted in the dataset MD, the POC for those would be the dataset MD POC. Some other service metatdata element would be in the GetCapabilities so for those the service POC is more relevant. In any case, whatever what we decide, the user will have access to both POC and I beleive is clever enough to pick the rigth body regarding his question.

MarieLambois commented 2 years ago

2022-02-25 discussion: All attendees directly agreed to take the https://github.com/INSPIRE-MIF/gp-data-service-linking-simplification/issues/41#issuecomment-1021278214. A note will be added to the consolidated proposal, clarifying that in cases where external ISO 19139 service metadada will not exist (i.e. only the Capabilities document of the service will), the metadata point of contact would be considered the same as the service provider.

Final proposal:

@heidivanparys That is just a first draft feel free to suggest any change.

Proposed mapping and rationale

Metadata Point Of Contact ('MD_Metadata > contact') will be mapped to the service responsible organization.

Detailed mapping description

For WMS 1.3 (XML schema): Metadata Point of Contact - organisation name: WMS_Capabilities/Service/ContactInformation/ContactPersonPrimary/ContactOrganization Metadata Point of Contact - e-mail: WMS_Capabilities/Service/ContactInformation/ContactElectronicMailAddress

  <ContactInformation>
    <ContactPersonPrimary>
      <ContactOrganization>organisation name</ContactOrganization>
    </ContactPersonPrimary>
    <ContactElectronicMailAddress>contact@myorg.eu</ContactElectronicMailAddress>
  </ContactInformation>

For WFS 2.0, that uses the OWS 1.1 schemas (see also http://docs.opengeospatial.org/is/09-025r2/09-025r2.html#23): Metadata Point of Contact - organisation name: WFS_Capabilities/ows:ServiceProvider/ows:ProviderName Metadata Point of Contact - e-mail: WFS_Capabilities/ows:ServiceProvider/ows:ServiceContact/ows:ContactInfo/ows:Address/ows:ElectronicMailAddress

<ows:ServiceProvider>
    <ows:ProviderName>organisation name</ows:ProviderName>
    <ows:ServiceContact>
        <ows:ContactInfo>
            <ows:Address>
                <ows:ElectronicMailAddress>contact@myorg.eu</ows:ElectronicMailAddress>
            </ows:Address>
        </ows:ContactInfo>
    </ows:ServiceContact>
</ows:ServiceProvider>

Changes to the current INSPIRE framework

Note to be added to the Service Technical Guidelines: Note: In cases where external ISO 19139 service metadada will not exist (i.e. only the Capabilities document of the service will), the metadata point of contact would be considered the same as the service provider.

heidivanparys commented 2 years ago

Only a minor remark regarding the proposed mapping and rationale

I would suggest rephrasing that to:

Proposed mapping and rationale

Metadata Point Of Contact¹ will be mapped to the contact information for the service. This means that the Metadata Point Of Contact is assumed to be the same as the Responsible Organisation.

¹ In a ISO/TS 19139 metadata record, Metadata Point Of Contact is mapped to gmd:MD_metadata/gmd:contact/gmd:CI_ResponsibleParty, see also [TG metadata].

The reasoning behind is that:

Service responsible organisation is INSPIRE terminology, whereas the term used in the relevant OGC specifications seems to be “contact information”.
It should be clear that this section is about mapping the INSPIRE metadata elements to the capabilities of services, so moving the mapping to ISO 19139 to a footnote.

idevisser commented 2 years ago

perhaps we should give consequently for all issues examples for WMS, WFS and Atom

MarieLambois commented 2 years ago

Based on @heidivanparys and @idevisser feedback:

Final proposal:

Proposed mapping and rationale

Metadata Point Of Contact1 will be mapped to the contact information for the service. This means that the Metadata Point Of Contact is assumed to be the same as the Responsible Organisation.

1 In a ISO/TS 19139 metadata record, Metadata Point Of Contact is mapped to gmd:MD_metadata/gmd:contact/gmd:CI_ResponsibleParty, see also [TG metadata].

Detailed mapping description

For WMS 1.3 (XML schema): Metadata Point of Contact - organisation name: WMS_Capabilities/Service/ContactInformation/ContactPersonPrimary/ContactOrganization Metadata Point of Contact - e-mail: WMS_Capabilities/Service/ContactInformation/ContactElectronicMailAddress

  <ContactInformation>
    <ContactPersonPrimary>
      <ContactOrganization>organisation name</ContactOrganization>
    </ContactPersonPrimary>
    <ContactElectronicMailAddress>contact@myorg.eu</ContactElectronicMailAddress>
  </ContactInformation>

For WFS 2.0, that uses the OWS 1.1 schemas (see also http://docs.opengeospatial.org/is/09-025r2/09-025r2.html#23): Metadata Point of Contact - organisation name: WFS_Capabilities/ows:ServiceProvider/ows:ProviderName Metadata Point of Contact - e-mail: WFS_Capabilities/ows:ServiceProvider/ows:ServiceContact/ows:ContactInfo/ows:Address/ows:ElectronicMailAddress

<ows:ServiceProvider>
    <ows:ProviderName>organisation name</ows:ProviderName>
    <ows:ServiceContact>
        <ows:ContactInfo>
            <ows:Address>
                <ows:ElectronicMailAddress>contact@myorg.eu</ows:ElectronicMailAddress>
            </ows:Address>
        </ows:ContactInfo>
    </ows:ServiceContact>
</ows:ServiceProvider>

For An ATOM feed Metadata Point of Contact - organisation name: feed/author/name Metadata Point of Contact - e-mail: feed/author/email `

organisation name contact@myorg.eu

`

Changes to the current INSPIRE framework

Note to be added to the Service Technical Guidelines: Note: In cases where external ISO 19139 service metadada will not exist (i.e. only the Capabilities document of the service will), the metadata point of contact would be considered the same as the service provider.

jescriu commented 1 year ago

This issue has been taken into account the current specification

INSPIRE-MIF / gp-data-service-linking-simplification