Improve / change handling of license information in ISO 19115

[PeterParslow]

At present, various profiles squeeze licensing information in somewhere. For example, the UK profile of the INSPIRE profile of ISO 19115:2003 states that license info should be entered using ISO 19115 resourceConstraints -> LegalConstraints.useConstraints

See https://agiorguk.github.io/gemini/1062-gemini-datasets-and-data-series.html#26 and TG Recommendation C.10 in https://github.com/INSPIRE-MIF/technical-guidelines/blob/2022.2/metadata/metadata-iso19139/metadata-iso19139.adoc#conditions-applying-to-access-and-use

But licences are actually more about permissions & responsibilities, as well as containing constraints*. Is there a good case for an explicit "licence" metadata element?

Possibly some useful work from the withdrawn ISO 19149 GeoREL, withdrawn ISO 19153 GeoDRM, or cancelled ISO 19172 "How to describe geographic data licence". See modelling in e.g. DCAT. Possible interest from Creative Commons to help (briefly discussed when they engaged regarding where to document the 'attribution statement' required by e.g. CC-BY, although their focus was in DCAT).

*Consider, for example, the analysis of licences that contributed to the development of https://www.w3.org/TR/odrl-model/ - I'm not suggesting we restrict ourselves to open data or to machine readable licences although both are good use cases.

[ReesePlews]

TMG would be happy if the revision of 19115 could become a new "authoritative" home for some of those terminological entries from withdrawn ISO 19149 GeoREL, and withdrawn ISO 19153 GeoDRM. at least they are a starting point for additional terminology development work.

[PeterParslow]

TMG would be happy if the revision of 19115 could become a new "authoritative" home for some of those terminological entries from withdrawn ISO 19149 GeoREL, and withdrawn ISO 19153 GeoDRM. at least they are a starting point for additional terminology development work.

I will let it be known here: I have made a comment/suggestion on the draft NWIP "Maintenance and management of cross committee common UML classifiers and their implementation artifacts" that it is actually about "management of common concepts & their realisation (if that’s the right word!) as UML classifiers, XML schema fragments etc" - and that could/would actually include the 'realisation' (labelling?) of a concept with one or more terms (terminology entries). Interestingly, there was a slightly similar comment from Norway, at least in terms of referring to the things the proposal is about as 'concepts'.

Note: the UK comments didn't make it into the first collation of comments, but should be available to the proposers.

That TR, or perhaps its supporting 'register' would then be the authoritative home for those 'useful concepts' that need to outlive the withdrawal of their standards.

That said, if ISO 19115 agrees to pick up licence descriptions, then (perhaps) some of those concepts / terms would have their home in ISO 19115.

[ejbleys]

Agreed that constraints in 19115:2003 can not handle licensing well.
I agree that it would be quite reasonable for licensing to be a seperate classifier, however licenses also tend to be inexorably linked to constraints on usage/redistribution. (I personally believe that licensing is not an access issue, those being more aligned with security/privacy/IP concerns)
ISO 19115-1:2014 added a number of attributes to MD_Constraints that are very useful for licensing. Australia uses MD_LegalConstraints/reference/CI_Citation/onlineResource/CI_OnlineResource/linkage to display the license URL.
The link to the URL is then either managed using gcx:Anchor or the XML attribute xlink:href

[PeterParslow]

Australia uses MD_LegalConstraints/reference/CI_Citation/onlineResource/CI_OnlineResource/linkage to display the license URL.
The link to the URL is then either managed using gcx:Anchor or the XML attribute xlink:href

Good spot, ISO 19115-1 gives "licence agreement" as an example of use for 'MD_Constraints.reference

ISO 19115:2003 in which MD_Constraints didn't have a 'reference' attribute to be inherited by MD_LegalConstraints, so UK (building on EU) uses MD_LegalConstraints/otherConstraints/Anchor:xlink:href to hold a licence URL.

[laers]

I also agree that licens is not handle in a good way in ISO19115-3. A much more simple approach should be considered - for instance with inspiration from DCAT´s license:

<dct:license>
<dct:LicenseDocument rdf:about="https://creativecommons.org/licenses/by/4.0/deed.da"/>
</dct:license>

In ISO19115-3 a RestrictionCode has to be provided and the relevant license is a kind of a sub-information - this kind of complexity could properly be avoided:

<mri:resourceConstraints>
<mco:MD_LegalConstraints>
<mco:useConstraints>
<mco:MD_RestrictionCode codeList="http://standards.iso.org/iso/19115/resources/Codelists/cat/codelists.xml#MD_RestrictionCode" codeListValue="otherRestrictions"/>
</mco:useConstraints>
<mco:otherConstraints>
<gcx:Anchor xlink:href="https://creativecommons.org/licenses/by/4.0/deed.da">CC BY 4.0</gcx:Anchor>
</mco:otherConstraints>
</mco:MD_LegalConstraints>
</mri:resourceConstraints>

[JanHjelmager]

Before we solve the licens issue in 19115-3 we have to solve it in 19115-1.

As licens is a fundamental issue for many organisations it should perhaps be an attribute at MD_Constraints levels as it might have an impact on both legal and security level. The data type of the attribute could be CI_OnlineResource.

[ejbleys]

Is there not a comment in CC that an image of the form of CC being used must be presented. Use of the logo attribute in 19115-1:2014 MD_Constraints is an option.Evert Bleys4 Tudor PlaceHUGHES ACTAustraliaMob: 0411 483 876On 26 Oct 2024, at 00:02, Jan Hjelmager ***@***.***> wrote: Before we solve the licens issue in 19115-3 we have to solve it in 19115-1. As licens is a fundamental issue for many organisations it should perhaps be an attribute at MD_Constraints levels as it might have an impact on both legal and security level. The data type of the attribute could be CI_OnlineResource. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[PeterParslow]

Is there not a comment in CC that an image of the form of CC being used must be presented.

No: this is what CC says:

"communicate this choice in a way that will be clear to people who come across your work. As part of this communication, you should include a link to the license you’ve chosen." (https://creativecommons.org/share-your-work/cclicenses/)

Interestingly, what CC came to us about is how to specify the "attribution statement" required when people use data under one of their BY licences. Sometimes a publisher wants to state the specific words that they wish the data user to use.

[ejbleys]

Oops, sorry. The one significant thing that is missing is a clear mechanism on where to supply a requested acknowledgement. Australia tends to use "otherConstraints" (having set an accessConstraint to "otherRestrictions") in the form of "(c) This data has been made available for reuse by ... " or something of that nature. It would be much better if there was a specific attribute to manage those details.