Adding Licensing Schemes in WMDR; #35

gaubert · 2019-11-05T16:31:06Z

G. Aubert and T. Kralidis.

Deadline: 15.11.2019
Investigate other licensing schemes (such as Creative Commons) and propose how to reconcile these with the current code table 9-02.

See proposal below.

gaubert · 2019-11-05T16:59:12Z

End of last year we made a proposal with two recommended solution:
Data_Policy_WIGOS_Proposal.pdf

After few discussion emails with Tom Kralidis and Tony Boston, the following implementation was proposed:
use a CI_Online resource element to describe licenses applied to the observations:

<wmdr:dataPolicy>
      <wmdr:attribution>
      ....
      </wmdr:attribution>
      <!-- OrdnanceSurvey license example -->
      <gco:CharacterString>WMOOther</gco:CharacterString>
      <!-- Optional link -->
      <gmd:CI_OnlineResource>
        <gmd:linkage>
          <gmd:URL>https://www.ordnancesurvey.co.uk/docs/licences/os-opendata-licence.pdf</gmd:URL>
        </gmd:linkage> 
        <!—license name (code) – optional -->
        <gmd:name>
               <gco:CharacterString>CC-BY-4.0</gco:CharacterString>
        </gmd:name>
      </gmd:CI_OnlineResource>
</wmdr:dataPolicy>

The CI_OnlineResource is optional.

To leave the freedom to the user to add not only the CC license but additional one, it was decide to not use a codelist for defining the license name but instead have a characterString to make then the solution more robust to evolution and cover the full licenses spectra.

In the WMDR XML documentation, a list of recommended licenses could be provided. An example should also be provided to indicate how to fill that information.

This is solution is now open for review. Please provide your comments.

joergklausen · 2019-11-12T17:04:01Z

Please have a look at

https://github.com/wmo-im/wmdr/blob/master/html/EARoot/EA2.png (lower right part of image)
https://github.com/wmo-im/wmdr/blob/master/xsd/wmdr.xsd for the schema itself.
This approach is modeled after recommendations from the CC licence recommendations and has already been implemented in OSCAR/Surface as part of the release 1.0RC9:
http://schemas.wmo.int/wmdr/1.0RC9/html/
https://github.com/wmo-im/wmdr/releases/tag/v1.0RC9
We might need a telco to review these 2 different approaches and see where to go in the future.

efucile · 2020-03-12T09:24:01Z

We had the same discussion in the TT on WIS metadata. This is exactly the same subject and I would strongly suggest adopting the same solution for WIS and WIGOS metadata. @gaubert and @tomkralidis you are both in the TT-WISMD can you please make sure that we have a consistent solution on WIS and WIGOS?

steingod · 2020-03-12T12:06:12Z

The discussions at ESIPFed/science-on-schema.org#47 might be of interest in this context. In the perspective of a linked data approach I would consider canonical URLs as beneficial (potentially combined with textual elements).

tomkralidis · 2020-03-18T13:12:43Z

cc @amilan17

Strong preference for solution 3.1 to align with WIS. Given WMDR is relatively new, it is a good time to make this change now.

gaubert · 2020-04-15T08:53:23Z

If we want to align ourselves with the WMCP decisions regarding the data policy then the proposal should be as defined below: use a gmd:resourceConstraints and for linking the data policy, use a gmx:anchor. Below is an example of the encoding of the Data Policy for an Ordnance Survey Open Data License.

Comments ?

    <wmdr:dataPolicy>
	<wmdr:attribution>
        ...
        </wmdr:attribution>
	<gmd:resourceConstraints>
		<gmd:MD_LegalConstraints>
			<!-- Add useLimitation to indicate the limitations of usage for the data -->
			<gmd:useLimitation>
				<gco:CharacterString>Disclaimer - While every effort has been made to ensure that
these data are accurate and reliable within the limits of the current state of the art,
OrganisationX cannot assume liability for any damages caused by any errors or omissions in the
data, nor as a result of the failure of the data to function on a particular system.
OrganisationX makes no warranty, expressed or implied, nor does the fact of distribution
constitute such a warranty.
</gco:CharacterString>
			</gmd:useLimitation>
			<gmd:accessConstraints>
				<gmd:MD_RestrictionCode
codeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/Codelist/gmxCodelists.xml#MD_RestrictionCode"
codeListValue="otherRestrictions">otherRestrictions</gmd:MD_RestrictionCode>
			</gmd:accessConstraints>
			<gmd:useConstraints>
				<gmd:MD_RestrictionCode
codeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/Codelist/gmxCodelists.xml#MD_RestrictionCode"
codeListValue="otherRestrictions">otherRestrictions</gmd:MD_RestrictionCode>
			</gmd:useConstraints>
			<!-- Add WMOOther, to signal that the policy is applicable in the WMO Context -->
			<gmd:otherConstraints>
				<gmx:Anchor xlink:href="http://wis.wmo.int/2013/codelists/WMOCodeLists.xml#WMO_DataLicenseCode_WMOOthrer">WMOOther</gmx:Anchor>
			</gmd:otherConstraints>
			<!-- Explanation expanding on WMOOther is added here (Point 2). This explanatory detail is
also needed, when using a term like ‘licence’ or ‘copyright’ -->
			<gmd:otherConstraints>
				<gmx:Anchor xlink:href="https://www.ordnancesurvey.co.uk/docs/licences/os-opendatalicence.pdf">Ordnance Survey Open Data License</gmx:Anchor>
			</gmd:otherConstraints>
		</gmd:MD_LegalConstraints>
	</gmd:resourceConstraints>
</wmdr:dataPolicy>

KarlBureau · 2020-04-16T07:01:05Z

I am not an expert in the means of recording licenses, however, considering that different jurisdictions have their own nuance in terms of license rules, it is helpful to allow the ability to link to the actual license. The downside is that it is more difficult to alter access to data based on the license type.

gaubert · 2020-05-05T10:06:13Z

example with WMOAdditional:

    <wmdr:dataPolicy>
	<wmdr:attribution>
        ...
        </wmdr:attribution>
	<gmd:resourceConstraints>
		<gmd:MD_LegalConstraints>
			<!-- Add useLimitation to indicate the limitations of usage for the data -->
			<gmd:useLimitation>
				<gco:CharacterString>No limitation</gco:CharacterString>
			</gmd:useLimitation>
			<gmd:accessConstraints>
				<gmd:MD_RestrictionCode
codeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/Codelist/gmxCodelists.xml#MD_RestrictionCode"
codeListValue="otherRestrictions">otherRestrictions</gmd:MD_RestrictionCode>
			</gmd:accessConstraints>
			<gmd:useConstraints>
				<gmd:MD_RestrictionCode
codeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/Codelist/gmxCodelists.xml#MD_RestrictionCode"
codeListValue="otherRestrictions">otherRestrictions</gmd:MD_RestrictionCode>
			</gmd:useConstraints>
			<gmd:otherConstraints>
				<gmx:Anchor xlink:href="http://wis.wmo.int/2013/codelists/WMOCodeLists.xml#WMO_DataLicenseCode_WMOAdditional">WMOAdditional</gmx:Anchor>
			</gmd:otherConstraints>
		</gmd:MD_LegalConstraints>
	</gmd:resourceConstraints>
</wmdr:dataPolicy>

gaubert · 2020-05-05T10:10:15Z

example with WMOEssential:

    <wmdr:dataPolicy>
	<wmdr:attribution>
        ...
        </wmdr:attribution>
	<gmd:resourceConstraints>
		<gmd:MD_LegalConstraints>
			<!-- Add useLimitation to indicate the limitations of usage for the data -->
			<gmd:useLimitation>
				<gco:CharacterString>No limitation</gco:CharacterString>
			</gmd:useLimitation>
			<gmd:accessConstraints>
				<gmd:MD_RestrictionCode
codeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/Codelist/gmxCodelists.xml#MD_RestrictionCode"
codeListValue="otherRestrictions">otherRestrictions</gmd:MD_RestrictionCode>
			</gmd:accessConstraints>
			<gmd:useConstraints>
				<gmd:MD_RestrictionCode
codeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/Codelist/gmxCodelists.xml#MD_RestrictionCode"
codeListValue="otherRestrictions">otherRestrictions</gmd:MD_RestrictionCode>
			</gmd:useConstraints>
			<gmd:otherConstraints>
				<gmx:Anchor xlink:href="http://wis.wmo.int/2013/codelists/WMOCodeLists.xml#WMO_DataLicenseCode_WMOEssential">WMOEssential</gmx:Anchor>
			</gmd:otherConstraints>
		</gmd:MD_LegalConstraints>
	</gmd:resourceConstraints>
</wmdr:dataPolicy>

markusfiebig · 2020-06-04T09:41:55Z

Being new to this discussion, a few words on my background and motivation. I'm heading the World Data Centre for Aerosol (WDCA) for GAW. Also, I'm involved with data management in ACTRIS, a European research infrastructure (RI) contributing to GAW. In that function, I participate also in ENVRI-FAIR, an EU umbrella project for the European geoscientific research infrastructures, focussing on data FAIRness. Here, I'm leading a task force on license metadata. The atmospheric ENVRI-FAIR RIs are currently looking into using WMDR for internal metadata exchange.

As with @KarlBureau , I'm not an expert on existing specs for encoding metadata, but I see the need for the following:

Distiguish between license metadata and data policy metadata. These live in different realms, and can even be used in parallel. A license is a legal statement, a data policy is an ethical statement. They are often combined, e.g. when using a CC0 license together with a "fair-use" policy asking for acknowledgement.
License metadata should at least comprise:

License identifier (controlled vocabulary)
Link to license (online resource)
Acknowledgement (free text, 0..n). Having the option of having several acknowledgement texts allows for attribution stacking (necessary feature), and allows to test whether an acknowledgement already exists before adding anotherone.

Data Policy metadata should at least comprise:

Title or identifier (fixed to either free text or controlled vocabulary, to be discussed)
Link to data policy
Acknowledgement (free text, 0..n).

I also agree that this should be aligned between WMDR and WIS.

markusfiebig · 2020-06-09T09:36:51Z

Short P.S. to my comment above:
For the license metadata, we need one more element:

Licensee (free text, 1..n). The licensee is the entitity the license is given to. It can be the general public, but doesn't have to be. If not the general public, the license can be given to several entities, which is why the field is 1..n.

joergklausen · 2020-06-11T10:32:47Z

The topic is at the interface between documenting observations and facilitating (potentially) restricted data access. Depending on that 1..1 or 1..n are necessary. For simple documentation, also an aggregated element such as 'a confined group' might be sufficient, where as for control of access, an individual list is needed.

joergklausen · 2020-10-23T12:01:31Z

@tomkralidis @gaubert What is the current situation with wmcp regarding this issue? Is the wcmp considered stable, or are there plans to update this part? Considering the examples above using the gmd:resourceConstraints construct, a clean separation between policy and licence doesn't seem to be supported. Further, should 'licencee' be included and how (free text, code list)? Is it worth a videoconf to pave the way forward? [As an aside: we need to decide on the spelling, licence vs license]

tomkralidis · 2020-10-28T02:34:28Z

@joergklausen +1 for a telecon to summarize and move forward. At this point I would personally say any major or minor (i.e. not maintenance) changes to WCMP would be rooted in either 19115-3:2016 (read breaking changes) and/or other standards (DCAT) or representations (JSON). This will become more clear as we pave the way for WIS 2.0 compliance and reach consensus in TT-WISMD.

As well, I would use licence given this is what's used in 19115:2003, for example.

joergklausen · 2021-04-23T10:52:30Z

