thoasm a écrit 9443 commentaires

Très sympa comme interview, j’aime le détachement et le sens de l’humour dont il fait preuve.

Un truc me fait tilter : d’un côté il semble preneur de toute personne qui pourrait lui virer du boulôt, mais d’un autre il se la joue élitiste en parlant des gens qui ont à un moment tenté d’insérer des technos « à la mode » pour lesquelles c’est probablement plus simple de trouver des compétences. Ça n’aurait pas aussi tendance à diminuer la qualité et à faire fuir les contrbuteurs de maitenir les choses plus « difficiles » ?

Hum, tu as l'air de supposer que les designer de métier ne sont pas formés aux problématiques d'accessibilité … J'ai plutôt l'impression qu'une formation en design digne de ce nom doit obligatoirement prendre cet aspect en compte.

Du coup les numéro de port sont carrément analogues aux "file descriptor" unix. J'ai jamais vraiment utilisé netcat, mais du coup la séparation "net" et "cat" prend tout son sens.

On a vraiment l'équivalent des tricks de magie noire qu'on peut faire avec les redirection d'entrée sorties, mais par le réseau.

Il y a plein de résultats pour https://www.google.fr/search?q=xmldiff A tester.

J'ai regardé la présentation que tu as lié. J'ai l'impression d'avoir compris tous les bouts, c'est passionnant et tout, mais j'ai pas bien saisi l'ensemble.

J'adore la manière dont le gars se repère dans le labyrinthe de techno informatique (ou pas), prend ce qui l'intéresse, réimplémente les truc qu'il veut maîtriser et l'analyse qu'il a des problèmes. Je suis infoutu (et je me permettrai pas) de critiquer ce qu'il fait à mon niveau, en même temps j'ai l'impression qu'il y a des milliards de trucs à dire. Le type est un génie du touche à tout. Il a aussi une motivation à toute épreuve, des années de travail sur un projet à très long terme …

Bref, j'ai un curieux sentiment mélange de "wtf" et d'admiration sans borne :) Du travail passionnant à plus d'un titre, mélange de physique, d'informatique et de biologie à en inspirer des réflexions métaphysiques.

faut coder une fonction bash-completion. C'est pas très dur.

Pourquoi pas. Mais bon à mon avis il y a des tas d'autres problèmes à régler avant d'en arriver à ce genre de raffinement. Par exemple un mot peut avoir de toutes façon plusieurs significations dans différents contextes. Déjà rien que détecter ça serait intéressant … Après raffiner jusqu'à créer des groupes d'utilisateurs qui parlent des dialectes en apprentissage non supervisé dans toutes les langues du monde et de classer automatiquement les utilisateurs dans un de ces groupes, c'est tout autre chose.

Et de toute façon j'ai l'impression qu'il s'agit de rajouter des liens dans les réponses plutôt que d'en disqualifier, dans ce cas précis. au pire donc tu chercheras à préciser ta requête …

Curryfication ?

Tu voudrais valider par l'analyse du web existant que l'usage des deux termes se confond avec le temps ?

Pas du tout. L'idée serait plutôt de détecter que les deux questions ont grosso modo la même signification et donc que les résultats les plus pertinents pour l'un et donc que les résultats pertinents sont sans doutes les mêmes aux deux requêtes.

Le fait qu'il y ait plusieurs niveaux de langues n'est probablement pas un obstacles, surtout pour les techniques statistiques. Genre le mot "truc" qui veut tout et rien dire sera facilement détecté comme terme générique synonyme de "machin" parce qu'ils vont tous les deux être utilisé dans des tonnes de contextes.

Si on essaye d'inférer une hiérarchie "est un" à la mode "l'homme un singe" "un singe est un animal" on aura sûrement "un homme est un truc" comme "un stylo est un truc" ce qui fait que "truc" se situera très haut dans la hiérarchie. Ou au contraire que certains termes sont des cas particuliers parce qu'ils s'utilisent dans des contextes compatibles mais plus spécifiques

Les niveaux de langues, les techniques statistiques n'en ont cure, et les techniques de construction de dico structuré peuvent les rajouter complètement manuellement au cas ou les stats se planteraient en annotant avec des connotations par exemple - et le wiktionnaire structuré de la fondation Wikimédia est parti pour permettre de définir communautairement les type d'annotation à l'envie.

