mapping Rights (of Image or Object)

[VladimirAlexiev]

This is all wrong.

  ?image crm:P104_is_subject_to ?right .
  ?right a crm:E30_Right .
  ?image crm:P67i_is_referred_to_by ?rights_statement_class .
  ?rights_statement_class a crm:E33_Linguistic_Object ;
    crm:P2_has_type <http://vocab.getty.edu/aat/300055547> ;
    rdf:value ?rights_statement .

You say there's some Right over the image, but provide no info about it; then say there's some Linguistic Object but it;s not related to the right. Should be like this:

  ?image crm:P104_is_subject_to ?right .
  ?right a crm:E30_Right 
    # crm:P2_has_type # pick a license from creativecommons.org or rightsstatements.org
    crm:P3_has_note ?rights_statement .

[azaroth42]

You're right that it's wrong ... but not because the model is, because this should be two separate features.

?image is_subject_to <license_uri> .

is one half, and no need to associate any more information with the license URI.

The linguistic object is a rights statement, rather than a license and follows the linguistic object + rdf:value pattern.

Propose splitting the description into these two distinct concepts.

[workergnome]

I'm fine with splitting them—I think it's an abstraction problem in the review tool, because they're really about an image, not about an object. Should I create a new section for Images (like we have for MMOs and Actors?)

[VladimirAlexiev]

A rights statement is absolutely certainly crm:E30_Right. How about this:

<image> crm:P104_is_subject_to <image/rights>.
<image/rights> a crm:E30_Right;
   crm:P3_has_note "<rights_statement>";
   crmx:P3_credit_line "<credit_line>";
   crm:P148_has_component <http://rightsstatements.org/license_url>.

Optionally, include some RDF info about http://rightsstatements.org/license_url from their site. The Credit Line is closely related to rights, so we also put it there. crmx:P3_credit_line is a CRMX ext that I defined for CONA (Rob has access)

[VladimirAlexiev]

they're really about an image, not about an object

Yes, in this particular case. Objects may and often have different rights from images. If there's info about Object rights, it should be mapped separately, but in exactly the same way as for Images.

This bug is about keeping outside of crm:E30_Right. If a is not E30_Right then pray tell, what is?

[azaroth42]

No, a rights statement could be "We have not assessed the copyright status of this image", as per http://rightsstatements.org/page/CNE/1.0/?language=en.

That is absolutely not an E30_Right, poorly defined in CRM as "This class comprises legal privileges concerning material and immaterial things or their derivatives." as no legal privileges are being claimed. Quite the opposite, the statement is that the organization explicitly does not know what legal privileges are claimed.

It is not a license or a legal privilege, it is a statement about the (potential lack of) knowledge of the rights status of the resource.

[VladimirAlexiev]

Seems to me CNE should be omitted, following the semweb best practice "you don't need to say you don't know". I'm not sure, do you propose to use some rightstatements URL or not? Could you please write some turtle here?

[azaroth42]

It is explicit that the organization has not assessed copyright for this object. But the same would apply to any of the other non license rights statements. They are not legal privileges, per E30, they're statements about the status of the resource according to the issuer.

_:x a ManMadeObject ;
  refered_to_by [
    a LinguisticObject ;
    rdf:value "rights statement text goes here" ;
    classified_as <aat:rights> ]
  dct:rights <rightsstatements.org/whatever> .

[azaroth42]

Also, the rights model in CRM (E72, E30, P104, P105, P75) is just broken when there are multiple Rights and multiple Actors that hold them. You would need multiple E72s, one per Right/Actor combination. As such it could not be associated directly with the object ... and then you need some way to relate the E72s to the Man Made Object ... which could be composed of ... but in some weird non physical way.

[azaroth42]

Issue raised for CRM:

http://lists.ics.forth.gr/pipermail/crm-sig/2017-February/002892.html

[VladimirAlexiev]

You would need multiple E72s, one per Right/Actor combination.

Yes, you do. Eg (adapting your JSONLD above):

<object/31> crm:P104_is_subject_to <Right/0>, <Right/1>.

<Right/0> a crm:E30_Right;
  crm:P75i_is_possessed_by <actor/6>;
  rdfs:label "Ownership Right by Owner of Object".

<Right/1> a crm:E30_Right;
  crm:P75i_is_possessed_by <actor/7>;
  "Copyright by Holder of Object".

then you need some way to relate the E72s to the Man Made Object ...

The relation is crm:P104_is_subject_to

As such it could not be associated directly with the object

What "could not be associated directly"? If you mean a link actor-object, that's P105. However, P105 is a short-cut that provides less info than the long-path: "P105 right held by (has right on) is a shortcut of the fully developed path from E72 Legal Object through P104 is subject to (applies to), E30 Right, P75 possesses (is possessed by) to E39 Actor." So you don't need to use P105.

which could be composed of ... but in some weird non physical way.

Above I've suggested to use crm:P148_has_component to link the specific E30_Right instance to the generic "right type" on RightsStatements.org. You suggest to use P2 which is also possible, but imho P148 is more accurate: we're saying that the specific Right, being a Propositional Object, is composed of a generic "right type" plus extra info.

We can also state that an object doesn't have its rights evaluated because crm:P75i_is_possessed_by is not mandatory in E30_Right:

<object/32> crm:P104_is_subject_to <right/13>.
<right/13> a crm:E30_Right; crm:P148_has_component <http://rightsstatements.org/vocab/CNE/1.0/>.

<http://rightsstatements.org/vocab/CNE/1.0/> a crm:E30_Right;
  rdfs:label "COPYRIGHT NOT EVALUATED".

Of course, in this case making a local Rights node is unnecessary, so we could simplify to:

<object/32> crm:P104_is_subject_to <http://rightsstatements.org/vocab/CNE/1.0/>.

<http://rightsstatements.org/vocab/CNE/1.0/> a crm:E30_Right;
  rdfs:label "COPYRIGHT NOT EVALUATED".

And this shows why "rights types" should be treated as E30_Right not E55_Type, and why P148_has_component is better than P2.

the rights model in CRM is just broken

I'm not sure what fault you find with it, please elaborate