Actions, métadonnées et revendications

Un manifeste C2PA est construit à partir d'assertions. Deux assertions comptent le plus pour la plupart des fichiers.

L'assertion d'actions (c2pa.actions.v2) liste les opérations discrètes dans l'ordre. La première entrée est presque toujours c2pa.created. Elle peut porter un digitalSourceType qui place l'œuvre dans une catégorie large telle que digitalArt. Les entrées suivantes peuvent décrire des ajustements de couleur, des recadrages ou d'autres modifications. La liste est censée être complète pour l'historique signé.

L'assertion de métadonnées contient des champs descriptifs ordinaires : titre, description, créateur, sujet, date de création. Ces champs utilisent les noms Dublin Core dans un contexte Schema.org dans la pratique courante. C'est l'endroit principal où des informations lisibles par l'humain sur l'œuvre peuvent voyager avec le manifeste.

Le format pousse donc deux types différents d'énoncés. La liste d'actions privilégie un compte rendu lisible par machine du processus. La section de métadonnées privilégie le type de description qu'un artiste pourrait déjà écrire pour une légende ou une déclaration d'artiste. Les deux sont signés ensemble.

Le choix de ce qu'il faut mettre dans ces champs n'est pas neutre. Un manifeste minimal qui n'enregistre que la création avec un type de source numérique générique ne dit pas grand-chose. Un manifeste plus riche qui inclut un titre précis et une description peut transporter plus du contexte intentionnel de l'œuvre. Cette richesse devient également partie de l'enregistrement permanent attaché au fichier.

Les plateformes qui consomment ces manifestes traiteront probablement la présence de revendications structurées différemment de leur absence. La décision d'inclure ou d'omettre des énoncés particuliers devient donc partie de la façon dont l'œuvre est présentée aux systèmes automatisés longtemps après que le signataire soit passé à autre chose.