doc/seda2_compat.rst
author Denis Laxalde <denis.laxalde@logilab.fr>
Fri, 19 Oct 2018 13:59:56 +0200
changeset 2972 359177d6a1c8
parent 2610 26dbed8bb1fe
permissions -rw-r--r--
Delete "container" relation on archive unit when unlinked from a profile - Container machinery got introduced in 143ae7a4a964, at that time the "container" relation was mandatory (on subject) for all entity types. - Integrity of this relation relied on the assumption that the relation was mandatory. (I.e. all entities mush have a link to their container and the only way to remove this link is to remove the container entity itself). - In a88deb387b2b, this assumption got broken as "container" relation was made optional for SEDAArchiveUnit as a subject. From there, when an archive unit got unlinked from a profile (through deletion of the "seda_archive_unit" relation), a "container" relation remained set. - This is problem since permission (especially on "delete" action) relies on the presence or absence of this relation. For instance, one would get an error when trying to delete an archive unit they just unlinked from a profile because they have no rights to delete the profile. So we fix this by dropping the "container" relation when a "seda_archive_unit" relation is deleted through a new hook. Additional test goes in test_entities.py as other container-related tests live there. In migration, we drop spurious "container" relation (not sure there are some).

Implémentation de la norme SEDA 2
=================================

Éléments non supportés
----------------------

Le modèle de données implémenté ne supporte pas l'intégralité du SEDA 2. Certains éléments sont
simplifiés, d'autres non supportés.

Les éléments non supportés sont les suivants :

* groupes d'objets (`DataObjectGroupId`, `DataObjectGroupReferenceId`),

* métadonnées étendues des objets-données (`Metadata`, `OtherMetadata`),

* référence à des profils ou unités d'archives (`ArchivalProfile`,  `ArchiveUnitProfile`),

* `Signature` sous la balise `Content`,

Enfin, il n'y a pas pour le moment de pas de possibilité d'étendre le modèle comme le prévoit le
SEDA 2 (c.f. les éléments `ArchiveUnitReferenceAbstract`, `ObjectGroupExtenstionAbstract`,
`OtherManagementAbstract`, `OtherCoreTechnicalMetadataAbstract`, `OtherDimensionsAbstract`,
`OtherCodeListAbstract` du `schéma XSD`_)

.. _`schéma XSD`: https://redirect.francearchives.fr/seda/seda_v2-0.zip


Référence vers des notices d'autorités et vers des vocabulaires
---------------------------------------------------------------

Dans une approche "référentiel" inspirée du `référentiel SAEM`_, un certain nombre d'éléments sont
implémentés via des références vers des notices d'autorité EAC ou des concepts de vocabulaires SKOS
(pour certains extrait du schéma du SEDA 2). De ce fait, tous les éléments de type `CodeListVersion`
pointent vers des vocabulaires et permettent de contrôler les concepts disponibles pour les éléments
associés.

Les balises référençant une notice d'autorité sont les suivantes : `Validator`, `Signer`, `Writer`,
`AuthorizedAgent`, `Addressee`, `Recipient`, `OriginatingAgency`, `SubmissionAgency`,
`ArchivalAgency`, `TransferringAgency`.

Les balises référençant un ou plusieurs concepts d'un vocabulaires sont les suivants :
`AcquisitionInformation`, `DescriptionLevel`, `ClassificationLevel`, `FinalAction`, `Encoding`,
`MimeType`, `EventType`, `LegalStatus`, `KeywordType`, `KeywordReference`, `CompressionAlgorithm`,
`MeasurementUnits`, `MeasurementWeightUnits`, `unit`, `FinalActionStorageCode`,
`FinalActionAppraisalCode`, `Level`, `FileFormat`, `VersionId`, `DataObjectVersion`, `FormatId`,
`Rule`, `RefNonRuleId`, `Type`. Les attributs suivants sont également gérés via référence vers un
concept : `type` (balise `Relationship`), `algorithm` et `language`.


.. _`référentiel SAEM`: http://www.saem.e-bordeaux.org/