L’idée c’est de débattre et de supprimer les silos, donc c’est fort possible. C’est presque le but. Mais l’idée ça a aussi l’air de pas refaire 43 milles fois le match, genre comme c’est possible en relançant un thread sur linuxfr ou tu vas dupliquer la même discussion.
Donc les farfelus, tout l’enjeu technique est de fournir des moyens de leur faire comprendre que le match à déjà eu lieux et que les arguments on déjà été donnés.
Je sais que ce n'est pas du tout ton objectif principal, mais si tu arrétais de personnaloser les débats àtpjt bout de champ ce serait quand même une bonne chose pour l'ambiance.
Il ne suffit pas de ne pas permettre des commentaires de résumé ?
Dans le papier il notent le fait qu’on note un début de «culture» du résumé avec les pratiques des participants qui s’alignent sur les pratiques des premier contributeurs du résumé, ça note que la communauté adopte une position pragmatique. Je pense que cette «culture» peut se bonifier avec l’expérience, et je pense aussi qu’elle se baserai sur l’intérêt communautaire bien compris (faire un résumé utile), et pas sur une volonté de discuter chaque virgule. En particulier, sur ce que tu dis, je pense qu’il s’agit de dépersonnaliser les arguments (ne pas évoquer « machin »), et mentionner le problème en question et ne pas le qualifier
Dans cette approche, j’ai l’impression que l’utilité est aussi de servir de « poteau indicateur » et de jouer le rôle de « sommaire » de la discussion.
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 ?
[^] # Re: Trollons
Posté par thoasm . En réponse à la dépêche Le développement de « Débattons » est lancé !. Évalué à 2.
L’idée c’est de débattre et de supprimer les silos, donc c’est fort possible. C’est presque le but. Mais l’idée ça a aussi l’air de pas refaire 43 milles fois le match, genre comme c’est possible en relançant un thread sur linuxfr ou tu vas dupliquer la même discussion.
Donc les farfelus, tout l’enjeu technique est de fournir des moyens de leur faire comprendre que le match à déjà eu lieux et que les arguments on déjà été donnés.
[^] # Re: XMPP, Pas facile de s'y retrouver
Posté par thoasm . En réponse à la dépêche Sortie du très attendu Prosody 0.10. Évalué à 9.
Je sais que ce n'est pas du tout ton objectif principal, mais si tu arrétais de personnaloser les débats àtpjt bout de champ ce serait quand même une bonne chose pour l'ambiance.
# Resumé
Posté par thoasm . En réponse à la dépêche Le développement de « Débattons » est lancé !. Évalué à 4.
Vous avez connaissance de systèmes de résumé comme wikum ? Cf. https://linuxfr.org/users/thoasm/journaux/wikum-resume-et-recursion ca me semble intéressant à considérer pour une telle plateforme.
[^] # Re: Trollons
Posté par thoasm . En réponse à la dépêche Le développement de « Débattons » est lancé !. Évalué à 3.
J'ai l'impression que c'est précisément ce qu'ils cherchent à éviter.
[^] # Re: du boulot!
Posté par thoasm . En réponse au journal Wikum : Résumé et récursion. Évalué à 4.
Il ne suffit pas de ne pas permettre des commentaires de résumé ?
Dans le papier il notent le fait qu’on note un début de «culture» du résumé avec les pratiques des participants qui s’alignent sur les pratiques des premier contributeurs du résumé, ça note que la communauté adopte une position pragmatique. Je pense que cette «culture» peut se bonifier avec l’expérience, et je pense aussi qu’elle se baserai sur l’intérêt communautaire bien compris (faire un résumé utile), et pas sur une volonté de discuter chaque virgule. En particulier, sur ce que tu dis, je pense qu’il s’agit de dépersonnaliser les arguments (ne pas évoquer « machin »), et mentionner le problème en question et ne pas le qualifier
Dans cette approche, j’ai l’impression que l’utilité est aussi de servir de « poteau indicateur » et de jouer le rôle de « sommaire » de la discussion.
[^] # Re: du boulot!
Posté par thoasm . 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 thoasm . 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 thoasm . 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 thoasm . En réponse au journal Comment concilier partage de ses données personnelles et vie privée ?. Évalué à 2.
Oui ?
[^] # Re: Cozy ?
Posté par thoasm . 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 thoasm . 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 thoasm . 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 thoasm . 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 thoasm . 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 thoasm . 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 thoasm . 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 thoasm . 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 thoasm . 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 thoasm . 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 thoasm . 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 thoasm . 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 thoasm . 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 thoasm . 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 thoasm . 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 thoasm . 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