Je pense même que les opérations sur les vecteurs risquent même de permettre de détecter les champs lexicaux "parallèles" au sens où deux jargons peuvent être développés par deux communauté disjointe et que la machine va détecter comme une grande que ces deux communauté parlent de la même chose alors qu'elles même l'ignorent …

Sinon sur le côté "vieux con" j'ai même pas envie de te suivre tellement ça n'a juste aucun rapport.

Je ne peux pas m'empêcher de rapprocher ton expérience de cette tribune récente qui plaide pour la fusion des mutuelles : http://www.lemonde.fr/idees/article/2017/01/14/creons-une-assurance-maladie-universelle_5062590_3232.html

Et si finalement la jungle de la privatisation - fusion avait pour résultat une jungle ou tous le monde tire les coûts vers le bas et se défausse de ses responsabilité, au prix d'une complexification de la vie du "client" que la concurrence exacerbe ? Une bonne vieille organisation centralisée n'aurait pas aussi des avantages ?

En l'occurrence, techniquement pour résoudre ça de manière générale faut faire une analyse sémantique pour comprendre que "rôle" et "fonction" sont probablement interchangeables. Ça peut se faire, c'est plus ou moins en cours par plusieurs approches :

• les dico structuré, par ex http://www.omegawiki.org/Expression:r%C3%B4le - mais là on voit que leurs données sont incomplètes vu qu'ils ne connaissent pas de synonymes. En utilisant le Tlfi on s'en sortirait beaucoup mieux sans doute. Wordnet aussi. Bientôt le wiktionnaire structuré, et WIkidata dans une certaine mesure avec le concept "d'alias", on peut donner autant de dénomination qu'on veut pour un concept
• Du côté des gafam justement, des gens de chez facebook (de mémoire) ont découvert la technique suivante qui est ultra prometteuse à mon avis : https://blog.acolyer.org/2016/04/21/the-amazing-power-of-word-vectors/ Il y a clairement le potentiel pour découvrir des relations sémantiques dans un corpus textuel.

tu penses que la majorité des gens sont des idiots manipulables à souhait

Que la majorité des gens sont des idiots, certes non, et de toute façon quand bien même ce fusse le cas on peut être démocrate malgré tout. Objectivement des gens avec un handicap mental ont le droit de vote et c'est très bien comme ça.

Manipulable : oui, comme tout le monde. On est tous plus ou moins influençable à part les grosses tête de mules bornées qui sont pas forcément pas moins idiotes que les autres. Et d'être influençable à être manipulable, il n'y a qu'un pas. Je pense qu'on ne gagne pas en se sortant du lot en se pensant invincible face à ce genre de manœuvres.

Et non, ce n'est pas parce qu'on est de mon avis qu'on est anti-démocrate. Simplement, quand on part de ce genre de principe, la démocratie devient un combat de tous les instants, une discussion sans fin contre les idéologies dangereuses et un exercice de conviction pour faire passer ses idées et ne pas laisser des idéologies dangereuses l'emporter.

Non, c'est juste une hypothèse en fait.

Du coup j'ai regardé le code de view-source:http://marionlepen.fr/action-parlementaire/le-role-du-depute/

Rien de spécialement avancé on dirait. Il y a des balises "header" qui ont l'air de masquer tout ce qui n'est pas spécialement du contenu sur la page, une pour encadrer le titre de l'article, sinon c'est que des "div". Il y a des méta données dans l'en tête par contre :

<meta property="og:type" content="article" />
<meta property="og:title" content="Le rôle du député - Marion Maréchal-Le Pen" />

Le préfix "og" correspond à the open graph protocol que je ne connaissait pas.

Du coup google peut savoir sait que c'est un article, connaît son titre. En virant tout ce qui est "header" il doit relativement facilement deviner ou est le début du vrai contenu, soit par là dans cet extrait de code :

    <header class="page-header pt-style-2">
      <h1 class="page-title"><span>Le rôle du député</span></h1> 

            <div class="entry-meta">
                            </div>                                  
        </header><!-- .page-header -->
    </div>

    <div class="grid-100 mobile-grid-100 tablet-grid-100">
    <div class="entry-content clearfix">    
        <p style="text-align: justify;"><div class="su-row">
