Skip to main content

System design

Response logic

Introduction

CommonsDB is a registry of ISCC codes that identify digital assets that are either in the Public Domain or published under an open license. ISCC codes are provided to the registry as part of declarations. Each declaration contains an ISCC code derived from a digital media asset. Together with the ISCC code, CommonsDB declarations record the Data Supplier’s identity, a rights statement relating to the asset, and a timestamp indicating when the information was declared to the registry. Once added, declarations are immutable, with any amendments recorded via new declarations linked by provenance identifiers.

The key functionality of CommonsDB is that it enables users—whether individuals or entities—to provide the ISCC of an asset (or upload the media file to CommonsDB Explorer in order to generate the ISCC fingerprint) to query the system for information about its rights status.

Put simply: given an ISCC, the system will return the rights status, the identity of the Data Supplier, and the timestamp of any declaration matching that code within the system.

The system is designed to retrieve multiple declarations associated with the same ISCC. This may occur when different Data Suppliers make declarations about the same digital asset, or when a single provider makes multiple declarations (e.g. updates) for the same asset. In addition, the system can also return information about digital assets similar to the provided ISCC by performing a similarity search on the code’s content unit.

When a CommonsDB query returns multiple declarations, the rights statements in the declarations may conflict. This document proposes an approach for handling such conflicts. In these situations, the system assesses whether a clear majority view exists across all matching declarations. Where a strong majority is present, that position may be highlighted while still displaying all declarations, maintaining transparency and supporting consistent interpretation.

Core assumptions

For the purpose of this analysis, we assume that rights information contained in declarations provided by Data Suppliers is trustworthy, unless there is an explicit conflict.

We focus on four properties encoded in each declaration: the ISCC, the declarerId (the identity of the declaring party), the rights statement, and the timestamp of the declaration.

We assume that, when queried with an ISCC code, the system can return a list of matching declarations based on similarity at the content unit level. Declarations with fewer than 10 bits of difference in the Content Code unit are considered matches. As a result, a query with a single ISCC may return none, one, or several declarations. When multiple declarations for the same ISCC are made by the same Data Supplier, the system will only return the declaration with the most recent timestamp.

CommonsDB currently supports four core rights statements—Public Domain Mark (PDM), CC0, CC BY and CC BY-SA—including all jurisdictional and version variants of the Creative Commons licenses. These can be grouped into two broad categories: (1) statements asserting no known copyright or reuse restrictions (PDM and CC0), and (2) statements indicating that copyright or use reservations may exist but that the work is available under an open license (CC BY and CC BY-SA). Statements within each category are treated as compatible; statements across categories are treated as potentially conflicting.

Logic

When queried with a single ISCC code, the system returns information for each declaration that contains an ISCC code where the difference of the content component is below a specified distance threshold (d), where (d <= 10).

For each matching declaration the system provides: 

  • The declarerID
  • The timestamp
  • The ISCC code
  • The rights statement

There are other elements that are returned but not used to determine the presence of a conflict.

Based on these elements the system calculates for each of the returned declarations a conflict indicator that is returned together with all the other elements.

The conflict indicator is binary: true or false where true indicates the presence of a conflict and false indicates the absence of a conflict. 

The following steps are used to determine the presence of a conflict for each individual result that is returned to the user. Note that not all matches are returned to the user since some results will be collapsed into one as part of the proposed logic.

There are two adjustable parameters included in the decision logic: 

  • The grouping of rights statements that are compatible into buckets. We are currently assuming two buckets (Public Domain: PDM and CC0; In Copyright: CC BY and CC BY-SA). It is possible that we will add additional rights statements to these buckets and unlikely that additional buckets will be introduced.
  • The numerical threshold for determining whether a majority view exists (m). For now, m is set at 75%, meaning a position is only treated as dominant when it has strong support among declarations.

Before the logic is run, the following optimizations need to be run: 

  • For each unique declarerId (Data Supplier) and identical ISCC, discard all entries except the one with the most recent timestamp.
  • For each provenance chain identified by subsequent CIDs (indicating successive declarations for the same work by the same Data Supplier), discard all entries except the one with the most recent timestamp. Then compute the following inputs from the remaining results:
  • nm = total matches.
  • n_pd, n_ic = counts per bucket (so n_pd + n_ic = nm).

Logic:

  • If nm = 0 → return “no information available”.
  • If (n_ic = 0 or n_pd = 0) → return all, set conflict = false.
  • If (n_ic > 0 and n_pd > 0) and max(n_ic, n_pd) / nm < m → return all, set conflict = true.
  • If (n_ic > 0 and n_pd > 0) and max(n_ic, n_pd) / nm ≥ m → return all, → for declarations in majority bucket: set conflict = false → for declarations in minority bucket: set conflict = true.

Output

For each matching declaration the system will output the following elements:

  • declarationId
  • declarerId
  • ISCC
  • distance
  • rights statement
  • conflict
  • source
  • signature

Note that the conflict value is not a part of the declaration. It is an additional output parameter that can vary over time and gets dynamically calculated in response to a query for each matching declaration. It only exists in relation to a specific query. The dynamic conflict flag allows the registry to transparently indicate when there is conflicting information on the rights status of a digital asset, without altering or invalidating any underlying declarations.

This is similar to the distance metric which is also not part of the declaration, but generated for each declaration at query time.

Not all of these elements will be displayed to the user in all interfaces.