Allow license property to link to other than LicenseDocument

[nicholascar]

In many ontologies that contain references to licenses, a property such as dcterms:license is used to link to a license document. ADMS links to a dcterms:LicenseDocument which is "A legal document giving official permission to do something with a Resource". ADMS' properties defined for a LicenseDocument are title, description & type.

These properties, and the intention of the dcterms:LicenseDocument, are for human actions however we would do well to better cater for machine actions, such as license type hierarchies (this is possible through dcterms:type for a dcterm:LicenseDocument but that's not its intention) and especially, nuanced evaluation of license' requirements.

Creative Commons already implements an RDF class model (https://creativecommons.org/ns) that includes classes of item that such as Requirement and Prohibition that can be used to make a license that is a collection of objects and this better allows for machine actions. I have previously extended this work with a methodology for machine handling of some license Requirements in an Agreements Ontology, see the example about what Agreements (license is a subclass) make Agents do.

If we allow datasets to indicate a license that is not just a LicenseDocument or, if it is, it is an extended version of dcterms:licenseDocument with element classes and properties, then we can allow for machine handling.

We need not exclude linking datasets to just LicenseDocuments but should encourage object use, not document use.

[aisaac]

Hi @nicholascar I agree this is an important issue, but maybe the solution is not at the license level - or one that's called 'license' even though it could mean something else...

I mean, the mechanism for machine-readable rights is probably going to be the same for rights that qualify as licenses, and for other types of rights statements (some of your agreements, ODRL's policies, CC's Public Domain).
I work for an initiative that use dcterms:rights and dcterms:RightsStatements as 'anchors' for machine-readable rights.

The ODRL itself has moved away from refering too prominently to dcterms:license and they coined a new property odrl:hasPolicy as better alternative for direct asset-policy links.

In practical terms, I guess my first proposal is to reword the issue and then have the discussion on the technical solution :-)

[makxdekkers]

The title of the issue makes an illegal suggestion. The range of dct:license is dct:LicenseDocument as formally defined by DCMI. We can't change that, so if you want to link a resource to something that is not a dct:LicenseDocument, you need a different property.

[nicholascar]

@makxdekkers: The title doesn't say dct:license for that reason, just "license property" but I do understand that people often use the dct property for indicating licenses.

[aisaac]

@nicholascar ah so the issue could be about creating or re-using another property? It wasn't clear from the use of "allow" and the description. Now it makes more sense!

But I'd still be worried that we use a constructs that hints at licenses only, as more general rights statements should be in scope. And again I believe this is your perspective too with your notion of 'agreement'. We should be careful about not ending like CCrel's cc:License, which is called 'license' but has a broader scope, quite confusingly for users of the vocabulary.

[nicholascar]

The ISO19115 standard has "constraints" including "legal constraints" which are "restrictions and legal prerequisites for accessing and using the resource or metadata". In the Agreements Ontology I declare an Agreement as a superclass of License to allow it to include both restrictions like Licenses and laws and also things like MoUs, etc. that enable greater access to things.

ISO also includes "security constraints" which are "...restrictions imposed on the resource or metadata for national security or similar security concerns", again, Agreements would be able to include those kind of constraints.

Agreements are really just collections of Requirements which can be restrictive ("must not be used for commercial purposes") or enabling ("users part of Initiative X can access copies of this dataset for free") and part of the goal of breaking Licenses and broader Agreements into Requirements is so that at least some of them can be handled by catalogue systems automatically.

[dr-shorthair]

Interestingly, ISO 19115-1 also makes the distinction between 'accessConstraints', 'useConstraints' and 'otherConstraints' - all aspects of MD_LegalConstraints. Then the first two of these are required to select a member of a list of RestrictionCodes which appears to mix together a few concerns that might be grouped separately -

[dr-shorthair]

The ontological commitment of the range of dct:license does not appear onerous.

dct:LicenseDocument is a subclass of dct:RightsStatement, which is just an rdfs:Resource. So use of dct:license merely says that the thing that it points to is classified as LicenseDocument from the viewpoint of DCMI worldview, which does not appear to add any problematic entailments, or in particular to exclude the use of another more specific representation of rights (ODRL anyone?).

[aisaac]

Actually this is one of the rare domain/range assertions that may hurt, especially in the context of Web Architecture and Linked Data recipes.

A lot of 'modern' applications would like to encourage to use resources that stand for the licenses or statements as social constructs or contracts or policies, not pieces of paper or HTML pages.

To use a concrete example, it is desirable to use a property that can be used
with http://creativecommons.org/licenses/by-sa/4.0/
not with https://creativecommons.org/licenses/by-sa/4.0/deed.en
or
with http://rightsstatements.org/vocab/InC-EDU/1.0/
not with http://rightsstatements.org/page/InC-EDU/1.0/?language=en

[dr-shorthair]

@aisaac I don't quite follow what you are saying.
I understand the difference between the resource http://creativecommons.org/licenses/by-sa/4.0/ and a particular serialization of it such as https://creativecommons.org/licenses/by-sa/4.0/deed.en .
But it looks like you might also be inferring something from the names dct:LicenseDocument and dct:RightsStatement that concerns you. Can you spell that out a bit more?

[aisaac]

I mean that the name and semantics of dct:licenseDocument are such that currently it makes sense to use it with https://creativecommons.org/licenses/by-sa/4.0/deed.en

If we use it with http://creativecommons.org/licenses/by-sa/4.0/, then one can entail that
http://creativecommons.org/licenses/by-sa/4.0/ is a dct:LicenseDocument. But that doesn't sound very right when the license document in reality is https://creativecommons.org/licenses/by-sa/4.0/deed.en

And yes, anyway all the initiatives I know, including CC itself, would recommend using http://creativecommons.org/licenses/by-sa/4.0/ over a specific license document URI. I'm not saying that it's wrong to use license document URI in every case. But certainly in the DCAT cases, I don't see much value in focusing on the license document URI.

I think all this is very much in agreement with what @nicholascar has described in the original issue description. I would prefer that we don't use dct:license with its current semantics.

Is it clearer now?

[dr-shorthair]

(Thanks @aisaac - that fills in the elisions.)

[dr-shorthair]

Meeting 2018-02-28 had 1/2 hour discussion on this issue.
https://www.w3.org/2018/02/28-dxwgdcat-minutes.html#item08
Main concern is that, while there are almost no significant entailments from dct:LicenseDocument, the definition says "A legal document giving official permission to do something with a Resource." within which the words 'legal' and 'document' may both lead to certain expectations by some users.
Most on the call thought that these issues could probably be ignored, but we should be alert to the fact that some in the DCMI community might feel different.

Also was suggested that we clarify from ODRL whether they considered use of ODRL document as a 'dct:LicenseDocument' was OK.

Also was noted that, while dct:rights and dct:license are both mentioned in DCAT, dct:accessRights is not.
Maybe needs to be added?

[aisaac]

Trying to contribute... I'm really in favor of using dct:rights or anything that wouldn't require contortions in the interpretation, as we would have to do with dct:license. Worst case, it's easier to say that we define an 'application profile' of DC :-) by saying that we want to use dct:rights with URIs of licenses - or a new subproperty of dct:rights than saying that we use dct:license with an interpretation that's wider than its original semantics.

Note that ODRL uses odrl:hasPolicy to link an asset to a Policy (which would represent a rights statements or a license): https://www.w3.org/TR/odrl-model/#policy-has
Note that the genesis of the property is documented at w3c/poe#184
(maybe this can help @makxdekkers @andrea-perego who took actions in the meeting yesterday).

[makxdekkers]

Thanks @aisaac. I am trying to understand the implications of the discussion at w3c/poe#184 but must admit it looks complex. However, the answer to our questions may already be in the discussion there, so I'll study it in detail before contacting the ODRL people. If I have questions, I might direct them to @aisaac who was the driver of the discussion over at ODRL.