Should we document Rights Statements and Licenses, and how?

[stephenhart8]

About Rights and Licenses

In the possible information that CHIN will handle, there are to kind of data:

• factual data and metadata, that are not subjected to intellectual property rights (at least in Canada), but some institutions still adds a license to such data (like CC0)
• Images, photos, long texts and other kind of data that could be subjected to intellectual property rights.

The first question that arise is about who owns the licenses: Does CHIN owns the licenses of the factual data and metadata (and can therefore add a license to them)? If not, is it the providing institution who owns them? For the images and other kind of data, it is the providing institution that holds the rights (or the artist in some cases).

When CHIN owns the rights, it can created a license, using the Creative Commons. If CHIN does not own the rights, it can simply declare the rights statements, using the RightsStatements.org

Modeling

Model-wise, rights and licenses can simply be stated using Dublin Core Terms.

In case of the factual data and metadata, the easiest way is to add a license or rightsstatements to the NamedGraph, like in the following diagram. In that case, all the data within the NamedGraph should be subjected to the license or rights stated in the NamedGraph.

https://drive.google.com/file/d/1mPOFRgl6zz6giX5YmwVeCQEWI9dmodyP/view?usp=sharing

For the Images, Texts or other data subjected to intellectual property rights, the same pattern using Dublin Core could be added, to specify the rights pertaining to the particular data.

https://drive.google.com/file/d/1y0fJxE11O4ldr1sFo8515LKLFQkbN0jV/view?usp=sharing

[Habennin]

Question: why would you not use the rights properties and classes native to CRM?

ie Object -> P104 is subject to -> E30 Right and then link to your rights statement URI as a type.

I would argue that aside from being consistent with the standard, the reason to instantiate a Rights node is that there are different kinds of right and right can also have different temporal limitations. Therefore, if you don't instantiate such a node the long term maintenance of this rights information could become quite tricky.

[VladimirAlexiev]

I would not use a named graph (alone) to attach rights. While it describes the situation, it's not enough for software agents (crawlers) who stumbled upon the resource to be confident they can use it. So you also better have in on each "main record" or entity (eg Artist, Artwork).

As for the whole dataset, it's best to use VOID (and DCAT), see http://vocab.getty.edu/doc/#License_Info for an example.

The next section shows how its attached to individual items, though that is probably slightly wrong since the Getty does not hold any rights over a concept such as Rhyton, only over Getty's description thereof. But we wanted to keep it simple.

[illip]

I think this is highly binded with #45 since the Named Graph level (dataset vs record) will impact the pattern.

@VladimirAlexiev So should we state the rights at the Named Graph level, since it's not convenient for crawlers and that it's not exactly right to say that a factual data is under a specific license? Does this kind of info is important for some data hubs? If so, can we explain that our datasets contain various types of licenses?

I would be happy with a right pattern that covers specific entities of our TM like images and long texts. I also agree with @Habennin that we should see the rights as a simple URI. We should state the right as a node to be able to describe it more precisely. @stephenhart8 was there a reason why we've decided to use Dublin Core in the first place?

Another question to all, should we have two different patterns for the "right" and the "right statement"? Following rightsstatements.org it seems like there is a slight difference between both. For instance, if we decide to use Copyright undetermined it's clearly a statement about the right and not the right itself. I didn't explore what have been done around those questions, but it's probably something that @Habennin has already tackled. ;)

[stephenhart8]

From the discussions in the Semantic Committee on issue #17 "How to model images and how to integrate image URLs?", the issue of rights (of images) has been touched on. For the moment, dct:source is used to indicate the image bibliographic mention, but this kind of information should be refined. It has been raised that there should be a semantic distinction between the kind of sources (rights, licenses, etc.), so that more refined information can be documented. For the moment, the list of fields needed is:

• Rights
• Provider
• License
• Creator

More effort should be put into establishing the list of elements needed for recording what “sources” entails.

Other questions raised during the meeting:

• What ontology should be used to model rights? Is CIDOC CRM enough?
• Where to place the rights statement? In the case of images, should it be on the Visual Item? On the object? On the Digital Object?

It is worth noting that this question is important, even if it is not possible to publish the protected information. Indeed, it is still possible to document the object (image, text, etc.) without publishing it