etalab / noms-de-domaine-organismes-secteur-public

Liste de noms de domaine d'organismes publics
Other
22 stars 15 forks source link

Generation de urls-*.txt par type de structure publique #49

Open mfaure opened 1 year ago

mfaure commented 1 year ago

Actuellement le fichier urls.txt (produit par script/http_check) regroupe en un seul fichier toutes les URLs de tous les fichiers sources/*.txt.

C'est pratique si on chercher à lister toutes les URLs, ça l'est moins si cherche uniquement les URLs des communes ou des EPCI ou des préfectures, etc.

L'objet de cette PR est d'ajouter dans le dépôt les fichier urls-X.txt et domains-X.txt les sous-ensembles suivants :

L'intérêt d'avoir ces fichiers est de mettre à disposition des fichiers d'URLs (pas domaine) directement (ré)utilisables.

JulienPalard commented 1 year ago

Un alternative serait d'avoir la même (ou quasiment la même) structure de donnée dans domains.csv et dans urls.csv (et donc plus urls.txt) :

name,SIRET,type,sources,script

L'avantage serait d'éviter d'avoir à choisir sur quel aspect on fait le découpage : ça permettrait de chercher une URL par sources, ou par SIRET en plus de pouvoir la chercher par type.

mfaure commented 1 year ago

Bien vu ! Ça pourra faire l'objet d'une autre PR.

Là le but est uniquement de mettre à dispo les fichiers urls-*.txt. Est-ce OK pour toi pour merger ?

villesinternet commented 1 year ago

Avez vous vu ma suggestion concernant le choix du numéro de Siren plutôt que le numéro de Siret ? (Plus facile à trouver, plus généraliste pour identifier une entité juridique que le Siret qui est associé à chaque établissement physique, et meilleur pivot car invariable et unique).

Pour le reste tout est OK pour moi !

Le jeu. 15 déc. 2022 à 17:34, Matthieu FAURE @.***> a écrit :

Bien vu ! Ça pourra faire l'objet d'une autre PR.

Là le but est uniquement de mettre à dispo les fichiers urls-*.txt. Est-ce OK pour toi pour merger ?

— Reply to this email directly, view it on GitHub https://github.com/etalab/noms-de-domaine-organismes-publics/pull/49#issuecomment-1353367090, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB2YF5RKOP4D7IA5ESXKGKTWNNCBXANCNFSM6AAAAAAS6XIFZY . You are receiving this because you are subscribed to this thread.Message ID: @.*** com>

JulienPalard commented 1 year ago

[après les vacances]

Bien vu ! Ça pourra faire l'objet d'une autre PR.

Oui mais y'a-il un grand intérêt d'avoir un commit qui découpe un fichier (en ~35 fichiers !) pour enchaîner avec une PR qui l'unifie à nouveau ?

mfaure commented 1 year ago

oui :) Ça permet :

JulienPalard commented 1 year ago

avoir dès maintenant les fichiers urls-*.txt dans master

Je n'ai pas retenu que c'était un objectif, selon les notes de la réunion l'objectif est un seul domains.csv et un seul urls.txt :

Jeux de données dérivés:

  • urls.txt: HTTP(S)
  • mx.txt
  • version_super_verifiee_pas_de_phishing.txt

Mais j'entend ton besoin d'avoir un découpage par type de structure, si je me souviens bien tu en avais fait la demande à l'oral et quelqu'un (si ce n'est pas moi) t'avait répondu « tu pourras faire une jointure ».

On parlait probablement de join qui permet de faire une jointure sur deux fichiers, mais la réponse à peut-être été lancée un peu vite, ce n'est pas si simple à appliquer ici car d'un côté on a des URLs et de l'autre des domaines, bon ça se fait, mais c'est pas agréable :

$ join -t, <(sed 's#^https\?://\(.*\)$#\1,\0#' urls.txt | sort) <(sort domains.csv)

Avec grep c'est un poil plus lisible, mais toujours pas agréable :

$ grep -Ff<(grep Commune domains.csv | cut -d, -f1 | sed s#^#//#) urls.txt

Par contre vu qu'on aura le type de structure dans domains.csv tu pourras faire :

grep Commune domains.csv

pour avoir toute les Commune, et là ça me paraît agréable. Tu pourras faire :

grep '200.OK.*Commune' domains.csv

pour avoir toutes les communes qui répondent en 200 OK en HTTP, ça reste lisible.

C'est le fait que ça devienne simple d'obtenir ces listes me fait penser qu'on ne devrait pas versionner tous ces fichiers.

J'ai presque envie de proposer de ne plus stocker, urls.txt du tout vu que c'est presque un grep 200.OK domains.csv mais on s'éloigne du sujet.

mfaure commented 1 year ago

Merci @JulienPalard pour les lignes de commandes que je ne connaissais pas !

Le fait d'avoir le ou les fichiers urls.txt dans le dépôt possède une grande valeur : "c'est le jeu de donnée de la DINUM". La recette de cuisine intéresse les développeurs, la liste des URLs intéresse tout le monde.

JulienPalard commented 1 year ago

la liste des URLs intéresse tout le monde

Oui, mais je suis réticent à versionner toutes les listes d'URLs (je suis le seul ?). Pour ton usage tu en as besoin par type, mais pour un autre usage le besoin est peut-être sur un autre aspect, et j'ai peur de voir le nombre d'artefacts versionnés exploser.

D'ailleurs @rdubigny côté publication sur data.gouv.fr, préconises-tu de versionner tous les artefacts qu'on publie, ou peut-on se contenter de versionner le script qui génère les artefacts ?

Ça permettrai peut-être de trouver un compris : la « recette de cuisine » côté github pour les devs, les listes côté data.gouv.fr pour les ré-utilisateurs ?

mfaure commented 1 year ago

Bien vu de séparer les lieux de publication ! Ça répondrait à mon besoin. Pour moi il est important de rendre nos listes utilisables dès maintenant, et à tout le monde :)