Proposition identifiants standard 1 et 2 #11
Comments
|
Merci @mbrasebin j’approuve cette proposition ! La syntaxe serait donc quelque chose comme : Propositions d'améliorations :
Nouvelle syntaxe : Il sera sans doute utile de réduire les noms de classe à une abréviation limitée par exemple à 5 caractères Exemples :Document d’urbanisme :
Règlement du document d’urbanisme :
Titre ou « Ensemble de zones d’urbanisme »
Dispositions générales :
Zone d’urbanisme :
Contenu :
Règles structurantes :
Conditions unitaires :
Contraintes unitaires :
Classes :
|
|
Bonjour, Je suis désolé mais j'ai beaucoup de mal à comprendre le fonctionnement attendu. Rappel du fonctionnement de l'outil de saisi à l'heure actuelle :Il n'y a que 3 éléments qui disposent d'un identifiant dans l'outil : les règlement, les titres et les contenus. Un règlement est composé de plusieurs titres. Les titres sont composés de un ou plusieurs contenus. Un contenu peut éventuellement être de la classe "article". D'ailleurs, je ne comprends pas à quoi sert cette fonctionnalité qui était déjà là quand j'ai repris le projet. Un paragraphe n'est pas égal à un contenu. Si tous les paragraphes d'un titre ont les mêmes métadonnées, le titre n'aura qu'un seul contenu regroupant tous les paragraphes. QuestionsPartant de là, une phrase comme "La classe titre est récursive dans le sens où un article ayant un titre peut être composé d'articles ayant leur propres sous-titres." est incompréhensible pour moi. Peut-être que le comportement actuel de l'outil ne convient pas ? Je ne comprends pas la syntaxe des identifiants des titres. Est-ce que les "UE1" et "UE2" sont des incréments ou est-ce que ça fait référence à autre chose ? On aurait une syntaxe du type {identifiant_plu}/reg/{zone}/{zone}{incrément} ? Si la zone n'a pas été renseignée par l'utilisateur, comment on fait ? On parle de mettre "dg" dans le cas des dispositions générales mais comment on sait qu'on est dans des dispositions générales ? Pour les contenus, ça me semble plus clair : on prend l'identifiant du titre parent et on ajoute un incrément. P.S. Je ne parle que pour le standard de niveau 1 étant donné que c'est le standard utilisé par l'outil de saisi. |
|
Pour te répondre @MFrangi :
Exact, et dans le standard CNIG SRU de niveau 2 tous les objets de toutes les classes portent un identifiant
Note également qu'un titre peut également avoir des sous-titres
Je ne vois pas de classe article dans le standard CNIG SRU.
@mbrasebin fait référence à la relation "a pour sous-titre" :
Non, ce ne sont pas des incréments mais des noms de zones d'urbanisme (ici : urbaines et économiques)
il s'agit d'un chapitre particulier, clairement identifié dans le règlement, qui en général précède les chapitres par zone puisque les dispositions générales s'appliquent par définition à toutes les zones. |
|
Bonjour, Merci pour les réponses. Je dois avouer que je n'avais pas fait attention que nous n'étions pas sur le github de l'outil de saisie quand j'ai cliqué sur le lien pour venir sur cette discussion. Cependant, étant donné qu'il faudra sûrement que j'implémente les identifiants dans l'outil, je pense que ce n'est pas plus mal que j'essaie de comprendre dès le début. Dans l'outil, il y a des titres de différents niveaux (1 à 4), est-ce que cela correspond à la notion de sous-titre ? Puisqu'il n'y a pas de notion d'article dans le standard, je pense qu'il faudra l'enlever de l'outil. Sûrement un reliquat d'une ancienne version qui n'a plus lieu d'être. Du coup, comment incrémente-t-on les identifiants des titres. J'ai peut-être mal compris mais j'ai l'impression que tel que c'est décrit pour l'instant, des titres différents pourraient avoir le même identifiant. Il faudra mettre en place un moyen pour l'utilisateur d'indiquer dans l'outil qu'un chapitre correspond aux dispositions générales. Ce n'est pas prévu à l'heure actuelle. |
|
@MFrangi : cette issue est dédiée à la définition des identifiants pour le standard SRU niveau 1 et 2. |
|
Les commentaires d'Arnaud me conviennent, je les ai intégrées à la proposition initiale |
|
Modifications intégrées dans le document |
|
Le projet de standard présente des incohérences entre le nom de l’attribut id<classe> et le nom de la classe retenu dans l’exemple. 2/ idDimParc et 44712_PLU_20041103/reglement/UE/UE2/contenu002/regle001/cdu003/surfpa01 3/ idBcons et 44712_PLU_20041103/reglement/UE/UE2/contenu02/regle01/cdu03/bandeconstructibilite01 etc. |
|
Garder le libellé entier dans le nom de l’attribut id et l’abréviation dans l’URI. exemples : idTypeBatiment et 44712_PLU_20041103/reglement/UE/UE2/contenu002/regle001/cd003/typba01 |
|
Cette issue est indiquée comme "en cours" dans le CR du 11 juin, mais au vu du projet de standard v2024-08 elle semble maintenant résolue sur le fond. (@alisonlenain : je mets cela en pense-bête pour le futur, pas pour prise en compte immédiate) |
|
La solution de codification des identifiants a été centralisée / factorisée dans la partie "Règles d'organisation et de codification" du projet de standard à l'occasion de son reformatage durant le mois de novembre 2024. |
Proposition
Suite à la réunion du 28 novembre 2023, nous avons établi qu'il serait nécessaire de spécifier les identifiants des standards de niveau 1 et 2 afin de de pas laisser une URI libre et aléatoire pour faciliter :
1/ le développement d'outils exploitant le lien entre ces URI
2/ la possibilité pour un humain de faire le lien entre l'URI et les objets associés
Le principal général est de produire des URI en cascade qui reprennent l'URI de la classe mère et d'en ajouter des éléments spécifiques à la classe.
La proposition se fait au regard du schéma ci dessous (avec pour rappel en orange les classes du standard de niveau 1 et en vert et bleu les classes de standard niveau 2).
Standard niveau 1 :
Classe ReglementPLU
L'idée serait d'appuyer l'identifiant de cette classe sur l'URI tel que défini dans le standard CNIG PLU où l’identificateur IDURBA est construit par concaténation du code INSEE de la commune ou du numéro SIREN de l’intercommunalité avec le type de document et sa date d'approbation (voir le paragraphe 4.3 de la norme pour plus de détail : https://cnig.gouv.fr/IMG/pdf/221108_standard_cnig_plu_v2022-10_comm_std.pdf)
Pour cet identifiant, nous proposons donc d'ajouter un suffixe /reglement/ pour préciser qu'il s'agit de l'identifiant du règlement.
Ainsi, si on considère deux documents d'urbanismes avec les identifiants IDURBA :
Les identifiants des règlements deviendraient :
Classe Titre
Le titre représente les différents titres du règlement d’urbanisme qui peuvent être liés à un zonage et à une prescription. La classe titre est récursive dans le sens où un article ayant un titre peut être composé d'articles ayant leur propres sous-titres.
Comme cette classe fait le lien avec le règlement d'urbanisme, il est proposé de construire l'identifiant à partir du règlement auquel il est associé et du libellé de la zone d'urbanisme à laquelle le titre est associé.
Cela donne dans le cas d'une zone UE :
Si cette zone UE est sous décomposée en zone UE1 et UE2 (pour prendre en compte la sous décomposition en sous-titres), on ajoutera l'identifiant de sous-titre au titre parent. Cela donne :
Cette hiérarchisation facilitera le fait de retrouver des éléments réglementaires définis au niveau de l'article parent et qui s'appliquent au niveau de règlement.
Enfin, pour les articles qui ne sont pas associés à une zonage du PLU (par exemple, les dispositions générales), un code est ajouté à la place de l'identifiant de la zone. Par exemple, le code serait dg pour les dispositions générales, les URI seraient alors les suivants :
TODO : définir la liste des codes pour spécifier ces articles sans zonage associé
REP : comme vu en SG6 du 08/01/2024, il ne semble pas y avoir d'autres code que dg à prévoir :
Classe Contenu
Le Contenu correspond à un ou plusieurs paragraphes à l’intérieur d’un Titre.
Concernant l'identifiant, celui-ci serait construit à partir de l'identifiant du titre parent et en ajoutant le préfixe contenu puis un numéro par ordre croissant en fonction du nombre de paragraphes sous le titre. Ce numéro serait codé sur 3 caractères et serait incrémental à partir de 1 et défini par identifiant de titre parent.
En reprenant les exemples précédents d'URI :
cela donnerait :
Standard niveau 2 :
Classe RegleStructurante
La classe règle structurante fait le lien entre les standards de niveau 1 et de niveau 2. Elle traduit le fait qu'une partie d'un article est traduite dans le format structuré d'exploitation des règles. Ainsi, il y a potentiellement plusieurs règles structurantes associées à un contenu d'article.
L'idée est de construire l'identifiant à partir du contenu auquel la règle est associée et d'ajouter le suffixe regle un numéro incrémental à 3 chiffres qui débute à 001 en fonction du nombre de règles associées à l'article.
Les identifiants suivants de contenu :
Impliquent les identifiants suivants de règles structurantes :
Classe ConditionUnitaire et ContrainteUnitaire
Ces classes associées à la classe de règles structurées permettent de définir les conditions à vérifier pour qu'une règle s'applique et les implications en termes de contraintes. Ces contraintes et conditions sont chaînées pour former des conditions et contraintes composites.
L'idée est de construire les identifiants à partir de la règle structurante à laquelle ces conditions et contraintes sont associées et d'ajouter un nombre codé sur 3 chiffres de manière incrémentale. Un préfixe (cdu ou ctu pour condition ou contrainte) est ajouté de manière à éviter les doublons et spécifier le type d'objet associé à la classe.
Pour les identifiants de règles structurantes suivants :
Les conditions unitaires seront codées comme suit :
et les contraintes unitaires :
Les différentes implémentations des classes ConditionUnitaire et ContrainteUnitaire (par exemple, BandeConstructibilité ou RetraitAlignement) ont les identifiants construits de la même manière en limitant à 5 caractères le préfixe des classes. Par exemple :
TODO : à moduler en fonction des classes et noms de classes finalement retenes dans le standard SRU de niveau 2
The text was updated successfully, but these errors were encountered: