search

rightsstatements / data-model

rightsstatements.org data model
http://rightsstatements.org/vocab/1.0/
Creative Commons Zero v1.0 Universal
12 stars 3 forks source link

Class for statements - dependency from property domain #37

Open anarchivist opened 8 years ago

anarchivist commented 8 years ago

cc:prohibits and others used in @escowles's examples may have domain cc:License. This may be an issue if we want to change the class of the statement.

Right now the issue may be less urgent as we are not using cc:prohibits and the likes in our data about statements. But if we need to describe statements in more details (e.g. for NoC-NC)

anarchivist commented 8 years ago

@aisaac:

My position is that we should just not care. Especially as long as there is no disjointness between statements. I.e. a resource can be both a dcterms:RightsStatement and a cc:License (and a skos:Concept) at the same time.

anarchivist commented 8 years ago

@musebrarian:

My main concern here is that there is a danger that implementers will be confused that these are licenses equivalent to the cc licenses (despite what's been said elsewhere). I'm happy to let licenses be licenses, but am hesitant about treating RightsStatements and cc;Licenses as equivocal classes (I think, dcterms:RightsStatements is a broader class that would include cc:License).

I am most happy just saying these are skos:concepts that classify existing statements and licenses (that are typed elsewhere).

anarchivist commented 8 years ago

@no-reply:

cc:License is a subclass of dcterms:LicenseDocument, which is skos:narrower than dcterms:RightsStatement. So while they are definitely not disjoint, I share Richard's concern.

Beyond the concern that implementers may be confused, I worry that we would in fact be making the wrong assertions. My take is that the appropriate response is to introduce a super-property of cc:prohibits with a broader domain. I realize this puts us in the business of vocabulary management, but I suspect that is inevitable.

anarchivist commented 8 years ago

@aisaac:

dcterms:LicenseDocument is a subclass of dcterms:Rightstatement, not a skos:narrower. So we're really safe on the disjointness side. So, we'd end up having some resources more specifically typed after one has used cc:prohibit. Given the fact that cc:License is fuzzy anyway (as we've discussed a while ago, it could well have been a rather ok choice for us instead of dcterms:Rightstatement, as it applies to CC's PDM too) I would really not bother about all this...

anarchivist commented 8 years ago

@no-reply:

my understanding was that dcterms:LicenseDocument is clear about its instances being official legal documents, and that (at least some of) our statements do not qualify. I think this is why we moved away from using dcterms:LicenseDocument to begin with, yes? If we really think that LicenceDocument, or the cc: subclass is a fine choice, I would advocate that we use it.

anarchivist commented 8 years ago

@aisaac:

I'm still ok with not choosing the specific cc:LicenseDoc for our RSs. I was just reacting to your comment about cc:LicenseDoc being a skos:narrower of dcterms:RS, which could have raised doubts about the (non)disjointness of both. But as they are a in a "real" subclass link they are not disjoint, and thus I'm even more comfortable with my "I don't care" approach at the beginning of this thread.

anarchivist commented 8 years ago

@no-reply:

To make sure this gets resolved: The concern I'm expressing is not that the relevant classes are disjoint, but that only the broader one applies. The current draft of the [color] paper reflects this.

My concern isn't that using cc:prohibits, etc... is inconsistent, but that an interpretation that takes the descriptions in dcterms at face value will make that graph "false".

Less technically, I think it may be appropriate that cc:prohibits has a license as a domain; i.e. what it means for a quasi-legal "rights statement" to "prohibit" something might require different sense of "prohibit" than is used with a binding legal instrument.

I'm not strongly blocking the "don't care" approach, but I want to make sure we're talking about the same issue. :)

anarchivist commented 8 years ago

@aisaac:

We use different words, and might have change along the thread, but I think we're talking about the same issue :-)

I'm trying to put the latest elements of the discussion in the text, rather than in this long thread. And my answer. Hopefully I'll have captured your worries, and you can comment in a fresh new thread on my answer!