ISO-TC211 / StandardsTracker

This GitHub repository lets you - our users - log and track issues that you find with our standards and other document. Tag the issue with the standard or standards effected; we will assign it to the relevant group(s) within TC 211.
11 stars 0 forks source link

ISO 19115 Constraint information - allow supplementary detail #435

Open PeterParslow opened 2 years ago

PeterParslow commented 2 years ago

When expressing a license or IPR constraint (and perhaps others) it would be helpful to be able to provide a link to further information - e.g. the licence itself.

But in order to allow this 'otherConstraints' information, useConstraints/accessConstraints has to be set to 'otherRestrictions'.

Proposal: allow a link (XML anchor or other) for additional information, independent of the RestrictionCode chosen.

ejbleys commented 1 year ago

a) It would be useful to extend useConstraint code option something like "licenceInfromation" and constraint on otherConstraint be extended to that codeValue {otherConstraints: only documented if accessConstraints or useConstraints = (“otherRestrictions” or "licenceInfromation"} b) MD_LegalConstraints contains mco:reference: cit:CI_Citation [0..] (by inheritance) that would be an appropriate place to provide a citation and link to a license information Note: 1) most licenses restrict usage (not access) 2) accessConstraints (drawn from MD_RestrictionCode) would usually be: restricted; private; confidential; in-confidence. 3) useConstraints & accessConstraints are [0..] eg useConstraint both license and otherRestriction the latter invoking otherConstraint containing information about the licence location 4) any gco:CharacterString can be substituted with gcx:Anchor (assuming namespace has be assigned)

PeterParslow commented 1 year ago

For interest (regarding Every's point 2), the European Union has a controlled list of "reason" to provide as an anchor link from accessConstraints (currently using ISO 19115:2003 / ISO 19139:2007). These are the "allowable reasons" for (EU member government) data to limit public access: https://inspire.ec.europa.eu/metadata-codelist/LimitationsOnPublicAccess. There is a more helpful description behind each link:

(a) confidentiality of the proceedings of public authorites (b) international relations, public security or national defence (c) the course of justice (d) confidentiality of commercial or industrial information (e) intellectual property rights (f) confidentality of personal data (g) interests of a person who supplied the data on a voluntary basis (h) protection of the environment

I'm not saying that should be adopted by ISO, but it suggests that the list of access constraint values may be longer than in MD_RestrictionCode.

PeterParslow commented 1 year ago

And regarding Evert's point 4: this has been the EU INSPIRE approach for some time (again, within an ISO 19115:2003 / ISO 19139:2007 approach). See e.g. Example 2.14 at https://github.com/INSPIRE-MIF/technical-guidelines/blob/2022.2/metadata/metadata-iso19139/metadata-iso19139.adoc (the official doc is maintained/published on GitHub)

ejbleys commented 1 year ago

Agreed that the MD_RestrictionCode could readily be expanded in the next iteration of ISO 19115-1. Once INSIRE fully transfers to ISO 19115-1/2 that will become even more important as the concepts being described would be better encoded in the MD_Releasability class and terms mentioned used in the disseminationConstraints (type=MD_RestrictionCode [0..*])