Which entities actually can have a copyright license?

[l-emele]

Description of the issue

We have the axiom 'information content entity' 'has copyright license' some 'copyright license'. This make sense for a lot of subclasses like study report, software and data set.

But there are a lot of information content entities, that do not have a copyright license, e.g. email adress, written name, abbreviation or unit of measurement.

Ideas of solution

Remove the general axiom 'information content entity' 'has copyright license' some 'copyright license' and add (where appropriate) a more specific axiom.

Workflow checklist

• [ ] I discussed the issue with someone else than me before working on a solution
• [ ] I already read the latest version of the workflow for this repository
• [ ] The goal of this ontology is clear to me

I am aware that

• [ ] every entry in the ontology should have a definition
• [ ] classes should arise from concepts rather than from words

[l-emele]

Here is a first, non-comprehensive list of classes that should imho get an 'has copyright license' some 'copyright license' axiom:

• data set
• database
• document
• copyright license
• data license
• scenario
• model

@Ludee : I assign you to this issue as you are our licensing expert.

[l-emele]

@ludee: Any thoughts on this issue?

[l-emele]

@oeo-domain-expert-linked-open-data : Any thoughts on this issue?

[Ludee]

Sorry for not responding yet. I will work on this now.

Before starting to reinvent the wheel I got in contact with the developers from DALICC - Data Licenses Clearance Center.

They maintain a License Library with machine readable licenses (RDF) and additional functions. The model is based on the Open Digital Rights Language (ODRL). Unfortunately, there is no dedicated ontology we can simply import. The library can be accessed here: https://github.com/dalicc/dalicc/tree/main/licensedata/licenselibrary

The DALICC Information Model:

Every license has a target property: odrl:target [ a odrl:AssetCollection ;

The three possible targets are:

• Creative work (i.e. text, picture, sound, movie) This asset type comprises any type of literary work that is subject to copyright. It also includes multimedia work that combines various media types such as text, audio, images, animations, video and interactive content.
• Dataset This asset type comprises a data collection, a database, a repository or any other type of systematically organized data. This also includes references to collections of unstructured information.
• Software This asset type comprises digital artefacts such as computer programs, libraries and related non-executable data as well as related online documentation or digital media.

Would it make sense to create these classes as sublasses of information content entity and restructure the existing classes as listed above? In addition the class license should be linked accordingly, because some licenses are suitable for multiple targets. Example: CC-BY-4.0 -> dct:type dalicc:CreativeWork, dcmitype:Dataset

Happy to hear your opinions on this and work on a suitable definitions and axioms. @l-emele @chrwm @christian-rli

[l-emele]

The three possible targets are:

* **Creative work** (i.e. text, picture, sound, movie)
  This asset type comprises any type of literary work that is subject to copyright. It also includes multimedia work that combines various media types such as text, audio, images, animations, video and interactive content.

* **Dataset**
  This asset type comprises a data collection, a database, a repository or any other type of systematically organized data. This also includes references to collections of unstructured information.

* **Software**
  This asset type comprises digital artefacts such as computer programs, libraries and related non-executable data as well as related online documentation or digital media.

This seems more like a distinction of which licenses can be used and less a clear distinction between different types of information content entities. For example a documentation is also a text and thus creative work. Similarly digital media / multimedia is basically mentioned both in software and in creative work.

We currently have the following relevant[^1] licenses:

• A copyright license is a license that states the ownership and contractually sets the rights and obligations to use, copy, and distribute a creative work.
• A software license is a copyright license that determines ownership and permissions for software, code, or models
• A data license is a license that determines ownership, database protection, and permissions for data.

Maybe we should introduce a further license class? Something like create work license or artwork license?

[^1]: We have some emission certificates as further licenses, but they are irrelevant here.

Would it make sense to create these classes as sublasses of information content entity and restructure the existing classes as listed above?

I don't see yet a clear reason why we should restructure the information content entities. A large part of them are not defined by ourselves but imported from IAO.

My first idea was to add equivalent classes. For example:

1. If we add creative work with a definition of something like A creative work is the product of a creative process and the axiom 'creative work' EquivalentTo: 'information content entity' and ('information output of' some 'creative process')
2. If we add creative process with a definition of something like A creative process is a creative process in which a person of a group of persons creates a creative work
3. And if we add the axiom 'information output of' some 'creative process' to those classes like report.

Then, these classes like report will be inferred as subclasses of creative work.

However, this somehow shifts only the problem, as we then have to identify which classes are output of which process. This would probably a similar work as identifying which entities actually can have a copyright license -- which was the original idea of this issue.

[Ludee]

Thanks for the detailed answer, that helps a lot!

Maybe we should introduce a further license class?

Yes, I suggest the following definition for it.

A creative work license is a copyright license that determines ownership and permissions for literary work and multimedia work that combines various media types such as text, audio, images, animations, video and interactive content and its collections.

I like your approach of adding the process of creating something, but I'm also not sure if it is needed at some point. And it clearly does only shift the task of assigning. And the copyright/license is only one aspect of the material.

Here is a first attempt to assign the content entities:

data license

• data set
• database

software license

• model
• software

creative work license

• document
• software documentation
• factsheet
• report

More creative work not in the OEO:

• image / picture / animations / plots
• text
• audio, video and interactive content
• presentation, collection
• metadata

I think a scenario is not suitable to be licensed. Only the used data sets, documents, and text.

In addition here is a (incomplete) list of entities that are clearly not suitable to be licensed:

• assumption
• constraint
• data descriptor
• objective function
• quantity value
• reference
• variable
• methodology
• unit of measurement

[l-emele]

We are almost done, one little thing regarding the object property to axiomatise the relations. We currently have has copyright license which is a direct subproperty of has information content entity and according to its definition[^1] cannot be used for data licenses.

There are a couple of options to solve this:

1. Use has copyright license for software licenses and create work license but use has information content entity for data licenses.
2. Relabel and redefine has copyright license to has license: A relation that holds between an information content entity and a ~copyright~ licence.
3. Add further object properties: has data license: A relation that holds between an information content entity and a data license. If we add this, we might also similarly add has creative work license and has software license.

@stap-m : Do you have an opinion here, which option is best suited for the OEKG?

In any case, we should add the proper domain and range to has copyright license (OEO:00020188).

[^1]: A relation that holds between an information content entity and a copyright licence.

[stap-m]

Option 2 allows a broad application and goes well with the OEKG population, from my point of view. It might even make queries more straightforward.

[l-emele]

I think, this issue is ready for implementation. To summarise:

1. Relabel and redefine has copyright license to has license: A relation that holds between an information content entity and a ~copyright~ licence.
2. Add domain information content entity and range license
3. Add class creative work license: A creative work license is a copyright license that determines ownership and permissions for literary work and multimedia work that combines various media types such as text, audio, images, animations, video and interactive content and its collections.
4. Delete axiom 'information content entity' 'has copyright license' some 'copyright license'.
5. Add 'has license' some 'data license' to data set and data base.
6. Add 'has license' some 'software license' to model and software.
7. Add 'has license' some 'creative work license' to document, software documentation, factsheet and report.
8. Open issue for creative work not yet in the OEO.
9. Harmonise spelling license versus licence; British English is licence (Not discussed in this is issue, but i noticed.)

I can implement this.

[l-emele]

in PR #1547 I've implemented everything we agreed on. However, I found an inconsistency:

We added the domain information content entity to has licence and we added the axiom model 'has licence' some 'software licence'. However, model is not a subclass of information content entity, but a sister class.

To solve this, I see two potential solutions:

1. Extending the domain of has licence to 'information content entity' and model.
2. Replacing the axiom model 'has licence' some 'software licence' with 'modelling software' 'has licence' some 'software licence'.

I am in favour of the second option.

[stap-m]

Option 2 will be inherited by software 'has license' some 'software license' anyway. However, the two options mean different things and are not interchangable from my point of view. Since model is discussed in several issues and might be reclassified sooner or later, I would be ok just with option 2 for now.

[l-emele]

Okay, then I'll do option 2.