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.

[makxdekkers]

From my reading of the discussion at w3c/poe#184, I understand that the conclusion was that, in general, dct:license cannot always be used to link to a odrl:Policy and that the more general approach is to use odrl:hasPolicy.

The reason is that odrl:Policy is defined as "a non-empty group of Permissions [...] and/or Prohibitions [...] and/or Duties[...]" while dct:LicenseDocument is defined as "a legal document giving official permission to do something with a Resource". So a dct:LicenseDocument is only about permissions while an odrl:Policy can also contain prohibitions and duties/obligations.
Therefore, the use of the property dct:license to link to an odrl:Policy is only valid if that odrl:Policy only contains permissions.

Based on this, my proposal is that we follow the conclusion that odrl:hasPolicy should be used if the object is an odrl:Policy.

However, I would not extend that conclusion to the use of dct:license to link to Creative Commons licences. Even if Creative Commons licences are not only about permissions, they are widely used as the object of dct:license. For example, CC-BY-NC-ND contains permissions (You are free to), prohibitions (You may not) and obligations (You must), which would not allow it to be used as the object of dct:license, according to the conclusion in the ODRL discussion.

I don't think it makes sense for DCAT to declare that practice invalid and say that everybody is doing it wrong.

[aisaac]

Hi @makxdekkers this is a good reading of the ODRL discussion, but I think it's incomplete in the sense that it wasn't only about a matter of permissions/duties/restrictions but also about whether a rights statements can legally count as a license of not.

Using dct:license has two drawbacks to me, with different levels of problems:

• The first is the fact that dct:license targets documents and not statements. If we say that dct:licenses can be used with licenses and not license documents, then we're blessing the practice of using it with a slightly different semantics than DC's one. I'm actually fine with this (rather than saying that everyone else is wrong) but we probably should have a small caveat in our specs then.

• the next issue is whether we allow the use of dct:license with non-license resources like all the ones at http://rightsstatements.org/en/statements/ or with instances of odrl:Policy in general. This would be a big change to the DC semantics. In fact I am not sure that you are suggesting this. Are you?
  But if you are not, then we're left with the issue of having in DCAT both a dct:license and a property to link to non-licenses (dct:rights, or odrl:hasPolicy). Would having two such options be alright?
  Or should we have DCAT rights strictly restricted to legal licenses (which is probably acceptable but I cannot see all implications of this)?

[makxdekkers]

@aisaac I have not gone into the question whether a rights statement can legally count as a licence. I am not a lawyer so I can't say anything about that.

To be honest, I don't understand your first bullet point about dct:license targeting documents and not statements. As far as I see it, there is a very fine line between "document" and "statement". An unwanted effect of a caveat could be that people read it as "you've been doing it wrong", so it would need to be carefully worded.

On the second bullet point, I think my proposal was clear, saying that the odrl:hasPolicy should be used if the object is an odrl:Policy, so not using dct:license in that case. For linking to the rightstatements.org resources, would your suggestion be to use dct:rights in that case? After all, the definition of dct:rights is "Information about rights held in and over the resource", or as the Usage note in DCAT states: "dct:license, which is a sub-property of dct:rights, can be used to link a distribution to a license document. However, dct:rights allows linking to a rights statement that can include licensing information as well as other information that supplements the licence such as attribution". Sounds clear to me.

[aisaac]

@makxdekkers I'm not a lawyer but I've heard pretty clearly that many of the things that I would have a couple of years ago considered to be ok for dct:license are actually not licenses and as a member of rightsstatements.org I have to echo this concern.

On the first point, my proposal is not that the caveat could be understood as people doing it wrong. On the contrary, it would be a blessing for ignoring the strict semantics of DC - i.e. people can continue doing as they can even if some people tell that DC has a slightly different semantics for the property.

For the first point, I had understood your proposal actually. And to me either dc:rights or odrl:hasPolicy would be ok (if ODRL still considers that odrl:hasPolicy can be seen as a superproperty of dct:rights). I just want to make sure that the others on this thread are ok with having DCAT rely two properties.

[makxdekkers]

@aisaac Understood.
One point about the two properties: DCAT already has both dct:license and dct:rights included. I guess the issue would be whether we would want to add yet another, namely odrl:hasPolicy. In the ODRL discussion a point was made that ODRL Policies may include things that are not rights. If ODRL Policies are always about rights, then use of dct:rights would be fully appropriate; if not, odrl:hasPolicy is the only general way to link to a policy.

[aisaac]

Do we have use cases for non-rights policies in general? If not, then dct:rights is still alright.
@makxdekkers indeed if we have use cases for ODRL policies in general then we'd have to go for odrl:hasPolicy

[dr-shorthair]

Can this be turned into a concrete proposal?

[dr-shorthair]

Can we verify if ODRL overlaps the scope of DCAT in any other ways? Or will we just adopt some narrow parts of ODRL?

[nicholascar]

I will:

• make a concrete proposal for adoption of part of ODRL
• ensure that the proposal both formally and informally relates proposed future use (hasPolicy) and current use (license, rights), perhaps using a general property + qualification pattern
• scan all other issues to see if adoption of further ODRL, since we will have adopted a part of it here, will satisfy them

[dr-shorthair]

DCAT recommendation should be generally to use a standard license, in preference to a bespoke license expressed in ODRL ...

[nicholascar]

I will:

• present a dataset to this group that contains several common license (CC-BY, MIT, GPL and a non-open counter example) broken down into their Requirements (as per CC ontology) and other components

This will allow for more machine-readable use of common licenses

[makxdekkers]

@aisaac I agree that we should not imply that all CC statements are licences, so text could say something like "for example, licences defined by Creative Commons".
Good point that there are no Use Cases that lead to a requirement for ODRL policies. If there are none, maybe we should drop the issue?
Not saying anything in DCAT does not stop anyone asserting a relation with an ODRL policy for a Dataset or Distribution, so the point could be moot.

[nicholascar]

In Australia we have several initiatives of government that apply rules to items in catalogues that would be best described as ODRL policies, not licenses, which motivates the use of odrl:hasPolicy.

One current example is a catalogue that is storing data generated within a project but which is only released publicly after some time. So the Use Case is:

"I am a catalogue manager and I want to encode notes on data publication permissions being enabled 6 months after dataset creation. I want to use the primary catalogue model (DCAT) rather than auxillory recording system"

This could be recorded something like this:

:Dataset_X dcat:distribution [
  dct:license <http://linked.data.gov.au/license/CC-BY-4.0> ;
  odrl:hasPolicy [
    a odrl:Policy ;
    rdfs:label "Access to data granted 6 months after lodgement" ;
    odrl:permission [
      odrl:action [
        ...define the publishing action...
      ] ;
      odrl:constraint [
        odrl:leftOperand xsd:dateTime ;
        odrl:operator "gt" ;
        odrl:rightOperand :Dataset_X_created_date + :6_months
      ]
    ]
 ]

Note that this is example is close to an ODRL Best Practice case http://w3c.github.io/poe/bp/, Example 1.2B

[andrea-perego]

Thanks for the example, @nicholascar .

As requested during today's call of the DCAT subgroup, I include a pointer to the Open Data Rights Statement (ODRS) vocabulary designed by @ldodds , which could be relevant to this discussion.

Consider the following (quite common) scenario:

I have two resources, both using CC-BY, but with different attribution and copyright notices. Attribution and copyright notice are clearly not part of the licence (CC-BY). So, where can I specify this information, and how can I link it to the relevant resource and its licence?

The ODRS approach is to attach attribution and copyright notice to a dct:RightsStatement (by using ad hoc properties), and then link the dct:RightsStatement to both the resource and the licence - which are also directly linked via dct:license. The diagram included in the ODRS specification gives a clear picture of this pattern.

Note that ODRS addresses also other requirements - e.g., rights jurisdiction, being able to specify licence compatibility, having different licences/rights for a database and its content (about this, see the notion of sui generis database rights). More details are provided in the documentation accompanying ODRS:

• the use cases behind its design
• the publishers' guide
• the re-users' guide

[stijngoedertier]

From the example of @nicholascar, I understand that ODRL is capable of expressing advanced permission, prohibition, and obligation statements that stem from licenses or policies in general. I wonder whether there is also a formal semantics (some temporal deontic logic) that would enable reasoning and apply these rules to a given situation.

Thinking of use cases / requirements, I think it would be important for many for publishers and users if the following information can be easily obtained from the metadata:

• license fee: whether a license fee must be paid (perhaps not specifying the amount of that fee, which may also be dependent on the status of the user).
• attribution text: whether attribution must be given and which text must be used when attributing.
• commercial use: whether commercial use is allowed.
• share-alike: whether derivative works must be shared under the same license conditions.
• reserved names: whether there is a prohibition to use the name of the publisher/owner when communicating about derivative works (e.g. as an implied endorsement).

As @aisaac pointed out, the use cases and requirements document does not include new requirements for license properties / usage constraints / access constraints. Would it still be possible to propose a use case for this?

[ldodds]

The proposal from @makxdekkers is consistent with the approach I took with the ODRS vocabulary. I'd like to second the point that @makxdekkers made earlier in the thread too: there is existing widely used practice to use dct:license to refer to licences, from CC and others. This group shouldn't make that incorrect.

What also shouldn't get overlooked is the benefits of consistent use of well-known URIs for licences, e.g. the CC suite, in making it easier for both human and machine consumers to easily identify licences. Encouraging convergence on use of standard licences is a much better outcome for data ecosystems, than use of bespoke terms.

As ODRL provides terms for those, it makes sense to suggest their use in scenarios where publishers cannot or will not use standard licences.

As @andrea-perego highlighted the ODRS vocabulary was created to allow for machine-readable provision of additional metadata, like attribution text, which is important for consumers to be able to readily access. We have built in support for this in Open Data Certificates certificates.theodi.org.

[aisaac]

@makxdekkers ok this sounds good.

About ODRS' 'statements', I wanted to point out that ODRL allows a similar function by having a Policy that stands for the general license/statement (e.g. CC-BY - NB the Policy would be the CC license itself in this case) and a 'derived' policy that carries the attribution and other characteristics for the 'policy-at-the-level-of-the-asset'. We're probably going to use this for implementation of some of the statements at RightsStatements.org

[nicholascar]

@aisaac could you please flesh out the example you hint at above about "a 'derived' policy that carries the attribution and other characteristics for the 'policy-at-the-level-of-the-asset'"?

Do you mean something like this made-up example using a custom text attribution for a CC-BY dataset:

:Dataset_X dcat:distribution [
  dct:license <http://test.linked.data.gov.au/dataset/odrl-policies/policy/cc-by-4.0> ;  # a test ODRL version of CC-BY 4
  odrl:hasPolicy [
    rdfs:label "Specific Attribution for Australian Government" ;
    rdfs:comment "Users of this dataset must attribute it in this specific way"@en ;
    odrl:duty [
        odrl:action  odrl:attribute ;
        odrl:attributedParty <http://australia.gov.au> ;
        # property following on from Leigh's ODRS property of this name
        xxx:attributionText "This dataset is proudly brought to you by the Australian Government, you're welcome!"@en ;
    ]
  ]
]

Do you mean to overload the Asset with both a stnadard license and extra conditions in paralell, as above.

Or, do you mean to indicate some derivation relationship from the policy requiring custom attribution and the general CC-BY license perhaps like this:

:Dataset_X dcat:distribution [
  odrl:hasPolicy [
    prov:wasDerivedFrom <http://linked.data.gov.au/license/CC-BY-4.0> ; or some other derivation relationship
    rdfs:label "Specific Attribution for Australian Government" ;
    rdfs:comment "Users of this dataset must attribute it in this specific way"@en ;
    odrl:duty [
        odrl:action  odrl:attribute ;
        odrl:attributedParty <http://australia.gov.au> ;
        # property following on from Leigh's ODRS property of this name
        xxx:attributionText "This dataset is proudly brought to you by the Australian Government, you're welcome!"@en ;
    ]
  ]
]

I gather there are several ways one might add additional conditions to CC licenses but I'm really interested to hear more about your proposal.

[dr-shorthair]

Is anyone willing to summarize the consensus in the document here: https://w3c.github.io/dxwg/dcat/#Property:catalog_license and https://w3c.github.io/dxwg/dcat/#Property:distribution_license ?

[aisaac]

@nicholascar I'm awfully sorry I didn't see your tag earlier :( If it still can help, what I meant was rather in the line of your second pattern. And ODRL even has a property for this: odrl:inheritFrom. In Europeana we have an example of this for some of our rights statements: https://pro.europeana.eu/files/Europeana_Professional/Share_your_data/Technical_requirements/EDM_Documentation/EDM_Mapping_Guidelines_v2.4_102017.pdf p50 (in RDF/XML, unfortunately) ``` <edm:WebResource rdf:about="http://example.org/aPieceOfMedia"> <edm:rights rdf:resource="#statement_3000095353971"/> </edm:WebResource> <cc:License rdf:about="#statement_3000095353971"/> <odrl:inheritFrom rdf:resource=“http://rightsstatements.org/vocab/NoC‐NC/1.0/”/> <cc:deprecatedOn rdf:datatype=”http://www.w3.org/2001/XMLSchema‐datatypes#date”>2029‐06‐01</cc:deprecatedOn> </cc:License> ``` This says that the license that prohibits commercial use will expire in 2029. The cc:License could be replaced by another type of odrl:Policy I guess. But our Europeana practice is designed that we've used cc:License.

[VladimirAlexiev]

Range reasoning often leads to onerous inferences.
But please don't give up using dct:license just because of that. Next should we give up on dct:language etc etc?
Just don't load Dct and you'll be fine :-)

[agbeltran]

Coming back to this issue and reiterating the proposal by @makxdekkers included above and also on the mailing list in a couple of occasions to see if we can get to an agreement and resolve it:

https://lists.w3.org/Archives/Public/public-dxwg-wg/2018Apr/0081.html
https://lists.w3.org/Archives/Public/public-dxwg-wg/2018Sep/0297.html

1. use dct:license to refer to licences like Creative Commons

2. use dct:rights to refer to rights statements that are not licences, such
   as copyright statements

3. use odrl:hasPolicy for linking to ODRL policies

[agbeltran]

As discussed in the meeting today (https://www.w3.org/2018/10/04-dxwgdcat-minutes.html), we are accepting @makxdekkers proposal on dealing with this issue. Just as a note, @andrea-perego suggested we might want to specialise the case of dct:accessRights in the future.

For now, @makxdekkers will provide a PR to resolve this issue.

[agbeltran]

Addressed in #442