Should gist:license be an object property?

[pmcb55]

Should gist:license be an object property?

Today we have:

<https://ontologies.semanticarts.com/o/gistCore> a owl:Ontology;
    owl:versionIRI <https://ontologies.semanticarts.com/o/gistCore11.0.0>;
    skos:definition "gist is a minimalist upper ontology created by Semantic Arts.";
    skos:prefLabel "gist";
    gist:license "https://creativecommons.org/licenses/by-sa/3.0/".

...instead, should we have:

    gist:license <https://creativecommons.org/licenses/by-sa/3.0/>.

...since that license IRI, when de-referenced, does indeed return RDF that is specifically typed as being of rdf:type Creative Commons cc:License, i.e., if you de-reference that IRI, you get:

@prefix cc: <http://creativecommons.org/ns#> .
@prefix dc: <http://purl.org/dc/terms/> .
@prefix ns0: <dct:> .

<http://creativecommons.org/licenses/by/4.0/>
  a cc:License ;
  dc:creator <https://creativecommons.org/> ;
  ns0:creator <https://creativecommons.org/> ;
  dc:title "Attribution-ShareAlike 3.0 Unported" ;
  ns0:title "Attribution-ShareAlike 3.0 Unported" ;

As an alternative (e.g., for licenses only described as HTML, and not as RDF at all), vocab creators might choose to use:

    gist:license "http://www.opendatacommons.org/licenses/pddl/"^^xsd:anyURI .

...where we are saying that the license is provided by that string literal, which is an IRI, but it isn't expected to return RDF (it just happens to return HTML only, in this case).
...although allowing both forms of values for gist:license should be explicitly expressed by the gist:license property itself using gist:rangeIncludes to state all the expected/allowable value datatypes.

Personally, I'd suggest that the gist:rangeIncludes for gist:license be deliberately restricted to only RDF-returning IRIs (so that we maintain 'Turtles all the way down', as there are already good RDF resources for all the common licenses today).

[uscholdm]

@pmcb55 Very interesting observation and analysis. There is one problem, though...

gist:license "http://www.opendatacommons.org/licenses/pddl/"^^xsd:anyURI .

The object for an object property cannot be a literal. So maybe we have to keep it as a data property?

If you agree, then we can close this issue as not completed.

[pmcb55]

Hiya @uscholdm - so yeah, a while ago I spent a good bit of time looking into licenses expressed as RDF (as I definitely want to support those licenses being machine-processable, so that (one day!) we can have machines automatically check and enforce the policies expressed in those licenses).

But firstly, for gist I would definitely suggest making gist:license an Object property (but isn't it an annotation property right now (i.e., here)?). I'd do this specifically so that machines can follow-their-nose to at least find something expressed as RDF to communicate what the license might actually mean.

Secondly, it seems the license IRI you're using today (i.e., https://creativecommons.org/licenses/by-sa/3.0/) isn't returning very valuable RDF at all any more (i.e., no longer the somewhat descriptive Turtle I pasted into my original issue above). All I seem to get back now is this (I used EasyRDF Converter here - i.e., it seems to be just a tiny bit of pretty useless RDFa extracted from the HTML):

@prefix cc: <http://creativecommons.org/ns#> .

<https://creativecommons.org/licenses/by-sa/3.0/>
  a cc:License ;
  cc:requires cc:Notice .

So one very encouraging recent effort I came across was from the Data License Clearance Center (DALICC), which is "...is a software framework that supports the automated clearance of rights thus supporting the legally secure and time-efficient reutilization of third party data sources."

These folks have engaged legal experts from the very start, with a view (as I understand it) to being able to demonstrate machine-verifiable legal licensing compliance with the strict European Data Protection legislation (i.e., GDPR).

But (as so often seems to be the case with Linked Data), the work on DALICC seems to have stalled. I raised a minor issue on their GitHub repo a year ago, but I got no response (although I did meet the creators at the SEMANTiCS conference in Leipzig this Summer, and yeah, they are still looking for research funding to pick up development of DALICC again).

Regardless, to help support their work and to demonstrate how I think software/data licenses should work, I switched all my license references to use the licenses in DALICC's library - e.g., for MIT I currently use <myVocab> dcterms:license <https://dalicc.net/licenselibrary/MIT> . (although it seems nowadays that they only return JSON-LD, even when I explicitly ask for Turtle, i.e., curl -H "Accept: text/turtle" -L https://dalicc.net/licenselibrary/MIT - d'oh!).

So anyway, I'd totally understand if you didn't want to flip to DALICC licenses (yet!), but at the very least I think I would make the gist:license an OWL Object property to communicate the intent that licenses should be machine-processable (and indirectly, therefore expressed as RDF). And I'd look into asking the Creative Commons folks if they need to 'fix' the RDF they return for their ShareALike-3.0 license!

[uscholdm]

I would make the gist:license an OWL Object property to communicate the intent that licenses should be machine-processable (and indirectly, therefore expressed as RDF).

That would preclude your example:
gist:license "http://www.opendatacommons.org/licenses/pddl/"^^xsd:anyURI .

How would you handle that?

[pmcb55]

Yeah, sorry - that example I gave was misleading and confusing (i.e., I was just trying to show an example of an IRI for a license that only returns HTML today (i.e., no HTTP-content-negotiable RDF at all)). I think we'd all agree that linking to non-RDF resources isn't really that helpful when there are RDF equivalents already available out there (such as the Creative Commons license resources, or the DALICC license resources (e.g., MIT license)). So I shouldn't have drifted off into talking about non-RDF license resources really, but it's just that today the current rdf:type of gist:license is owl:AnnotationProperty, i.e., just just lowly Literals, as opposed to machine-follow-able IRI's).

So let me start again.

Here's the current definition of gist:license (here):

gist:license
	a owl:AnnotationProperty ;
	skos:definition "An annotation for providing the licensing on this or derivative ontologies"^^xsd:string ;
	skos:prefLabel "license"^^xsd:string .

All I'm proposing is that it be 'upgraded' to an Object Property, and it's applicability (as expressed in it's skos:defnition) be broadened beyond 'ontologies', and maybe adding some helpful rangeIncludes triples, just for good measure, e.g.:

gist:license
	a owl:ObjectProperty ;
	skos:definition "The license applicable to something, or anything derived from it."^^xsd:string ;
	skos:prefLabel "license"^^xsd:string ;
        gist:rangeIncludes 
            dcterms:LicenseDocument ,
            cc:License , # cc:License is actually an rdfs:subClassOf dcterms:LicenseDocument.
            odrl:Set . # Support W3C standard ODRL-defined machine-processable 'Polices', so that permissions, prohibitions, duties, etc. can be automatically expressed, checked, enforced, etc. by machines (for example, see [DALICC](https://www.dalicc.net/)).

You can still use the same license value for gist - you'd just change it's use from this today:

	gist:license "https://creativecommons.org/licenses/by-sa/3.0/"^^xsd:string ;

...to be this 'better' alternative:

	gist:license <https://creativecommons.org/licenses/by-sa/3.0/> ;

(Although, just to note that the CC BY_SA license has moved to v4.0 now, and they "...strongly recommend the use of the 4.0 license instead" - just click on link itself).

[rjyounes]

@pmcb55 We cannot use dcterms:LicenseDocument because it is an rdfs:Class. This would make gist non-OWL 2 DL compliant.

We plan to switch to version 4.0 of the CC license in gist 13.0.0. See #244.

I agree with making gist:license an object property.

[uscholdm]

I'm leaning towards leaving it as an annotation property, for the sake of simplicity and flexibility. Annotation properties can take literals or individuals as values. So one can point to an IRI which is a named individual, or one can point to a literal of type anyUri or one can point to a string which describes the license.