@tomkralidis @efucile This has been dormant for too long ... Is there any specific solution that WIS is now proposing? Do we need to do something above and beyond the existing solution (see figure)? If so, can @efucile perhaps propose a meeting?

efucile · 2021-04-23T11:47:05Z

@tomkralidis @efucile This has been dormant for too long ... Is there any specific solution that WIS is now proposing? Do we need to do something above and beyond the existing solution (see figure)? If so, can @efucile perhaps propose a meeting?

I think we need a meeting on this. I would propose to have both teams and I think that we should start talking of preparing for the new data policy. It is not going to be so different in terms of metadata, but we need to discuss the implications. It would be good to have a meeting with both TTs only on the subject.

joergklausen · 2023-01-09T15:38:11Z

Closed for lack of further requirements.

gaubert self-assigned this Nov 6, 2019

IgorZahumensky changed the title ~~Adding Licensing Schemes in WMDR~~ Adding Licensing Schemes in WMDR; Deadline:3.03.2020 Jan 30, 2020

IgorZahumensky changed the title ~~Adding Licensing Schemes in WMDR; Deadline:3.03.2020~~ Adding Licensing Schemes in WMDR; Mar 17, 2020

joergklausen transferred this issue from wmo-im/wmds Jun 3, 2020

joergklausen mentioned this issue Jun 3, 2020

AI2019-5: Verify existing recommendation on licenses wmo-im/et-acdm#5

Closed

joergklausen added discussion needed Issue needs further discussion within the team enhancement New feature or request labels Oct 23, 2020

joergklausen added the OSCAR/Surface Issue addresses OSCAR/Surface feature label Apr 23, 2021

joergklausen added this to Submitted in WMDR XML Schema Definition v2.0 Apr 23, 2021

joergklausen added this to Submitted in OSCAR/Surface Apr 23, 2021

joergklausen removed this from Submitted in OSCAR/Surface May 27, 2021

joergklausen closed this as completed Jan 9, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Adding Licensing Schemes in WMDR; #35

Adding Licensing Schemes in WMDR; #35

gaubert commented Nov 5, 2019

gaubert commented Nov 5, 2019

joergklausen commented Nov 12, 2019

efucile commented Mar 12, 2020

steingod commented Mar 12, 2020

tomkralidis commented Mar 18, 2020

gaubert commented Apr 15, 2020 •

edited

Loading

KarlBureau commented Apr 16, 2020

gaubert commented May 5, 2020 •

edited

Loading

gaubert commented May 5, 2020

markusfiebig commented Jun 4, 2020

markusfiebig commented Jun 9, 2020

joergklausen commented Jun 11, 2020 •

edited

Loading

joergklausen commented Oct 23, 2020

tomkralidis commented Oct 28, 2020

joergklausen commented Apr 23, 2021

efucile commented Apr 23, 2021

joergklausen commented Jan 9, 2023

Adding Licensing Schemes in WMDR; #35

Adding Licensing Schemes in WMDR; #35

Comments

gaubert commented Nov 5, 2019

gaubert commented Nov 5, 2019

joergklausen commented Nov 12, 2019

efucile commented Mar 12, 2020

steingod commented Mar 12, 2020

tomkralidis commented Mar 18, 2020

gaubert commented Apr 15, 2020 • edited Loading

KarlBureau commented Apr 16, 2020

gaubert commented May 5, 2020 • edited Loading

gaubert commented May 5, 2020

markusfiebig commented Jun 4, 2020

markusfiebig commented Jun 9, 2020

joergklausen commented Jun 11, 2020 • edited Loading

joergklausen commented Oct 23, 2020

tomkralidis commented Oct 28, 2020

joergklausen commented Apr 23, 2021

efucile commented Apr 23, 2021

joergklausen commented Jan 9, 2023

gaubert commented Apr 15, 2020 •

edited

Loading

gaubert commented May 5, 2020 •

edited

Loading

joergklausen commented Jun 11, 2020 •

edited

Loading