Est-ce qu'un sous-domaine "public" d'un domaine "privé" est ... #26
Comments
|
Oui, je pense qu'il faut les garder quitte à rapidement trouver un moyen de rajouter de la métadonnée sur ces urls |
|
De même, je pense qu'il faut les garder - si je prends l'exemple de http://mairiederance.blogspot.com c'est bien la mairie qui est éditrice (et juridiquement responsable) des contenus publiés, quel que soit l'hébergeur ou le prestataire qui gère la mise en ligne de ces contenus. |
|
+1
Pascal Kuczynski -https://www.adullact.org
Délégué Général - 04 67 65 05 88
L'ADULLACT fête ses 20 ans du 15 au 17/06/2022 -https://adullact.org/congres/congres-2022
Le 25/03/2022 à 08:46, Bastien a écrit :
…
De même, je pense qu'il faut les garder - si je prends l'exemple de
http://mairiederance.blogspot.com c'est bien la mairie qui est
éditrice (et juridiquement responsable) des contenus publiés, quel que
soit l'hébergeur ou le prestataire qui gère la mise en ligne de ces
contenus.
—
Reply to this email directly, view it on GitHub
<#26 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACUE3NVFFV4QPCTZQSCQZITVBVVO3ANCNFSM5RSMKOBQ>.
You are receiving this because you are subscribed to this
thread.Message ID:
***@***.***>
|
|
Effectivement il faut distinguer le producteur de contenu / responsable éditorial de l'hébergeur. Actuellement pour Sources de confiance nous avons des règles de validation qui distinguent Au niveau des urls, des règles similaire pour le path peuvent être définies si on traite des plateformes de réseaux sociaux. Mais cela dépend du périmètre que l'on se fixe pour ce repo : sommes-nous intéressés par des domaines (y compris mx, ftp, etc.), des sites (cela pourrait inclure |
|
Villes Internet ***@***.***> writes:
On peut donc trouver grenoble.fr www.grenoble.fr blabla.grenoble.fr sans que ces entrées ne soient considérées comme des doublons.
Je trouve que cette approche est correcte.
Au niveau des urls, des règles similaire pour le path peuvent être définies si on traite des plateformes de réseaux sociaux. Mais cela dépend du périmètre que l'on se fixe pour ce repo : sommes-nous intéressés par des domaines (y compris mx, ftp, etc.), des sites (cela pourrait inclure facebook.com/nomdelacollectivite dont le domaine n'est pas du secteur public, mais le producteur de contenu si), ou les deux ?
Je crois qu'il est utile de se concentrer sur la notion de "(sous-)domaines gérés par une entité du secteur public" sans entrer dans la notion de "site".
|
Je pense aussi, le repo est orienté domaine, pas site. Il faut garder en tête que ça nous coupe de quelques pages d'organismes publics hébergées sur des services comme "sites.google.com" (ce qui pour moi n'est pas un problème, mais il faut peut être le documenter dans le README aussi ? Prévenir qu'on est pas exhaustif.). |
|
Julien Palard ***@***.***> writes:
Je pense aussi, le repo est orienté domaine, pas site. Il faut garder en tête que ça nous coupe de quelques pages d'organismes publics hébergées sur des services comme "sites.google.com" (ce qui pour moi n'est pas un problème, mais il faut peut être le documenter dans le README aussi ? Prévenir qu'on est pas exhaustif.).
Oui, en effet.
OK pour dire dans le README que ce n'est pas exhaustif, juste en mode "best effort".
Et donc OK aussi pour ne pas inclure sites.google.com/* ni facebook.com/* (et consorts), même si le contenu présenté ressemble à un contenu de type "site institutionnel" plutôt qu'à du contenu de com' pure.
|
J'ai du mal à décider de ce qu'on doit faire de :
Je n'en cite quelques uns mais il y en a des centaines.
D'un côté ce sont bien des "organismes publics" qui y sont, le travail fourni pour la création du contenu délivré est bien financé par des finances publiques, mais le domaine est géré par une société privée, le contenu est délivré par une société privée.
Ce sont des "sous-domaines publics de domaines privés" ...
Je serai d'avis de les garder, qu'en pensez-vous ?
The text was updated successfully, but these errors were encountered: