ISP 1: International Standard Content Number Objectives

[Aludirk]

ISP: 1
Title: International Standard Content Number Objectives
Status: Draft
Created: 2020-03-16

Motivation

In order to create a global, decentralised and resilient digital content library, a digital content registry must need to build up. Therefore, we are going to propose the International Standard Content Number (abbreviated as ISCN). The following propose objectives of each section of ISCN are for use as a guideline to the schema specifications design.

Proposal

ISCN Objectives

1. A general digital content registry
2. A unique identifier to identify a digital content
3. All changes of the metadata must be simply traceable
4. The registry must be extensible
5. The hint for profit sharing on all stakeholders in case it happens
6. A registry to register metadata of digital content and at least to have the followings:

• The stakeholders of the digital content
• The content fingerprint
• The creation footprint
• The license
• The content metadata, including, but not limited to, caption and description, or even some specific metadata according to the content type

ISCN Schema

To fulfil the above objectives, using a structured-data is proposed as the digital content registry. To have a good structure and efficiently for re-using metadata, the structured-data should be like a directed acyclic link topology. Starting from a core ISCN metadata, linking to three more data nodes named: stakeholder, license and content metadata, and the architecture of an ISCN registry look like:

ISCN metadata

The ISCN metadata is the core metadata, that is the linkage between a content fingerprint and a globally unique identifier and also some metadata about the ISCN itself, and hence it contains:

• The version of the schema
• A unique identifier to identify a digital content
• The content fingerprint
• The source location of the digital content if it is open to public
• The version of the current ISCN

Also, links to another metadata to complete the ISCN registry:

• The link to the previous version of current ISCN
• The link to stakeholder metadata
• The link to the license
• The link to content metadata

The version of the schema

The version of the ISCN metadata schema and it can help the computational procedure to identify the schema.

A unique identifier to identify a digital content

A randomly generated identifier to assign to the ISCN and the length of the identifier should long enough, which has the confidence to be globally unique.

The content fingerprint

Base on the type of digital content, some hash algorithm should be chosen to generate the unique fingerprint to represent the digital content.

The source location of the digital

If the license of the digital content allows it to open to the public, the source location, maybe an URL, an IPFS address or whatever digital location, should also be registered.

The version of the current ISCN

An auto-increment number about the version of the ISCN metadata, if it is at least version 2, a reference link to the previous version of the ISCN metadata must also be registered.

Stakeholder metadata

The possible kind of stakeholders is the author(s), editor(s), publisher, escrow and creation footprints.

Author (0 to n)

The creators of the digital content, the metadata should contain:

• Information about the author
• Information about the location for receiving profit
• Hint on profit sharing

Editor (0 to n)

The editors of the digital content, the metadata should contain:

• Information about the editor
• Information about the location for receiving profit
• Hint on profit sharing

Publisher (0 to 1)

The publisher is a role to register the digital content as ISCN and manage the digital content itself. The metadata should contain:

• Information about the publisher
• Information about the location for receiving profit
• Hint on profit sharing

Escrow (0 to 1)

If the digital content registers as escrow, all the future profit will hold in custody. Once the escrow claims the real stakeholder, all profit should transfer to the new stakeholder. Therefore, the metadata should contain:

• Information about the escrow which has the right to claim the real stakeholder
• Hint on profit sharing to the final real stakeholder

Creation Footprint (0 to n)

If the digital content is a derivative creation, that is a creation creates based on any other creations, and we call this relationship as creation footprint. The registering content should also register those origins as creation footprint if those also registered as an ISCN. Therefore, the metadata should contain:

• The links to the origins of the creation footprint
• Information about the location for receiving profit
• Hint on profit sharing

License

The legal documentation of the license.

Content metadata

Due to the difference in nature between each type of contents, the schema should be discussed independently per type by another draft.

[guoliu]

Great design and exciting progress! Still digesting the overall logic and potential scenarios, but here are some ideas I have so far:

• In ISCN metadata, hashing algorithm for content fingerprint and protocol for source location need to be self-explanatory. Protocol can be expressed with standard url such as http://, dat:// or ipfs://, but there seems to be no standard way of expressing hashing algorithms. Maybe the work done by multihash project is worth considering.
• I assume the separation of unique identifier and content fingerprint is to support different content versions. Is there a design to express or record different content versions?
• Since adoption will likely to be the biggest challenge at least in the beginning, are there considerations of supporting other specs for creation footprint, such as plain http? Otherwise content using ISCN can fill out the schema only if all the creation footprint are using ISCN as well.

[Aludirk]

In ISCN metadata, hashing algorithm for content fingerprint and protocol for source location need to be self-explanatory. Protocol can be expressed with stand url such as http://, dat:// or ipfs://, but there seems to be no standard way of expressing hashing algorithms. Maybe the work done by multihash project is worth considering.

I assume the separation of unique identifier and content fingerprint is to support different content versions. Is there a design to express or record different content versions?

Yes, I agree.

Since adoption will likely to be the biggest challenge at least in the beginning, are there considerations of supporting other specs for creation footprint, such as plain http? Otherwise content using ISCN can fill out the schema only if all the creation footprint are using ISCN as well.

For this point, I basically agree with you. However, we need to think about a mechanism to let the origins' owner migrate from a simple URL to ISCN. I will make a separate draft to discuss this point.

[cognition9144]

but there seems to be no standard way of expressing hashing algorithms

Actually there is: https://youtu.be/Z5zNPwMDYGg?t=597

Update: well it's just multihash. So it seems to be the recommended way by IPFS.

[guoliu]

but there seems to be no standard way of expressing hashing algorithms

Actually there is: https://youtu.be/Z5zNPwMDYGg?t=597

Update: well it's just multihash. So it seems to be the recommended way by IPFS.

Yes, Protocol Lab is effectively leading the standard now, multihash looks quite promising in adoption. I think I was sitting on the right of the camera in this video 😝