2020-01 hierarchyLevelName redundant?

[PeterParslow]

Having set the hierarchyLevelName value in the guidance, perhaps the element should be dropped & given as part of the ‘resourceType’ (gmd:hierarchyLevel) encoding? Also, the encoding guidelines & example given are not useful; those facts should be (perhaps are) in the general XML encoding part. (Peter, 31/02/2020)

Fix the example XML, and move the encoding guidelines to the general XML page Fixed on Peter’s laptop.

The text was already on the general XML page (https://www.agi.org.uk/40-gemini/1048-uk-gemini-encoding-guidance#2, 2.3.1 & 2.4.1; I made a minor change at 2.3.1 & 2.4.1 to fix hierarchyLevelName values

[6footdestiny]

Im in agreement with the suggestion to drop and wrap into resourceType. +1

[PeterParslow]

Sean: MEDIN decided not to add hierarchyLevelName to their profile, for just this reason. Edd: OK Jo: not sure what the effect would be to implement this in GeoNetwork James R: it might be!

[nmtoken]

I thought initially you were discussing removing the requirements for Hierarchy level name rather than, what I now realise you mean, remove the element from GEMINI and roll the requirement into Resource type, like we have already with Hierarchy Level

I note in the schematron we have:

<!-- ============================================================== -->
<!-- Metadata Item 39 - Resource Type (aka 46 - Hierarchy Level)    -->
<!-- ============================================================== -->

So in principle I have no main issue with it. My reservations are what the implications will be for the schematron.

No changes to the tests themselves, but it will/should involve changing to wording of responses, and variable names (which follow the element numbering), and what then of the versioning of GEMINI?

From

<!-- ======================================== -->
<!-- Metadata Item 47 - Hierarchy level name                                    -->
<!-- ======================================== -->
<sch:pattern fpi="Gemini2-mi47">
  <sch:title>Hierarchy level name</sch:title>
</sch:pattern>
<sch:pattern fpi="Gemini2-mi47-general">
  <sch:p>Hierarchy level name is mandatory for dataset series and services, not required for
    datasets</sch:p>
  <sch:rule context="//gmd:MD_Metadata[1]">
    <sch:let name="hierLevelNameCount" value="count(gmd:hierarchyLevelName)"/>
    <sch:report
    test="$hierLevelNameCount = 0 and ($hierarchyLevelCLValue = 'service' or $hierarchyLevelCLValue = 'series')"
    > MI-47a (Hierarchy level name): Need at least one hierarchyLevelName have: <sch:value-of
      select="$hierLevelNameCount"/>
    </sch:report>
  </sch:rule>
</sch:pattern>
<sch:pattern fpi="Gemini2-mi47-services-restriction">
  <sch:p>TG Requirement 3.1: metadata/2.0/req/sds/resource-type Additionally the name of the
    hierarchy level shall be given using element gmd:hierarchyLevelName element with a Non-empty
    Free Text Element containing the term "service" in the language of the metadata.</sch:p>
  <sch:rule context="//gmd:MD_Metadata[1]/gmd:hierarchyLevelName/*[1]">
    <sch:let name="hierLevelcListVal" value="preceding::gmd:hierarchyLevel/*/@codeListValue"/>
    <sch:let name="hierLevelNameText" value="descendant-or-self::text()"/>
    <sch:report test="($hierLevelcListVal = 'service' and $hierLevelNameText != 'service')">
    MI-47b (Hierarchy level name): Hierarchy level name for services must have value "service" </sch:report>
    <sch:assert test="normalize-space(.)"> MI-47c: Hierarchy level name for services must have
    value "service" </sch:assert>
  </sch:rule>
</sch:pattern>

To?

<!-- ============================================================== -->
<!-- Metadata Item 39 - Resource Type 
(aka 46 - Hierarchy Level and 47 - Hierarchy level name -->
<!-- ============================================================== -->
<sch:pattern fpi="Gemini2-mi39">
    <sch:title>Resource type</sch:title>
    <sch:rule context="//gmd:MD_Metadata[1]">
      <sch:assert test="count(gmd:hierarchyLevel) = 1"> MI-39a (Resource Type): Resource type is mandatory. One
        shall be provided. </sch:assert>
      <sch:assert
        test="
          gmd:hierarchyLevel[1]/*[1]/@codeListValue = 'dataset' or
          gmd:hierarchyLevel[1]/*[1]/@codeListValue = 'series' or
          gmd:hierarchyLevel[1]/*[1]/@codeListValue = 'service'"
        > MI-39b (Resource Type): Value of resource type shall be 'dataset', 'series' or 'service'. </sch:assert>
    </sch:rule>
</sch:pattern>
<sch:pattern is-a="IsoCodeListPattern" id="Gemini2-mi39-CodeList">
    <sch:param name="context" value="//gmd:MD_Metadata[1]/gmd:hierarchyLevel/*[1]"/>
</sch:pattern>
<sch:pattern fpi="Gemini2-mi39-general">
  <sch:p>Hierarchy level name is mandatory for dataset series and services, not required for
    datasets</sch:p>
  <sch:rule context="//gmd:MD_Metadata[1]">
    <sch:let name="hierLevelNameCount" value="count(gmd:hierarchyLevelName)"/>
    <sch:report
    test="$hierLevelNameCount = 0 and ($hierarchyLevelCLValue = 'service' or $hierarchyLevelCLValue = 'series')"
    > MI-39c (Resource Type): Need at least one hierarchyLevelName have: <sch:value-of
      select="$hierLevelNameCount"/>
    </sch:report>
  </sch:rule>
</sch:pattern>
<sch:pattern fpi="Gemini2-mi39-services-restriction">
  <sch:p>TG Requirement 3.1: metadata/2.0/req/sds/resource-type Additionally the name of the
    hierarchy level shall be given using element gmd:hierarchyLevelName element with a Non-empty
    Free Text Element containing the term "service" in the language of the metadata.</sch:p>
  <sch:rule context="//gmd:MD_Metadata[1]/gmd:hierarchyLevelName/*[1]">
    <sch:let name="hierLevelcListVal" value="preceding::gmd:hierarchyLevel/*/@codeListValue"/>
    <sch:let name="hierLevelNameText" value="descendant-or-self::text()"/>
    <sch:report test="($hierLevelcListVal = 'service' and $hierLevelNameText != 'service')">
    MI-39d (Resource Type): Hierarchy level name for services must have value "service" </sch:report>
    <sch:assert test="normalize-space(.)"> MI-39e (Resource Type): Hierarchy level name for services must have
    value "service" </sch:assert>
  </sch:rule>
</sch:pattern>

[archaeogeek]

I've had a look through the Gemini 2.3 metadata profile for GeoNetwork, and the only places I can see where hierarchyLevelName is specifically handled (with the exception of the schematron, as discussed above) are to ensure it's editable if blank, and then ensuring any remaining blank entries are given a gco:nilReason attribute with a value of inapplicable when the record is saved. So from that perspective, I don't think I'd need to make any changes.

However, the guidance (both Gemini https://www.agi.org.uk/gemini/40-gemini/1062-gemini-datasets-and-data-series/#47 and ISO19115) discuss multiple scoped hierarchy levels in a record. In that scenario, I don't feel that the lack of a hierarchyLevelName element (implying it's referring to the whole dataset) would be enough. I would want to see an explicitly defined dataset declaration as well as declarations for what ever Feature Types or Instance Types were also being described.

So my proposal would be that instead of rolling hierarchyLevelName into resourceType, we leave it as is, but improve the guidance to distinguish between the two (particularly since the encoding talks about hierarchyLevel, not resourceType) to allow for the use of Feature Level or Instance Level metadata.

[PeterParslow]

2021-07-16: Removing this element would restrict possible future use of GEMINI for e.g. feature level metadata.

It's not doing any harm being defined, so leave it in.

Could change the guidance to describe the situations where ISO allows other values for Resource type (hierarchyLevel), in which case it is not an INSPIRE record. But without a proper discussion about the questions of different (& multiple) hierarchyLevels, we might push people in the wrong direction. We should raise a separate issue for that.