We design a workflow to create a summary tree using the idea of recursive summarization of a discussion, where users build summaries of small sections of the discussion, small sets of those summaries are then aggregated and summarized, and so on until the entire discussion is incorporated into the layered summary tree.
Editors can then continue to create new summaries that can distill both previously-written summaries and unsummarized comments, until we are left with a summary of the entire discussion.
Even before the summary tree is complete, the summaries that people write in Wikum are embedded in the original discussion and contribute towards making the discussion easier to read. In threaded discussions, the summary of a subtree lives "Between" the comment and its parent.
Building the Summary Tree For readers of a discussion, Wikum lets them see a visual overview, differentiate between summaries and comments, explore into summaries, and jump between conversations.
If a summary of a subthread has been written, a person writing a summary at a higher level in the discussion thread can promote the lower summary to their position and build on the summary text; this lower summary can be a useful starting point for authoring the higher-level summary.
We chose to stop subjects working on both tasks after each Wikum summary was completed because we wanted to use our other user study participants to provide feedback on the Wikum summary qualities as opposed to spending all their study time finishing the Google Docs summaries.
A thousand words of summary is around two pages long, which may be more than someone is willing to read. However, because of recursive summarization in the Wikum case, users can read a 250-word summary of the entire discussion and drill in to get more detailed summaries.
À comparer avec le mien :p Il y a des trucs que j’ai pas dit et je dis des trucs qui n’y sont pas. Le automatique n’est pas ultra cohérent étant donné qu’il y a des détails sur l’expérience mais pas les résultats, ce qui est fâcheux. Niveau description des fonctionnalités par contre c’est pas mal.
Vous voulez dire quoi par « sur le même cozy » ? qu’on ne peut pas calculer une moyenne entre deux instances perso de Cozy parce que ce n’est pas « le même Cozy ? »
Ça me semble un peu paradoxal quand même. Il y a forcément une certaine quantité d’information qui « fuit » sur ces données. On se situe à la limite entre le cas ou le programme qui tourne sur le client fait un « return null » et un ou il fait un « return data accessibles » tel quel. Dans le cas intermédiaire il fait un traitement qu’on peut assimiler à une « compression » avec perte (plus ou moins importante) de l’ensemble des données.
Si l’enjeu c’est l’anonymat, la perte d’information doit être suffisamment importante pour qu’il soit compliqué de remonter à partir des données publiées jusqu’à l’émetteur de ces données. Cela dit si ce sont des données « privées » on a pas forcément de point de comparaison, effectivement. Est-ce que finalement il ne suffirait pas de publier les données privées en rendant les données de l’utilisateur qui sont accessibles par d’autres canaux (l’annuaire par ex) suffisamment « floues » (en ne conservant par exemple que des coordonnées tronquées pour l’adresse) pour qu’il soit difficile de faire le chemin inverse. La question clé serait alors « quelles informations on doit biffer / approximer / agréger » pour que les données publiées au final ne permette pas d’identifier les donateurs d’infos. Une histoire d’entropie des données utilisables pour l’identifier.
Après réflexion, je pense comprendre votre objectif : si les calculs ont lieux chez le client, il a le contrôle sur quel degré d’info il veut laisser fuiter.
On peut avoir des détails sur la thèse ? L’objectif au moins.
J’ai du mal à voir comment on peut constituer un jeu de donnée en garantissant (j’imagine) que les données restent chez soi (vu que c’est un des objectifs d’owncloud), un minimum d’information doit filtrer.
Par exemple pour calculer une moyenne (genre si on veut calculer la moyenne de l’age des gens qui participent) on peut faire ça de manière incrémentale. Ça nécessite deux nombre : un nombre pour la somme et un nombre pour le nombre de personne dont l’age a été sommé, la moyenne étant la division des deux. Si on imagine une chaîne entre les participants, le premier passe ces deux nombre au suivant, le second connaît l’age du premier (ce n’est plus vrai opur les suivants) … donc le premier ne doit pas passer directement l’info au second. Il pourrait passer par un tiers, l’expérimentateur, mais de même, l’expérimentateur doit peut en déduire l’âge du premier.
J’ai lu des trucs sur les systèmes homomorphes : http://www.pourlascience.fr/ewb_pages/a/article-chiffrement-homomorphe-deleguer-des-calculs-sans-divulguer-les-donnees-35907.php mais dans le cadre d’une expérience scientifique (ouverte), il peut être de bon ton de publier ses données anonymisées pour soumettre son analyse aux autres chercheurs qui voudraient refaire des calculs. Dans ce cas la question deviendrait, est-il possible de créer un jeu de données anonymisé de manière homomorphe, s’il s’agit d’effectuer les calculs chez les clients ?
Plus simplement, s’il s’agit simplement de constituer un jeu de données anonymisé, l’expérimentateur à une « clé privée », diffuse la clé publique à l’ensemble des participants qui chiffrent leurs données, agrègent ces données chiffrées entre eux puis finissent par renvoyer un jeu complet à l’expérimentateur qui a la clé de décryptage sans que l’expérimentateur puisse savoir qui a envoyé quoi mais en pouvant décrypter l’ensemble grâce à sa clé.
Une fois ce jeu anonymisé constitué, il peut servir à toutes les analyses qu’on veut …
Donc non, pour l,instant ça colle pas, tu ne peux pas faire d’étude épidémiologique en te créant un jeu avec les données de 1000 personnes et faire des stats dessus. Tu peux juste faire une analyse locale des données d’un individu.
A la rigueur j’ai l’impression que la fonctionnalité « partage » pourrait coller : «je partage ce type de données sur telle plage de temps avec ce groupe de chercheurs ».
Ça semble donc résoudre de problème du partage de données.
Pour le problème de format par contre je sais pas, Cozy semble être conçu pour que l’appli puisse définir ses propres types, donc n’impose par de format, un peu comme Wikidata. Il existe un catalogue de formats quelque part ? Ils parlent de tes données de poids dans les pages de présentation, pas trouvé l’exemple.
Le problème de validation des expés (confiance, relecture du code) et de la pub ne semble pas être traîté non plus. Il existe des catalogues d’appli Cozy ?
Faut savoir qu’étanchéifier ça a tendance à rendre le sol imperméable et donc faire monter l’eau et la faire ruisseler. Des circonstances plutôt aggravantes en fait …
Prévisions du GIEC : réchauffement implique plus de précipitations et une fréquence et une intensité accrue des événements extrême.
Il est évident que quand dans un contexte ou on bat quasiment d’une année sur l’autre le record d’années la plus chaude jamais enregistrée, avoir des événements extrêmes qui sont pas loin de battre des records fait dresser l’oreille. Alors oui, l’analyse du climat étant par nature statistique, les climatologues n’attribueront pas à un événement particulier l’étiquette « réchauffement climatique ». On commence cependant à voir des pourcentages d’attributions, peut être l’anomalie de l’intensité par rapport aux événements précédents (j’ai cru voir des chiffres genre 10 ou 30% pour Harvey)…
Oui je sais bien, mais autant je pense que la question se poserait complètement dans le cas d’un tremblement de terre, autant pour un ouragan sur une île pas très grande qui risque de perdre de sa surface à court/moyen terme, ça me semble un peu vain. Mais ce n’est que mon avis.
Rajoute la montée du niveau des océans dans l’équation et tu auras beau avoir construit des bâtiments solides (et sans doute chers, donc pas accessibles à tous) ils résisteront pas à la submersion si ils sont trop bas.
Tout ne se règle pas avec des normes de construction.
Si tu réécris la sémantique en OWL en plus de la grammaire (mais du coup on a juste besoin de réécrire l’AST) ptete que ça peut devenir intéressant question raisonnement ;)
J’ai acheté mon vélo il y a plus de 10 ans et à l’époque j’ai pas acheté de casque avec. Je connais des mecs qui font absolument tout bien et ont un équipement choisi, réfléchi et qui font absolument tout à vélo. Deux remarques : la première : j’en connais un seul, en fait, et la deuxième : Il n’attache pas son casque, il le trimballe tout le temps avec lui, avec ses sacoches, il monte le vélo dans son appart dans l’ascenseur . bref, c’est assez pénible et ça ne donne pas forcément envie.
je ne me cherche pas des excuses.
Bref, tu en fais une question de morale. Là ou les pouvoirs publics cherchent l’efficacité. La question de morale part d’une hypothèse : mettre un casque, c’est bien. Ne pas le mettre, c’est donc être un mauvais citoyen. C’est assez pratique, ça empêche de se poser des questions genre l’impact réel dans toutes les dimensions du problème et fermer le débat en taxant de mauvaise foi.
Moi j’ai la flemme de faire quelques km à vélo … pour m’acheter un casque, en tout cas. Et oui, c’est parfois très chiant d’attacher son vélo. Pas la mer à boire évidemment, mais si tu rajoutes un casque dans l’équation ça facilite rien. Ils ont l’air de faire des antivols spéciaux pour casque : https://www.lecyclo.com/velo/securite/antivols/cadre-et-casque/antivol-pour-casque-et-selle-de-velo-combiflex-abus.html La sécurité par contre … déja qu’on conseille des antivols en U, un truc avec un câble aussi fin, c’est ridicule.
Tu rajoutes des trucs importants quand tu roules beaucoup, les protections contre la pluie, les lumières qu’il faut enlever (les trucs qui font pester les automobilistes parce qu’à la rentrée tout le monde en a mais en fin d’année les piles sont mortes ou que les deliveroo ont à peine les moyens de se payer, en tout cas ils en ont rarement), et là tu bloques tout un sac à dos rien que pour les accessoires et ça devient pénible de transporter autre chose, Faut donc mettre des sacoches et/ou un porte bagage en plus, donc penser aux tendeurs … il n’y a pas de coffre fermé sur un vélo.
Une des forces du vélo c’est sa légèreté d’utilisation. À force de ci ou ça, on peut perdre beaucoup et finalement « oh puis merde, je prend la bagnole/le métro/mes pieds »
La clé, c’est qu’on parle de raisonnement et pas de « programmation » au sens traditionnel.
Il y a un genre de « sémantique » aussi chez les universitaires quand on parle de programmation, Sémantique des langages de programmation. Mais c’est différent, on parle de « c’est quoi un programme qui fait ce qu’on lui demande » ou « que fait un programme ». Il s’agit de spécifier, dans un langage « autre » comme un langage logique mathématique les propriétés du programme qu’on veut écrire, de vérifier que notre programme fait bien ce qu’on avait l’intention de lui faire faire.
Ici c’est différent, on parle avant tout de donner des propriétés des données et des structures de données qui permettent de raisonner, de lui brancher un moteur de raisonnement logique type prolog qui permettent de vérifier, à terme, si notre jeu de données est propre. Par exemple en partant de la définition d’un logiciel libre, on peut détecter si un logiciel dans nos données est marqué à la fois comme libre et comme non redistribuable. Une telle erreur détectée par le moteur de raisonnement indique soit qu’on a un problème dans nos données soit qu’on a un problème dans notre ontologie.
Pour faire le lien avec le monde des langage de programmation, on peut imaginer qu’une fonction buguée fasse un traitement sur les donnés qui renvoie parfois un logiciel à la fois libre et non redistribuable. On dit que cette fonction « casse l’invariant » dans la méthode B par exemple. L’invariant étant une proprété logique que douvent tout le temps (enfin « atomiquement » on va dire, au cours d’une opération on est autorisé à le casser) respecter les données. Pr exemple, qeu le nombre de ticket vendu doit ètre inférieur au nombre de place disponibles. Si tu lance le moteur d’inférence après un tel cas de figure, tu auras détecté un bug du programme (ou de l’ontologie encore une fois).
J’ai l’impression que d’une certaine manière ici brancher une ontologie OWL sur un programme python est le moyen de brancher un tel invariant sur python, donc de définir certaines propriétés de la sémantique attendue du programme.
Ben, la flemme ça se surmonte, parfois. Seulement quand tu trouves la motivation mais que finalement tu trouves pas ton casque, c’est le genre de truc qui n’aide pas à surmonter sa flemme.
Ben l’autodérision, c’est quand tu te moques de toi même, pas quand on se fout de ta gueule. Et là oui, ça peut faire sourire au premier abord. Puis après tu réfléchis un peu et là ça devient complètement « wtf » remis un peu en contexte.
Ça mérite du détail. Je suis censé lire tous les résultats du moteur de recherche pour savoir si les community manager sont censés être engagés par des lobbys et commenter incognito sur les journaux en ligne ?
Mouais, tu nous sors surtout sans aucune critique le discours traditionnel du progrès triomphant. Et il n’est pas jeune. Je te rejoins sur le jardinage avec la Lune, bien que je ne sois pas certain que ce soit si « hyper récent » que ça, mais pour le reste tu es en mode « arrière garde » :
« OK il y a des problèmes mais c’est la faute de [la distribution] … et pas du paradigme dominant»
Variante de « OK il y a des incendies mais il faut surtout travailler sur … et pas sur le réchauffement climatique »
Tu reconnais le problème parce que tu ne peux pas faire autrement, mais c’est reculer pour mieux sauter parce que c’est pour dire « mais c’est juste un effet de bord ». Et là tu rajoutes la caricature biobio pour mieux assimiler les critiques à un groupe d’illuminés pas sérieux.
Faut changer de disque à un moment et se dire que peut être que la solution ne passe pas par la défense bec et ongle de l’existant. C’est fermer la porte à des solutions potentielles de manière dogmatique. Genre se tourner du côté de l’INRA ou des chercheurs en agronomie qui font des travaux sérieux. Ça évite les caricatures rassurantes du passé que tu nous sors : Je suis persuadé qu’il y avait des paysans pauvres, mais il y avait également des régions qui nourrissaient des villes qui étaient certainement plus prospères.
Mais dans le cadre des changements de paradigmes, il est bien connu que les vielles idées ne meurent qu’avec la mort des derniers bornés qui n’ont plus changé d’idée depuis leurs 15 ans :p
Il semble que le semi sans labour puisse marcher. Mais si le sol est abîmé - genre sol « limoneux » fragile - il semble qu’il faille labourer. Et qu’on ne peux pas vraiment savoir sans une connaissance de l’historique.
Donc il semble que la situation soit bien plus nuancée que ce que tu présentes (ça marche pas) et que … ça ne règle pas le problème de la restauration des sols abîmés. Ça aide juste à ne pas les abîmés. Mais que pour cultiver sur les sols abîmés ont ait besoin de les abîmer d’avantage ? Ça n’a pas l’air durable.
Ce n’est pas solide étant donné que j’ai juste lu un bout de la conclusion et pondu ça en 30 seconde en extrapolant comme un malade, mais ton commentaire péremptoire m’a titillé.
Enfin bref, qu'importe le langage, ça serait un gigantesque travail de tout porter, et peut-être pas très utile.
Je ne commenterai pas sur le les avantages de lisp vs. python, il y aurait sûrement des tonnes de trucs à faire partir en cacahuète, par contre j’imagine qu’emacs se traîne des pelletées de code historique et que ça doit pas être méga simple de faire du nettoyage. Dans ces conditions se reposer des questions de design pourrait peut être bénbfique pour coder enfin emacsOS. Mais ptete que jme goure et que c’est proprifié de génération en génération de dinosaure.
[^] # Re: du boulot!
Posté par Thomas Douillard . En réponse au journal Wikum : Résumé et récursion. Évalué à 3.
Un copier/coller du résumé de l’article :
(paramètres par défaut)
http://smmry.com/https://people.csail.mit.edu/axz/papers/wikum.pdf#&SM_LENGTH=7
À comparer avec le mien :p Il y a des trucs que j’ai pas dit et je dis des trucs qui n’y sont pas. Le automatique n’est pas ultra cohérent étant donné qu’il y a des détails sur l’expérience mais pas les résultats, ce qui est fâcheux. Niveau description des fonctionnalités par contre c’est pas mal.
[^] # Re: Cozy ?
Posté par Thomas Douillard . En réponse au journal Comment concilier partage de ses données personnelles et vie privée ?. Évalué à 2.
Ça se passe comment pour l’agrégation ?
Vous voulez dire quoi par « sur le même cozy » ? qu’on ne peut pas calculer une moyenne entre deux instances perso de Cozy parce que ce n’est pas « le même Cozy ? »
[^] # Re: Cozy ?
Posté par Thomas Douillard . En réponse au journal Comment concilier partage de ses données personnelles et vie privée ?. Évalué à 3.
Ça me semble un peu paradoxal quand même. Il y a forcément une certaine quantité d’information qui « fuit » sur ces données. On se situe à la limite entre le cas ou le programme qui tourne sur le client fait un « return null » et un ou il fait un « return data accessibles » tel quel. Dans le cas intermédiaire il fait un traitement qu’on peut assimiler à une « compression » avec perte (plus ou moins importante) de l’ensemble des données.
Si l’enjeu c’est l’anonymat, la perte d’information doit être suffisamment importante pour qu’il soit compliqué de remonter à partir des données publiées jusqu’à l’émetteur de ces données. Cela dit si ce sont des données « privées » on a pas forcément de point de comparaison, effectivement. Est-ce que finalement il ne suffirait pas de publier les données privées en rendant les données de l’utilisateur qui sont accessibles par d’autres canaux (l’annuaire par ex) suffisamment « floues » (en ne conservant par exemple que des coordonnées tronquées pour l’adresse) pour qu’il soit difficile de faire le chemin inverse. La question clé serait alors « quelles informations on doit biffer / approximer / agréger » pour que les données publiées au final ne permette pas d’identifier les donateurs d’infos. Une histoire d’entropie des données utilisables pour l’identifier.
Après réflexion, je pense comprendre votre objectif : si les calculs ont lieux chez le client, il a le contrôle sur quel degré d’info il veut laisser fuiter.
[^] # Re: Retroshare
Posté par Thomas Douillard . En réponse au journal Comment concilier partage de ses données personnelles et vie privée ?. Évalué à 2.
Oui ?
[^] # Re: Cozy ?
Posté par Thomas Douillard . En réponse au journal Comment concilier partage de ses données personnelles et vie privée ?. Évalué à 2.
On peut avoir des détails sur la thèse ? L’objectif au moins.
J’ai du mal à voir comment on peut constituer un jeu de donnée en garantissant (j’imagine) que les données restent chez soi (vu que c’est un des objectifs d’owncloud), un minimum d’information doit filtrer.
Par exemple pour calculer une moyenne (genre si on veut calculer la moyenne de l’age des gens qui participent) on peut faire ça de manière incrémentale. Ça nécessite deux nombre : un nombre pour la somme et un nombre pour le nombre de personne dont l’age a été sommé, la moyenne étant la division des deux. Si on imagine une chaîne entre les participants, le premier passe ces deux nombre au suivant, le second connaît l’age du premier (ce n’est plus vrai opur les suivants) … donc le premier ne doit pas passer directement l’info au second. Il pourrait passer par un tiers, l’expérimentateur, mais de même, l’expérimentateur doit peut en déduire l’âge du premier.
J’ai lu des trucs sur les systèmes homomorphes : http://www.pourlascience.fr/ewb_pages/a/article-chiffrement-homomorphe-deleguer-des-calculs-sans-divulguer-les-donnees-35907.php mais dans le cadre d’une expérience scientifique (ouverte), il peut être de bon ton de publier ses données anonymisées pour soumettre son analyse aux autres chercheurs qui voudraient refaire des calculs. Dans ce cas la question deviendrait, est-il possible de créer un jeu de données anonymisé de manière homomorphe, s’il s’agit d’effectuer les calculs chez les clients ?
Plus simplement, s’il s’agit simplement de constituer un jeu de données anonymisé, l’expérimentateur à une « clé privée », diffuse la clé publique à l’ensemble des participants qui chiffrent leurs données, agrègent ces données chiffrées entre eux puis finissent par renvoyer un jeu complet à l’expérimentateur qui a la clé de décryptage sans que l’expérimentateur puisse savoir qui a envoyé quoi mais en pouvant décrypter l’ensemble grâce à sa clé.
Une fois ce jeu anonymisé constitué, il peut servir à toutes les analyses qu’on veut …
[^] # Re: Cozy ?
Posté par Thomas Douillard . En réponse au journal Comment concilier partage de ses données personnelles et vie privée ?. Évalué à 2.
Donc non, pour l,instant ça colle pas, tu ne peux pas faire d’étude épidémiologique en te créant un jeu avec les données de 1000 personnes et faire des stats dessus. Tu peux juste faire une analyse locale des données d’un individu.
A la rigueur j’ai l’impression que la fonctionnalité « partage » pourrait coller : «je partage ce type de données sur telle plage de temps avec ce groupe de chercheurs ».
[^] # Re: Cozy ?
Posté par Thomas Douillard . En réponse au journal Comment concilier partage de ses données personnelles et vie privée ?. Évalué à 2.
Intéressant. Je n’avais jamais regardé Cozy de près.
Je ne sais pas si c’est totalement ça. J’ai quelques questions :
A priori oui : https://github.com/Ljinod/cozy-docs/blob/master/src/documents/en/hack/cookbooks/sharing.html.md
Ça semble donc résoudre de problème du partage de données.
Pour le problème de format par contre je sais pas, Cozy semble être conçu pour que l’appli puisse définir ses propres types, donc n’impose par de format, un peu comme Wikidata. Il existe un catalogue de formats quelque part ? Ils parlent de tes données de poids dans les pages de présentation, pas trouvé l’exemple.
Le problème de validation des expés (confiance, relecture du code) et de la pub ne semble pas être traîté non plus. Il existe des catalogues d’appli Cozy ?
[^] # Re: préparation
Posté par Thomas Douillard . En réponse au journal Le jour d’après, c’est aujourd’hui. Évalué à 3.
Faut savoir qu’étanchéifier ça a tendance à rendre le sol imperméable et donc faire monter l’eau et la faire ruisseler. Des circonstances plutôt aggravantes en fait …
[^] # Re: Attention, n'allons pas trop vite…
Posté par Thomas Douillard . En réponse au journal Le jour d’après, c’est aujourd’hui. Évalué à 1. Dernière modification le 08 septembre 2017 à 14:26.
Et bien bien sur que ça apporte une lumière.
Prévisions du GIEC : réchauffement implique plus de précipitations et une fréquence et une intensité accrue des événements extrême.
Il est évident que quand dans un contexte ou on bat quasiment d’une année sur l’autre le record d’années la plus chaude jamais enregistrée, avoir des événements extrêmes qui sont pas loin de battre des records fait dresser l’oreille. Alors oui, l’analyse du climat étant par nature statistique, les climatologues n’attribueront pas à un événement particulier l’étiquette « réchauffement climatique ». On commence cependant à voir des pourcentages d’attributions, peut être l’anomalie de l’intensité par rapport aux événements précédents (j’ai cru voir des chiffres genre 10 ou 30% pour Harvey)…
Du coup ton « ça n’a aucun rapport » quand on nous dit d’un autre côté « faut s’y habituer » (ex parmi d’autre : https://www.sciencesetavenir.fr/nature-environnement/le-rechauffement-climatique-facteur-aggravant-du-risque-d-inondation_10389 hors contexte puisque l’article est de 2013)
[^] # Re: préparation
Posté par Thomas Douillard . En réponse au journal Le jour d’après, c’est aujourd’hui. Évalué à 2.
Oui je sais bien, mais autant je pense que la question se poserait complètement dans le cas d’un tremblement de terre, autant pour un ouragan sur une île pas très grande qui risque de perdre de sa surface à court/moyen terme, ça me semble un peu vain. Mais ce n’est que mon avis.
[^] # Re: préparation
Posté par Thomas Douillard . En réponse au journal Le jour d’après, c’est aujourd’hui. Évalué à -2.
Rajoute la montée du niveau des océans dans l’équation et tu auras beau avoir construit des bâtiments solides (et sans doute chers, donc pas accessibles à tous) ils résisteront pas à la submersion si ils sont trop bas.
Tout ne se règle pas avec des normes de construction.
[^] # Re: Idée de projet inutile
Posté par Thomas Douillard . En réponse à la dépêche Owlready : un module Python pour manipuler les ontologies OWL. Évalué à 3.
Si tu réécris la sémantique en OWL en plus de la grammaire (mais du coup on a juste besoin de réécrire l’AST) ptete que ça peut devenir intéressant question raisonnement ;)
Ptete qu’on risque de tomber sur des problèmes de décidabilité par contre : https://www.cs.ox.ac.uk/boris.motik/pubs/motik07metamodeling-journal.pdf
[^] # Re: VW
Posté par Thomas Douillard . En réponse au journal Vélo vs Voiture : le tro^W^W la controverse s’intensifie. Évalué à 2.
Un truc plus intéressant sur la question : http://sante.lefigaro.fr/actualite/2016/09/23/25436-port-casque-velo-reduit-bien-risques
Par contre, en commentaire, on parle de velib’. Et pour le coup, fait triblarrer un casque si tu prend un vélib’ par exemple ?
[^] # Re: VW
Posté par Thomas Douillard . En réponse au journal Vélo vs Voiture : le tro^W^W la controverse s’intensifie. Évalué à 3.
J’ai acheté mon vélo il y a plus de 10 ans et à l’époque j’ai pas acheté de casque avec. Je connais des mecs qui font absolument tout bien et ont un équipement choisi, réfléchi et qui font absolument tout à vélo. Deux remarques : la première : j’en connais un seul, en fait, et la deuxième : Il n’attache pas son casque, il le trimballe tout le temps avec lui, avec ses sacoches, il monte le vélo dans son appart dans l’ascenseur . bref, c’est assez pénible et ça ne donne pas forcément envie.
Bref, tu en fais une question de morale. Là ou les pouvoirs publics cherchent l’efficacité. La question de morale part d’une hypothèse : mettre un casque, c’est bien. Ne pas le mettre, c’est donc être un mauvais citoyen. C’est assez pratique, ça empêche de se poser des questions genre l’impact réel dans toutes les dimensions du problème et fermer le débat en taxant de mauvaise foi.
[^] # Re: VW
Posté par Thomas Douillard . En réponse au journal Vélo vs Voiture : le tro^W^W la controverse s’intensifie. Évalué à 3.
Moi j’ai la flemme de faire quelques km à vélo … pour m’acheter un casque, en tout cas. Et oui, c’est parfois très chiant d’attacher son vélo. Pas la mer à boire évidemment, mais si tu rajoutes un casque dans l’équation ça facilite rien. Ils ont l’air de faire des antivols spéciaux pour casque : https://www.lecyclo.com/velo/securite/antivols/cadre-et-casque/antivol-pour-casque-et-selle-de-velo-combiflex-abus.html La sécurité par contre … déja qu’on conseille des antivols en U, un truc avec un câble aussi fin, c’est ridicule.
Tu rajoutes des trucs importants quand tu roules beaucoup, les protections contre la pluie, les lumières qu’il faut enlever (les trucs qui font pester les automobilistes parce qu’à la rentrée tout le monde en a mais en fin d’année les piles sont mortes ou que les deliveroo ont à peine les moyens de se payer, en tout cas ils en ont rarement), et là tu bloques tout un sac à dos rien que pour les accessoires et ça devient pénible de transporter autre chose, Faut donc mettre des sacoches et/ou un porte bagage en plus, donc penser aux tendeurs … il n’y a pas de coffre fermé sur un vélo.
Une des forces du vélo c’est sa légèreté d’utilisation. À force de ci ou ça, on peut perdre beaucoup et finalement « oh puis merde, je prend la bagnole/le métro/mes pieds »
[^] # Re: j'ai pas tout saisi.
Posté par Thomas Douillard . En réponse à la dépêche Owlready : un module Python pour manipuler les ontologies OWL. Évalué à 4.
La clé, c’est qu’on parle de raisonnement et pas de « programmation » au sens traditionnel.
Il y a un genre de « sémantique » aussi chez les universitaires quand on parle de programmation, Sémantique des langages de programmation. Mais c’est différent, on parle de « c’est quoi un programme qui fait ce qu’on lui demande » ou « que fait un programme ». Il s’agit de spécifier, dans un langage « autre » comme un langage logique mathématique les propriétés du programme qu’on veut écrire, de vérifier que notre programme fait bien ce qu’on avait l’intention de lui faire faire.
Ici c’est différent, on parle avant tout de donner des propriétés des données et des structures de données qui permettent de raisonner, de lui brancher un moteur de raisonnement logique type prolog qui permettent de vérifier, à terme, si notre jeu de données est propre. Par exemple en partant de la définition d’un logiciel libre, on peut détecter si un logiciel dans nos données est marqué à la fois comme libre et comme non redistribuable. Une telle erreur détectée par le moteur de raisonnement indique soit qu’on a un problème dans nos données soit qu’on a un problème dans notre ontologie.
Pour faire le lien avec le monde des langage de programmation, on peut imaginer qu’une fonction buguée fasse un traitement sur les donnés qui renvoie parfois un logiciel à la fois libre et non redistribuable. On dit que cette fonction « casse l’invariant » dans la méthode B par exemple. L’invariant étant une proprété logique que douvent tout le temps (enfin « atomiquement » on va dire, au cours d’une opération on est autorisé à le casser) respecter les données. Pr exemple, qeu le nombre de ticket vendu doit ètre inférieur au nombre de place disponibles. Si tu lance le moteur d’inférence après un tel cas de figure, tu auras détecté un bug du programme (ou de l’ontologie encore une fois).
J’ai l’impression que d’une certaine manière ici brancher une ontologie OWL sur un programme python est le moyen de brancher un tel invariant sur python, donc de définir certaines propriétés de la sémantique attendue du programme.
[^] # Re: VW
Posté par Thomas Douillard . En réponse au journal Vélo vs Voiture : le tro^W^W la controverse s’intensifie. Évalué à 1.
Ben, la flemme ça se surmonte, parfois. Seulement quand tu trouves la motivation mais que finalement tu trouves pas ton casque, c’est le genre de truc qui n’aide pas à surmonter sa flemme.
[^] # Re: Le sens de l'humour, c'était mieux avant
Posté par Thomas Douillard . En réponse au journal Vélo vs Voiture : le tro^W^W la controverse s’intensifie. Évalué à 10.
Ben l’autodérision, c’est quand tu te moques de toi même, pas quand on se fout de ta gueule. Et là oui, ça peut faire sourire au premier abord. Puis après tu réfléchis un peu et là ça devient complètement « wtf » remis un peu en contexte.
[^] # Re: est-ce que ce type de signature …
Posté par Thomas Douillard . En réponse au journal Vélo vs Voiture : le tro^W^W la controverse s’intensifie. Évalué à 5.
Ça mérite du détail. Je suis censé lire tous les résultats du moteur de recherche pour savoir si les community manager sont censés être engagés par des lobbys et commenter incognito sur les journaux en ligne ?
[^] # Re: Et pendant ce temps là...
Posté par Thomas Douillard . En réponse au journal Désactiver l'Intel ME: merci la NSA. Évalué à 2.
https://tech.slashdot.org/comments.pl?sid=11045309&cid=55101019
[^] # Re: A suivre
Posté par Thomas Douillard . En réponse à la dépêche Open Source Seeds : les graines de tomates libres. Évalué à 10.
Mouais, tu nous sors surtout sans aucune critique le discours traditionnel du progrès triomphant. Et il n’est pas jeune. Je te rejoins sur le jardinage avec la Lune, bien que je ne sois pas certain que ce soit si « hyper récent » que ça, mais pour le reste tu es en mode « arrière garde » :
« OK il y a des problèmes mais c’est la faute de [la distribution] … et pas du paradigme dominant»
Variante de « OK il y a des incendies mais il faut surtout travailler sur … et pas sur le réchauffement climatique »
Tu reconnais le problème parce que tu ne peux pas faire autrement, mais c’est reculer pour mieux sauter parce que c’est pour dire « mais c’est juste un effet de bord ». Et là tu rajoutes la caricature biobio pour mieux assimiler les critiques à un groupe d’illuminés pas sérieux.
Faut changer de disque à un moment et se dire que peut être que la solution ne passe pas par la défense bec et ongle de l’existant. C’est fermer la porte à des solutions potentielles de manière dogmatique. Genre se tourner du côté de l’INRA ou des chercheurs en agronomie qui font des travaux sérieux. Ça évite les caricatures rassurantes du passé que tu nous sors : Je suis persuadé qu’il y avait des paysans pauvres, mais il y avait également des régions qui nourrissaient des villes qui étaient certainement plus prospères.
Mais dans le cadre des changements de paradigmes, il est bien connu que les vielles idées ne meurent qu’avec la mort des derniers bornés qui n’ont plus changé d’idée depuis leurs 15 ans :p
[^] # Re: les graines en France
Posté par Thomas Douillard . En réponse à la dépêche Open Source Seeds : les graines de tomates libres. Évalué à 9.
Intrigué par ton affirmation sur l’effet de mode, effet de mode retours, j’ai rapidement requêté google, et j’ai trouvé cette source : http://agriculture-de-conservation.com/sites/agriculture-de-conservation.com/IMG/pdf/christian_roisin.pdf
Il semble que le semi sans labour puisse marcher. Mais si le sol est abîmé - genre sol « limoneux » fragile - il semble qu’il faille labourer. Et qu’on ne peux pas vraiment savoir sans une connaissance de l’historique.
Donc il semble que la situation soit bien plus nuancée que ce que tu présentes (ça marche pas) et que … ça ne règle pas le problème de la restauration des sols abîmés. Ça aide juste à ne pas les abîmés. Mais que pour cultiver sur les sols abîmés ont ait besoin de les abîmer d’avantage ? Ça n’a pas l’air durable.
Ce n’est pas solide étant donné que j’ai juste lu un bout de la conclusion et pondu ça en 30 seconde en extrapolant comme un malade, mais ton commentaire péremptoire m’a titillé.
[^] # Re: Le troll n'est pas sorti ?!
Posté par Thomas Douillard . En réponse à la dépêche Nouvelles de KDE (saison 2016-2017). Évalué à 5.
En gros, kde est un logiciel ultra configurable mais qui marche plus si tu changes quoi que ce soit ?
[^] # Re: en fait Emacs est très facile. Enfin le lisp.
Posté par Thomas Douillard . En réponse au journal Participer à l'amélioration de l'expérience utilisateur d'Emacs (c'est facile). Évalué à 2.
Je ne commenterai pas sur le les avantages de lisp vs. python, il y aurait sûrement des tonnes de trucs à faire partir en cacahuète, par contre j’imagine qu’emacs se traîne des pelletées de code historique et que ça doit pas être méga simple de faire du nettoyage. Dans ces conditions se reposer des questions de design pourrait peut être bénbfique pour coder enfin emacsOS. Mais ptete que jme goure et que c’est proprifié de génération en génération de dinosaure.
[^] # Re: les conventions sur les raccourcis!!!!
Posté par Thomas Douillard . En réponse au journal Participer à l'amélioration de l'expérience utilisateur d'Emacs (c'est facile). Évalué à 2.
Ben ça en fait carrément partie :)