<div class="su-column su-column-size-1-2"><div class="su-column-inner su-clearfix">
<p style="text-align: justify;"><strong>Les députés sont élus pour 5 ans au suffrage universel direct, au scrutin uninominal majoritaire à deux tours.</strong></p>
<p style="text-align: justify;">Ils sont les représentants de la Nation et participent à l’expression de la volonté générale. Ils sont également, de fait, représentants dans l’hémicycle de leur circonscription, chargé de se faire l’écho des préoccupations propres à leurs territoires.</p>

par contre rien dans ce code qui annote spécifiquement le deuxième paragraphe, donc il y a forcément une bonne dose d'heuristique pour le choisir. Sûrement quelque chose basé sur du traitement de la langue et/ou des stats.

Rien de bien concluant.

Et bah non. Sur wikipédia comme ailleurs il y a un culte de la simplicité - à tous les niveaux - qui est supposée faciliter la contribution. Le wikitexte est relativement pauvre en élément sémantique, et quand il y en a la communauté préfère parfois utiliser le formatage manuel pour contrôler le rendu. C'est un fatra de classe CSS généré par des modèles et le moteur de wikitexte, grosso modo. Ça va peut être changer un peu avec l'éditeur graphique peut être, Wikidata et des choses comme la gestion intégrée des citations, mais on part de loin, et c'est jamais simple à faire accepter par la communauté qui a tendance à crier lors des changements.

Du coup il n'y a pas vraiment de balisage très utile pour sémantiser les contenus dans Wikipédia. Du coup faut faire une analyse en connaissant le fonctionnement de Wikipédia pour extraire des infos de manière un peu plus intelligente, genre ce que fait dbpedia avec les résumé introductif : http://fr.dbpedia.org/page/Paris (ils ont une propriété "abstract") ou les descriptions avec Wikidata qui sont des projets de structuration des données, mais dbpedia fait de l'extraction avec pas mal de travail sur les extracteurs et Wikidata est renseignée par les utilisateurs (parfois depuis wikipédia) ou les bases de données externes. Mais ce n'est certainement pas grâce aux balises ''sémantiques'' standards de Wikipédia parce qu'il n'y en a pour ainsi dire pas.

Ptete que c'est une histoire d'annotation/balisage HTML dans le document pour déterminer que c'est effectivement une définition. Si il n'y en a pas sur service public mais que la sémantique est marquée chez mlp google arrive à la trouver.

C'est à dire qu'à partir du moment où tu as accepté qu'on ne peux pas tester l'égalité de deux nœuds blancs - utilisés en tant que "valeur inconnue" - ben forcément c'est compliqué de déterminer l'égalité de deux noeuds blancs et t'es obligé de rajouter des hypothèses supplémentaires.

Mais c'est comme pour le linéaire versus le exponentiel : on n'a pas forcément à perdre en facilité de modélisation sous prétexte que certains problèmes sont difficiles à résoudre.

Autrement dit, les nœuds blancs sont utiles précisément pour les mêmes raisons qu'ils posent des problèmes difficiles. On est dans un monde ouvert, on va pas le refermer juste pour se restreindre à des problème facile. Mais à l'utilisation de Wikidata, ça marche très bien.

Euh, la skolémisation, c'est totalement indépendant des données, ça concerne uniquement la requête. Je vois pas le rapport avec l'étape de sérialisation et désérialisation.

Le seul problème que je vois ici c'est que la fonction "isBlank" risque de retourner une valeur différente sur la version sérialisée. Donc les requêtes risquent de toute façon ne pas retourner quelque chose d'équivalent sur les deux jeux de données. De la à parler d'un problème de skolémisation de la requête … la skolémisation c'est une opération de mise en forme normale sur les formules du premier ordre qui est toujours possible. C'est assez anecdotique, non ?

OWL(?) et RDF sont uniquement utilisés, comme je l'indiquais dans mes remarques sur le typage, pour l'ontologie Wikidata.

L'ontologie Wikidata est assez bas niveau et ne sert grosso modo qu'à définir les types de base de Wikidata, la notion de "déclaration" https://www.wikidata.org/wiki/Help:Statements/fr et deux/trois autres trucs, et c'est tout. On est loin d'avoir une sémantique "au dessus" des déclaration dans cette ontologie, ce que pourrai permettre OWL.

Mais c'est en pratique assez peu compatible avec l'utilisation de Wikidata : Wikidata est essentiellement une collection de déclaration. Une déclaration est accompagné d'une source. Sa signification est supposé signifier :

• D'après la source, ceci est vrai.

On peut ainsi modéliser des trucs comme
* D'après l'état civil, Johnny est né le … à Paris
Mais aussi des trucs contradictoires comme
* D'après Johnny, Johnny est né le … à Bruxelle

Ajouter une sémantique logique au dessus de ça est assez compliquée parce que ces deux déclarations sont contradictoires et que la logique doit donc être résistance aux contradictions. En pratique aussi, Wikidata ne permet pas de distinguer deux déclarations contradictoires de deux déclarations complémentaires.

Euh non c'est pas compliqué du tout de skolémiser … il suffit de prendre des variables qui n'apparaissent nulle par ailleurs et de les ignorer par ailleurs. Le fait de dire que ça ne saurait générer de nouvelles ressources ça veut simplement dire que la portée des variables qu'on pourrait définir à l'intérieur du "exists" est limité à cette intérieur. Mais ça n'empêche pas de skolémiser les problèmes de scope, il suffit que les variables définies en tête de formules skolémisées ne soient utilisés qu'au bon endroit dans la formule et jamais ailleurs.

Ou alors file des exemples.

Sur le "optional", ça n'est pas un problème, c'est juste con de les utiliser dans un exists à priori vu que ça risque d'être remplacé par un "pattern ou vrai" ce qui se simplifie en "vrai" donc c'est supprimable à priori lors de la phase de skolémisation ou une phase de simplification de la requête.

J'ai rien compris. On ne qualifie certainement pas sur un graphe pattern ou sur un ensemble, ça signifierait qu'on tente de démontrer l'existence d'un graphe pattern. Or le graphe pattern on le connaît déjà vu qu'on le file à la clause "exists".
On quantifie sur l'existence de triplets dans le graphe qui sont "solution" du graph-pattern, ce qui n'implique certainement pas une logique d'ordre supérieur. D'ailleurs le graphe pattern n'est pas du tout un ensemble, c'est une formule logique. Il se trouve qu'il existe un ensemble de tuples qui correspondent à ce graphe pattern. Mais on ne quantifie absolument pas sur cet ensemble, on l'ignore allègrement, on cherche juste à savoir si il a (au moins un) élément.

C'est quand même complètement modélisable avec un quantificateur existentiel, il sera juste dans une sous-formule. En utilisant une notation en extension dans la théorie des ensemble ça donnerait quelque chose comme {l'ensemble des résulat|il existe un sous graphe tel que …}

Ah j'ai donc écris des bêtises dans la dépêches ! Merci de la correction. Je n'avais jamais eu à utiliser le From et j'ai naïvement cru qu'il n'y en avait pas, ça m'apprendra a ne pas vérifier.

Pour le quantificateur existentiel, il existe aussi l'opérateur clé exists cf. la doc qui en relève aussi.

http://csl.name/mandelbrot/#zoom=2.7756811401600924e-10,1.2862416996495893e-10&lookAt=-0.1048396969286931,-0.9270125830273652&iterations=7051&superSamples=1&escapeRadius=10.0&colorScheme=pickColorGrayscale

http://csl.name/mandelbrot/#zoom=3.736400104511079e-13,1.7314357731738756e-13&lookAt=-0.19857058455624454,1.1000828013085886&iterations=7051&superSamples=1&escapeRadius=10.0&colorScheme=pickColorGrayscale

Et là, c'est riche : http://csl.name/mandelbrot/#zoom=1.918408520032536e-13,8.890106888503201e-14&lookAt=0.2504324539517045,0.00001608137713336215&iterations=7051&superSamples=1&escapeRadius=10&colorScheme=pickColorGrayscale

Genre cactus, fougère, bonhomme de neige.