Métadonnées des scènes eCorpus
ce document fait référence à des fonctionnalités en cours de développement
TODO
- relever toutes les équivalences eCorpus ↔ Dublin Core
- Annoter les vocabulaires applicables selon LIDO-MC
- Finaliser le vocabulaire des relations (voir:
)
Normes applicables
dcterms DCMI: DCMI Metadata Terms
Quand applicable, les métadonnées sont structurées en respectant la norme ISO 15836-2:2019, dite dcmi-terms. Le prefixe dcterms: est omis dans un soucis de concision et de lisibilité. Seuls les champs pertinents sont définis mais l’ensemble des termes dcterms sont considérés comme réservés.
Vocabulaires contrôlés
La capacité à diffuser les métadonnées propres d’eCorpus au format :xml: LIDO est un objectif envisagé. Ce format suppose l’utilisation d’un vocabulaire contrôlé pour un certain nombre de champs. On peut se référencer à la specification LIDO elle-même, qui utilise le système SKOS mais délègue la définition des Thésaurus aux profils d’application. Dans le cas de la France c’est LIDO-MC qui s’applique (
Profil d’application LIDO-MC.pdf (2,1 Mo)). Concrètement, on appliquera généralement des thésaurus de getty.edu ou de data.culture.fr.
La terminologie « de base » pour LIDO est documentée ici : xTree.public
Title
localisé: oui
Texte extrait du document scene.svx.json, champ titre dans l’onglet collection.
Language
localisé: oui
code alpha2 ISO 639-1)
Rights Holder
localisé: non
Le « copyright holder » peut être extrait du champ asset.copyright du fichier scene.svx.json.
License
localisé: non
Un [LicenseDocument]DCMI: DCMI Metadata Terms). Devrait idéalement être une URL. à défaut une chaîne libre.
DCMI ne précise pas le vocabulaire utilisé mais le type RigthsType de LIDO recommende un vocabulaire contrôlé issu de rightsstatements.org ou les licences Creative Commons
Exemples:
- https://rightsstatements.org/vocab/InC/1.0/ : In Copyright
- https://creativecommons.org/licenses/by/4.0/ Creative Commons Attribution
- …
Une license applicable pourrait être déduite du champ asset.copyright (ex: chercher CC-*) mais c’est probablement une mauvaise pratique. Ajouter un champ asset.license au vocabulaire contrôlé pourrait être adapté (permet de stocker la license avec la scène y compris lors d’un export ZIP).
Contributor
eCorpus utilise des username / emails, pas vraiment compatibles
localisé: non
Liste des contributeurs pour cette scène. Idéalement, URI désignant le contributeur. à défaut son identifiant
Created
localisé: non
Date (ISO 8601) de création de la scène telle que renvoyée par le champ ctime de celle-ci.
Modified
localisé: non
Date (ISO 8601) de création de la scène telle que renvoyée par le champ mtime de celle-ci.
Creator
localisé: non
Identifiant (URL ou nom) du créateur de la scène
Description
localisé: oui
Résumé non-exhaustif des contenus textuels de du fichier scene.svx.json selon pertinence
Format
localisé: non
MIME non-standard (pas répertorié par l’IANA) application/si-dpo-3d.document+json.
Le mime du document devrait-il être remonté sur la scène via le champ meta ?
Subject ( proposition)
localisé: oui
Elements de language décrivant le sujet de la scène. Idéalement faisant référence à une ontologie ou un vocabulaire contrôlé.
Pouvoir associer des tags à des éléments de vocabulaire? Pouvoir associer des métadonnées à des tags (pour marquer la signification « sujet » du tag)?
relations ( proposition)
Liste des relations utiles identifiées:
isFormatOfsi la scène est une représentation canonique d’un objet identifié.sourcesi la scène découle évidemment d’un objet identifiéreferencessi la scène est en relation avec un objet sans lien de parenté précisisPartOf: Référence possible vers les différents modèles 3D présents dans la scène.
Le support des références inverses (hasFormat, hasPart) n’est pas prévu. Elles pourront être générées à l’export.
Ajouter les relations supplémentaires définies dans dublin-core: replaces, requires, conformsTo, isVersionOf?
Ajouter une relation générique?
Les relations sont de type Relation. Les URI (Idéalement, URN. à défaut une URL) ne sont pas strictement requises par le standard mais devraient l’être par eCorpus.
L’adjonction de relations externes à une scène eCorpus permet d’informer le type de contenu représenté. Typiquement, une référence à l’oeuvre en question via une relation source ou isFormatOf.
Si applicable, des éléments de métadonnées du sujet pourront être récoltés pour fournir des informations complémentaires sous forme libre.
Ces données ne sont pas supposées faire autorité et seront exclues des exports de métadonnées d’eCorpus à l’exception du champ uri qui servira à l’établissement d’une relation
les relations doivent-elles être localisées? si non, comment localise-t-on les métadonnées? Difficile de vérifier l’applicabilité puisque les sources explorées ne sont pas multi-locales.