Acronymes : conseils régionaux

Pour le Département du Vaucluse j’utilise operator=CD84 ce qui est l’acronyme utilisé en interne
j’aimerais pousser l’équivalent en acronyme pour la Région SUD, or je vois sur wikipedia qu’il y a le FR-PAC.
Cela donnerait-il operator=CRPAC ?
Y-a-t-il une idée cc @tony.emery ?

il me semble que parler du conseil départemental pour désigner l’entité juridique « département » est un abus de langage. Faut-il le reproduire pour les régions ?

operator=CD84 est l’acronyme utilisé par les Départements de façon générale (CD84 étant dans ce cas pour le Vaucluse en y adossant le référentiel INSEE pour les départements).
Cela a été fixé par la loi Conseil départemental — Wikipédia

Tel n’est pas le sujet du message.

Il me semblait que le thème du message était l’extension d’un principe de définition d’acronymes ?

Le message est comment définir un ‹ operator › pour le Conseil Régional et en particulier celui du SUD car il a deux appellations.

C’est bien d’operator que je parle moi aussi. Je ne retrouve pas à l’instant le sujet du forum où nous avons débattu récemment de la désignation des opérateurs des réseaux (y compris en évoquant l’idée de basculer sur un identifiant wikidata plutôt qu’un nom), mais il me semblait que l’idée générale était de désigner de manière non ambiguë l’entité en charge de la gestion : commune, SIVOM, EPCI, département, région, etc.

cela me va, mais en attendant je pousse sur un identifiant évident

Pour qui hormis @ZIMMY CRPAC est un acronyme évident ? Je n’en fait pas partie. CRPACA, j’aurais deviné.
Et pourquoi ne pas dire région ? Car c’est un l’opérateur régional, peu importe la région.
Donc :
operator:type=government
admin_level=4
operator:wikidata=Q2994252
operator=conseil régional de Provence-Alpes-Côte d’Azur

Bonsoir

Pour carrément simplifier les choses et ne pas se poser la question, je vous recommande l’usage de operator:wikidata

Pour le Conseil Départemental du Vaucluse : operator:wikidata= Q23782080

Les éditeurs pourraient automatiquement afficher l’intitulé correspondant à l’utilisateur sans avoir à dupliquer operator + operator:wikidata comme nous le faisons actuellement.

C’est le rôle de operator:type, quand l’organisation exacte est inconnue

Le département est le périmètre administratif et le Conseil Départemental est l’organisation qui le gère.
Un peu comme la commune (code INSEE) et la mairie (code SIRET).

Le CRPAC est simplement lié aux conventions de normalisation, dans ce cas c’est la norme ISO
image

je viens de pousser pour les collèges un operator:wikidata en doublon

Honnêtement, je n’aurai pas compris que ca désignait le CR PACA.

Un mélange entre l’abréviation ISO à 2+3 lettres et nos ref ça me parait pas très digeste.

  • CRPAC :-1:
  • CRPACA ou CR PACA :+1:

PACA est quand même un cas un peu particulier, car l’acronyme PACA est relativement usité, alors que c’est rarement le cas pour les autres régions.

On ne va pas mettre CRB pour la Bretagne… sur operator je trouverai que CR + le nom de la région ça ferait sens (CR Bretagne, CR Hauts de France).

Les identifiants wikidata, c’est bien mais destiné à des machines pas des humains et trop d’outils ne font pas le déréférencement pour avoir le libellé.

1 Like

Une réponse avec double détente bienvenue :
1- mise en lumière de l’acronyme operator=CR PACA qui me va
2- préciser le risque de l’alimentation non explicite (lisible par des machines) qui me conforte dans le bénéfice d’une convergence (avec un operator compréhensible) et non exclusivité du operator:wikidata

C’est vrai.
Cela me semble être une nécessité si nous voulons apporter de la lisibilité dans nos données.
Il y aura systématiquement des valeurs CRPACA, CRPAAC, CR paca qu’il faudra nettoyer et ce temps passé n’est pas très bien employé.

Alors oui, on ne doit pas faire ça pour toutes les valeurs parce qu’on va produire une usine à gaz illisible.
Pour les items wikidata, le rapport bénéfice / inconvenients me semble favorable.

ou alors on définit des URN ?

Ca ne suit pas la RFC mais c’est bien le rôle qu’on donne aux identifiants wikidata.

mais si on trouve que les ID wikidata sont peu lisibles, on pourrait avoir des URN semi-lisibles par des humains en restant lisibles par des machines

Ca ne réglera pas dans ce cas le problème que je point au dessus, on aura des URN erronées (si vous me répondez qu’on a qu’a les valider en amont, pourquoi ne valide-t-on pas les valeurs actuelles ?).

Les identifiants signifiants présentent le problème que les utilisateurs vont/voudront les retenir, parfois de manière erronée.
Les identifiants non signifiants nécessitent une ergonomie plus importante mais au moins on ne cherche pas à les retenir faux.