Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New KPI regarding filename in metadata #81

Open
jsieland opened this issue Jan 8, 2021 · 3 comments
Open

New KPI regarding filename in metadata #81

jsieland opened this issue Jan 8, 2021 · 3 comments
Labels
Milestone

Comments

@jsieland
Copy link
Contributor

jsieland commented Jan 8, 2021

Summary and Purpose
Comment from my GISC Offenbach colleagues.

Proposal

  • filename should be contained in metadata (identifier.xml for metadata, data filename?)

Reason

  • if filename is only included in url it is more difficult to split the information
@tomkralidis
Copy link
Collaborator

@jsieland thanks for reporting. Can we get clarification? What filename are we referring to (in which element of WCMP)?

Keep in mind URLs may point to files with filenames or an API call (which has no filename per se).

@josusky
Copy link
Contributor

josusky commented Jan 22, 2021

According to publication 1060, requirement 8.1.1: "WIS discovery metadata record shall be uniquely identified using the gmd:​MD​_Metadata/​gmd:​fileIdentifier attribute". In case of metadata for traditional bulletins this can be easily translated to the heading (AHL). But for other types of data, I suppose that is what @jsieland means, we need some other identifier. There is the so called "online resource", here is an example:

 <gmd:transferOptions>
        <gmd:MD_DigitalTransferOptions>
<gmd:onLine>
            <gmd:CI_OnlineResource>
              <gmd:linkage>
                <gmd:URL>http://gisc.dwd.de/wisportal/#SearchPlace:q?pid=urn:x-wmo:md:int.wmo.wis::ISMD01EDZW</gmd:URL>
              </gmd:linkage>
              <gmd:protocol>
                <gco:CharacterString>http</gco:CharacterString>
              </gmd:protocol>
              <gmd:name>
                <gco:CharacterString>GISC Offenbach, Deutscher Wetterdienst</gco:CharacterString>
              </gmd:name>
              <gmd:description>
                <gco:CharacterString>WMO Information System, download products/data through GISC Offenbach, Deutscher Wetterdienst</gco:CharacterString>
              </gmd:description>
            </gmd:CI_OnlineResource>
          </gmd:onLine>

Is this the URL you ar referring to? The "CI_OnlineResource" has attributes and contains (may contain) additional elements, I guess, one of those could be used to give (optional) information about file name. Of course, it should be some pattern, not a fixed name, as the actual file name may contain variable parts (e.g. date/time).
I see that "gmd:name", that looks like a good place to me, is currently used for things like that are more a description than a name, could we (re)define the meaning of this element? Or perhaps use something else - @jsieland any proposals?

@jsieland
Copy link
Contributor Author

The idea is to be able to access the data automatically (as far as possible) based on the metadata. This means that the metadata contains a reference that can also be used by automated processes to access the respective data:

  • Services: The address of the service through which the data can be obtained (then it is essential that the metadata contains a description of the service)
  • Directory: Needs information which data is located in the directory (additional information using filepattern?)
  • Direct: Specify a file that can be retrieved via the URL

I like the idea of using the additional elements of gmd:CI_OnlineResource - as far as I'm aware INSPIRE recommends using gmd:name, gmd:description and gmd:function/gmd:CI_OnLineFunctionCode.

@amilan17 amilan17 added this to the Future milestone Apr 6, 2022
@amilan17 amilan17 added the kpi label Apr 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants