Principle 1 (fp-open) requests using rdfs:comment for rights statement

[hlapp]

While not obviously wrong, is there a good reason not to recommend dc:rights, which seems made for this purpose?

My concern here is machine-interoperability. It's hard for a machine to intuit that a rdfs:comment metadata annotation is one about intellectual property rights rather than just some random commentary. A well-behaved machine that, for example, facilitates interaction with a user, or collates rights statements from across a database of integrated ontologies, would be much better enabled to do the "right" thing if a rights statement were properly flagged as such. After all, we do that for the URI of the license too (as opposed to, say, using dcterms:relation).

[cmungall]

I think it's suggesting both an explicit property and a comment for the OWL, and a remark for .obo

I think we should follow DRY and have a single annotation assertion using whatever is more appropriate (dc right vs license, what's the difference?) and ditch the comment.

The obo guidelines are confused. They should follow the OWL. I thought we had a PR for this but I guess not

[hlapp]

I do think a reasonable case can be made that there are two things that aren't the same and that are both useful to provide.

One is a link to the canonical (so that machines can recognize and possibly act on it) license declaration as a URI for a resource. That's what dcterms:license, cc:license, and dcterms:rights would be for. It seems reasonable to me as a recommendation to consolidate that to dcterms:license.

The other is a rights statement in prose, which is meant for human consumption, not machine consumption (but this still means that machines should be enabled to surface this to a human user, hence the argument against rdfs:comment.) This is what I argue dc:rights (not dcterms:rights) would be well suited for. This could, for example, repeat the synopsis of the rights reserved and rights granted by the license. It could also include expectations for attribution, and for when the ontology or terms from it are reused. For OBO ontologies, this could be boilerplated, as presumably such expectations will intentionally be somewhat uniform across the board.

I'm certainly highly in favor of the DRY principle. However, for license (or more generally rights) statements repeating yourself is already the vastly predominant convention, for example look at software source code.

[balhoff]

This is what I argue dc:rights (not dcterms:rights) would be well suited for.

In my opinion we should favor dcterms over dc. See discussion in this issue. Because of the very ambiguous semantics, it doesn't seem that useful to me to rely on fine distinction between rights in the dc namespace vs. dcterms namespace. However neither rights nor its subproperty license are meant to have literal values, so I don't have a good suggestion for a property for this. Since we use these as annotation properties, perhaps it doesn't matter.

[cmungall]

pinging @tombaker and @jonquet

[hlapp]

I know the distinction is not strongly articulated anywhere, but due to history, terms in the dc and in the dcterms namespaces are not treated synonymously by most consumers. Specifically, when using terms in the dcterms namespace that aren't dates and stuff, one should not put literals as their values. Conversely, dcterms terms should be used instead whenever the value is already known to be an (identifiable) resource. To generically favor dcterms over dc regardless of value type would run counter to how these are conventionally used in most information science fields.

[hlapp]

Was anything ever decided about this?

[nlharris]

Just wondering if this has been resolved.

[matentzn]

No, not resolved. While I agree that dc and dcterms are somewhat fuzzy on the data type range side, I am not entirely sure if we would want to use that ambiguity in OBO to allow literal ranges. In general, I would prefer if we pretend the dc and dcterms namespaces to be synonymous to make their harmonisation easier (translating back and forth between them), and always go with terms "semantics" (range constraints).

However, I do agree with @hlapp that recommending rdfs:comment is not ideal. I think dc:rights would be appropriate. I think despite the fact that I would generally like to avoid the above (using dc namespace to circumvent constraints), in this particular case I would agree with the suggestion of recommending dc:rights instead of rdfs:comment.

[alanruttenberg]

There's a minor risk in paraphrasing the rights statement. The language for the CC licenses has been carefully crafted. Is it too much of a stretch to think that people who want more information click the link? A

On Sat, Jan 1, 2022 at 6:48 AM Nico Matentzoglu @.***> wrote:

No, not resolved. While I agree that dc and dcterms are somewhat fuzzy on the data type range side, I am not entirely sure if we would want to use that ambiguity in OBO to allow literal ranges. In general, I would prefer if we pretend the dc and dcterms namespaces to be synonymous to make their harmonisation easier (translating back and forth between them), and always go with terms "semantics" (range constraints).

However, I do agree with @hlapp https://github.com/hlapp that recommending rdfs:comment is not ideal. I think dc:rights would be appropriate. I think despite the fact that I would generally like to avoid the above (using dc namespace to circumvent constraints), in this particular case I would agree with the suggestion of recommending dc:rights instead of rdfs:comment.

— Reply to this email directly, view it on GitHub https://github.com/OBOFoundry/OBOFoundry.github.io/issues/807#issuecomment-1003546707, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAB3CDQTSNYY5H5V576USKDUT3SZDANCNFSM4GLDIGCA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you are subscribed to this thread.Message ID: @.***>

[cmungall]

@matentzn won't be back for a few weeks.

OK this issue is confusing as over the years we have talked about two orthogonal things

1. dcterms vs dce
2. the value of including a supplementary textual comment paraphrasing the rights -- and if we want it, which property to use

We should not be talking about 1 any more, this is completely resolved. See #540. Re-open this if there is more to discuss here. But all existing checks assume dcterms not dce.

The remaining question is regarding 2.

As @alanruttenberg says, there is a minor risk in paraphrasing the rights statement. I agree, and as I said above

I think we should follow DRY and have a single annotation assertion using whatever is more appropriate and ditch the comment.

So I think we should recommend against, but not forbid. And if people really want to state this, I agree with Hilmar and Nico that dcterms:rights should be used, as it is explicitly designed for this.

Currently our guidelines are confusing.

https://obofoundry.org/principles/fp-001-open.html

The first part is very clear:

---

The license MUST be clearly stated using the http://purl.org/dc/terms/license property followed by the URL representing the license (e.g. https://creativecommons.org/licenses/by/3.0/) in the ontology file (OWL example).

But then things get muddied:

---

OBO Foundry Ontologies MUST specify the reuse constraints using the following annotations in any publically[sic] released OWL version of the ontology:

• dcterms:license - specifies the license - see Example 1 (below)

• rdfs:comment - specifies terms of reuse - see Example 1 (below)

The MUST is ambiguous. It could be mean that ontologies MUST always have an rdfs:comment stating terms of reuse. But I think the intent is to state that IF there are specific terms THEN rdfs:comment MUST be used.

In fact if we look at the implemented checks https://obofoundry.org/principles/checks/fp_001 we see comment is ignored.

Proposal

Let's keep this very simple.

Minor word changes:

---

The license MUST be stated using the http://purl.org/dc/terms/license property followed by the canonical URL representing the license (e.g. https://creativecommons.org/licenses/by/3.0/) in the ontology file (OWL example). Be sure to use the exact URL (e.g. include trailing slash).

Then add:

---

Ontologies MAY choose to include an additional textual summation of license terms. If present, this SHOULD use dcterms:rights, but these MAY be stated in an rdfs:comment

Possibly add a paremthetical note:

---

Many OBO ontologies have historically used rdfs:comment to state additional information on usage rights. We now recommend using dcterms:rights instead, if this is the intent. However, we prefer that neither is used and the license stands on its own, the CC licenses have been craefully crafted and there is minor risk in paraphrasing [refer to this ticket]

[alanruttenberg]

If the proposal is kept, typo: there is ^a^ minor risk. The question is, what if the description in dc:rights conflicts with the CC license, for instance adding additional conditions? Which wins? There is a place for one kind of comment, which is the manner of attribution. I don't recall if we legislate this as using the PURL. If not, then in order to prevent potential conflict, perhaps add something to the effect that dc:rights additional information MUST be limited to the manner in which attribution is requested. If we do legislate this then I don't see any benefit to adding extra text. I only see risk. A

On Tue, Jan 4, 2022 at 12:46 PM Chris Mungall @.***> wrote:

@matentzn https://github.com/matentzn won't be back for a few weeks.

OK this issue is confusing as over the years we have talked about two orthogonal things

1. dcterms vs dce
2. the value of including a supplementary textual comment paraphrasing the rights -- and if we want it, which property to use

We should not be talking about 1 any more, this is completely resolved. See #540 https://github.com/OBOFoundry/OBOFoundry.github.io/issues/540. Re-open this if there is more to discuss here. But all existing checks assume dcterms not dce.

The remaining question is regarding 2.

As @alanruttenberg https://github.com/alanruttenberg says, there is a minor risk in paraphrasing the rights statement. I agree, and as I said above

I think we should follow DRY and have a single annotation assertion using whatever is more appropriate and ditch the comment.

So I think we should recommend against, but not forbid. And if people really want to state this, I agree with Hilmar and Nico that dcterms:rights should be used, as it is explicitly designed for this.

Currently our guidelines are confusing.

https://obofoundry.org/principles/fp-001-open.html

The first part is very clear:

The license MUST be clearly stated using the http://purl.org/dc/terms/license property followed by the URL representing the license (e.g. https://creativecommons.org/licenses/by/3.0/) in the ontology file (OWL example).

But then things get muddied:

OBO Foundry Ontologies MUST specify the reuse constraints using the following annotations in any publically[sic] released OWL version of the ontology:

• dcterms:license - specifies the license - see Example 1 (below)
• rdfs:comment - specifies terms of reuse - see Example 1 (below)

---

The MUST is ambiguous. It could be mean that ontologies MUST always have an rdfs:comment stating terms of reuse. But I think the intent is to state that IF there are specific terms THEN rdfs:comment MUST be used.

In fact if we look at the implemented checks https://obofoundry.org/principles/checks/fp_001 we see comment is ignored. Proposal

Let's keep this very simple.

Minor word changes:

The license MUST be stated using the http://purl.org/dc/terms/license property followed by the canonical URL representing the license (e.g. https://creativecommons.org/licenses/by/3.0/) in the ontology file (OWL example). Be sure to use the exact URL (e.g. include trailing slash).

Then add:

Ontologies MAY choose to include an additional textual summation of license terms. If present, this SHOULD use dcterms:rights, but these MAY be stated in an rdfs:comment

Possibly add a paremthetical note:

Many OBO ontologies have historically used rdfs:comment to state additional information on usage rights. We now recommend using dcterms:rights instead, if this is the intent. However, we prefer that neither is used and the license stands on its own, the CC licenses have been craefully crafted and there is minor risk in paraphrasing [refer to this ticket]

— Reply to this email directly, view it on GitHub https://github.com/OBOFoundry/OBOFoundry.github.io/issues/807#issuecomment-1005036591, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAB3CDRV33EQ6H23XFCNVLDUUMW6TANCNFSM4GLDIGCA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[matentzn]

I agree with @alanruttenberg.. I am not at all clear on the value of adding rights statements which may conflict with the license. According to dublin core, license is a subroperty of rights, and should therefore "inherit all its properties". I would like to hear one or two advocates for a separate rights statement before applying your (otherwise sensible) suggestion @cmungall. But I am also not too concerned here.

[kltm]

As a data point, for the https://reusabledata.org rubric, from what I'm reading here, I think that how users would likely interpret the formulate that Chris gave would likely give results that we would be able to score without too much trouble. I might suggest encouraging users to not to add additional text unless it was something useful or professional. For example, I can imagine a lay summary of some CC licenses could introduce statements that are not consistent with the license.

if the comments section was merely doing something like clarify the method of attribution for CC, that would probably be evaluated consistently. If there were inconsistent/conflicting licensing statements introduced the resource would be marked as "inconsistent" and score very low (the rationale is that once it becomes necessary for lawyers or site counsel to get involved to understand how a license could be interpreted given a particular legal/jurisdictional context that wheels have already flown off the cart).

[matentzn]

Thank you @kltm, what you are saying is convincing, and I would perhaps tweak the @cmungall suggestion towards that a bit..

[jonquet]

Sorry if I missed some aspect of the discussion here. We reviewed several properties for "licensing and rights" when doing MOD1.4

dct:license => A legal document giving official permission to do something with the resource.

dct:accessRights => Information about who can access the resource or an indication of its security status.

Typically we can expect an URI for the value of dct:license and a string as the value of dct:accessRights Where the former property is supposed to unambiguously refer to a clearly identified license the latter property is here to express in natural language anything that is not explicit in the generic license description.

@matentzn "I am not at all clear on the value of adding rights statements which may conflict with the license." => This situation may occur with any property. The coherence between property values is an hard issue in the RDF world, almost impossible to check automatically (even if rules of shapes) especially when one value is a string.

[alanruttenberg]

It's true that validating a string is not going to happen. But the way to avoid that is to not say anything at all. Everything except for how OBO asks for attribution is specified by the license. Perhaps have a standard value: "The preferred method of attribution is to use the OBO PURLs directly." Not really a rights statement - that's taken care of by the license. Or: The standard value could be the summary given on the CC license page.

On Wed, Jan 19, 2022 at 8:28 AM Clement Jonquet @.***> wrote:

Sorry if I missed some aspect of the discussion here. We reviewed several properties for "licensing and rights" when doing MOD1.4

dct:license => A legal document giving official permission to do something with the resource.

dct:accessRights => Information about who can access the resource or an indication of its security status.

Typically we can expect an URI for the value of dct:license and a string as the value of dct:accessRights Where the former property is supposed to unambiguously refer to a clearly identified license the latter property is here to express in natural language anything that is not explicit in the generic license description.

@matentzn https://github.com/matentzn "I am not at all clear on the value of adding rights statements which may conflict with the license." => This situation may occur with any property. The coherence between property values is an hard issue in the RDF world, almost impossible to check automatically (even if rules of shapes) especially when one value is a string.

— Reply to this email directly, view it on GitHub https://github.com/OBOFoundry/OBOFoundry.github.io/issues/807#issuecomment-1016465891, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAB3CDRNMNYQLP6B74UFYJ3UW237LANCNFSM4GLDIGCA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>