thoasm a écrit 9447 commentaires

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.

J'ai un truc là, non ? http://csl.name/mandelbrot/#zoom=4.9476223442773656e-8,2.292712258039312e-8&lookAt=0.2504324627016174,0.000016083833276264126&iterations=7051&superSamples=1&escapeRadius=10&colorScheme=pickColorGrayscale

L'expressivité de SPARQL fait qu'effectivement résoudre une requête SPARQL est probablement NP-complet, oui.

Mais si on se limite à des calculs linéaires on limite fortement l'expressivité du langage et des tas de requêtes deviennent non exprimables. On va pas se limiter à du linéaire juste pour que ce soit limité, tout dépend de l'application.

C'est moi qui comprend rien à ce que tu racontes du coup. Et ça cadre mal avec ton discours genre "je comprend rien" : c'est quoi un ws ? C'est quoi "scaler linéairement", sur des jointures de données ?

En vrai je pense que j'ai rien compris à tout ça…

Je crois aussi, c'est compliqué de te répondre du coup :)

Pour utiliser ldf, t'as pas grand chose à faire. De ce que j'ai compris c'est juste une option des serveurs qui l'implémentent qui leur permette de fournir des "fragments" de données. Au lieux de fournir une requête SPARQL entière tu file ta requête SPARQL au client LDF qui se démerde tout seul pour négocier les fragments avec le serveur. C'est une sorte de protocole au dessus de http, quoi.

Sinon sur ces technologies en général : c'est pas spécialement supposé remplacer tes webservices non, c'est un choix technologique qui en vaut sûrement un autre. Le truc c'est que des tas de sites web ont fait le choix de fournir des points d'accès à leur données qu'on peut interroger en SPARQL : https://www.w3.org/wiki/SparqlEndpoints . Du coup on peut aborder ça avec une perspective opendata. Ces données sont accessibles à tous pour l'utilisation que tu veux. Et tu peux croiser un peu comme tu veux les données de tous ces fournisseurs. Wikidata peux aider pour ça parce que la correspondance entre les entités Wikidata comme https://www.wikidata.org/entity/Q5 et les identifiants des même concepts sont stockés pour de nombreuses autres bases de données externes sur Wikidata et/ou sur mix'n'match.

Le but peut être simplement la curiosité, par exemple très récemment quelqu'un sur BuzzFeed a utilisé une requête Wikidata concernant les décès de célébrités : https://lists.wikimedia.org/pipermail/wikidata/2016-December/010138.html La page du point d'accès de Wikidata peut générer des résultats sous divers format : tableau classique, carto pour les trucs géolocalisable, graphe avec des sommets et des arêtes pour les trucs généalogiques … il y a des exemples. On doit sûrement pouvoir intégrer ça directement sur une page web. Dans le futur on pourra sûrement intégrer directement ça dans une page Wikipédia.

Un autre cas ultra concret de consommation des données par Wikidata au travers de SPARQL c'est le maintien de listes automatique : https://fr.wikipedia.org/w/index.php?title=Discussion_Projet:Wikidata#Wikidata_weekly_summary_.23242 un robot génère des articles de liste dans la Wikipédia en gallois à partir de requête Wikidata. Dans le cas de Wikidata ça sert aussi à faire des requêtes de maintenance pour trouver les problèmes dans les données rentrées par les utilisateurs.

Après ce n'est pas la seule manière d'accéder aux données Wikidata, qui peut fournir les données des entités dans plusieurs formats en json pour l'entité "être humain" par exemple.

Voilà, je sais pas si ça correspond à ce que tu attends comme réponse mais j'aurai essayé :)

On oblige personne à rien faire, il s'agit d'une alternative à explorer quand la requête est trop lourde pour le serveur. On gagne aussi la possibilité de fédérer des données sur des serveurs qui ne sont pas interconnectés et qui ne fournissent que des points d'accès vers leurs données propres. Il y a des exemples sur leur site.

Pour le truc de serveur à serveur, pourquoi pas, on peut évidemment sûrement faire un serveur au dessus des serveurs de base, par exemple un serveur qui sait fédérer les données de plusieurs point d'accès SPARQL si on veut. Tout est possible. Mais c'est pas de l'interconnexion de serveur : ils se causent pas, ils filent juste des données vers le même point.

Parce que je me suis gouré !

par exemple, avec le mot clé a tu parle d'uri mais elles interviennent où ?

Bonne question. Les uris, c'est les identifiants de la base de données. Toute ressource, propriété, élément, possède son uri. Par exemple, l'uri de l'entité correspondant au concept d'être humain dans Wikidata est : http://www.wikidata.org/entity/Q5 . On peux l'utiliser telle quelle dans une requête SPARQL, mais il existe un mécanisme de préfixes pour éviter d'avoir à se taper l'url en entier à chaque fois.

Pour simplifier l'écriture, parce que c'est long pour un identifiant toute une uri, il y a un mécanisme qui permet de définir des préfixes :

PREFIX wd: <http://www.wikidata.org/entity/> 

dans une vraie requête sur query.wikidata.org on pourra taper de manière équivalente à l'url http://www.wikidata.org/entity/Q5 le code wd:Q5. La page de requête définit par défaut les préfixes habituels.

J'ai du mal avec ces techno, j'ai l'impression qu'elles veulent trop bien faire et répondent trop tard et avec trop de complexité au besoin.

Je peux pas forcément te contredire, peut être que d'autres technos feraient aussi bien l'affaire, je ne sais pas. Mais ce que je sais c'est que Wikidata n'a pas l'air d'avoir moins de succès que freebase, au contraire, qu'on ne manque pas vraiment d'exemples de requêtes pour Wikidata voir la page de requête donc que communautairement la communauté ne semble pas spécialement avoir eu de difficulté à s'approprier SPARQL. Je sais aussi que le service précédent de requête, proposé par un unique individu, un poil plus simple et moins puissant a fini par fermer sans que personne ne semble s'en émouvoir plus que ça. Je sais aussi que l'équipe de développement a pas mal attendu avant de se lancer dans le moteur de requête officiel, ils ont semblé s'orienter vers le choix du moteur spécifique avant de finalement faire le choix de SPARQL. Je pense que le fait que ça existait déjà, que c'était standard (dés le déploiement suffisait d'inclure une lib python pour faire une requête par exemple) a largement joué dans leur choix plutôt que de se lancer dans un chantier finalement assez inutile. Bref, si je peux pas formellement te contredire, j'aurai tendance à penser que tu as une mauvaise impression.

Je n'ai pas l'impression que ça dit une vraie solution à tout cela. La forme des requêtes, leurs éventuelles limitation est souvent là pour avoir des temps de réponse acceptable. Et le crissement des données se fait très bien côté client avec la possibilité de choisir ce qui se passe lorsque l'un des serveurs est inaccessible, de faire du cache, etc

Ben justement, ldf tire dans cette direction. La forme des requête peut être arbitrairement complexe sur ta machine tout en respectant le serveur. Après le système de cache habituel du web doit très bien marcher sur les fragments et tout ça. Et que ldf n'est pas du tout incompatible avec tous ces mécanismes qui sont plus parallèle qu'en opposition. Par exemple les fragments étant plus réguliers qu'une requête arbitraire, tu as largement plus de chance que ton fragment soit en cache quelque part que ta requête à toi. Il suffit que quelqu'un ait besoin du même fragment que toi bien qu'il ne fasse pas la même requête pour profiter du cache, alors que le serveur Wikidata sans fragment ne sait que faire du cache des résultat pour les requêtes identiques.

Ben justement, le choix à ses pièges : http://ecopsycho.gretha.cnrs.fr/spip.php?article273 qui commente la très agréable à regarder vidéo de http://www.ted.com/talks/lang/fr-ca/barry_schwartz_on_the_paradox_of_choice.html

Aujourd'hui, tu as le choix pour tout et n'importe quoi. Ça a un coût cognitif et psychique important et répondre "bien fait" à tous ceux qui en ont peut être raz la casquette d'être soumis en permanence à des dilemmes sur des sujets divers et variés, du choix de son assurance à son choix de slip en passant par le téléphone ou de la prochaine conquête meetic, ben tu leur reproche d'avoir une réaction naturelle et fort explicable.

Si tu comprend pas ça, tu va ptete te prendre des baffes.

Tu sais, si il y avait que les profs qui avaient des problèmes avec les différentes interfaces et les logiciels équivalents mais pas tout à fait pareils parce qu'il y en a un qui utilise des rubans et l'autre une barre latérale … On trouve même des informaticiens qui chouinent quand ils doivent utiliser un logiciel un poil différent de celui qu'ils utilisent d'habitude. Donc ça sert à rien de s'énerver, faut réfléchir aux approches qui auraient des chances de changer les choses, et ça n'a rien de simple.

Concernant "télécharger.com", j'en connais qui préféreraient un téléchargement sur ce site plutôt que sur un site web random qui tente de vendre du libreoffice rebrandé en "Microfost Office", par exemple.

Sinon pour les polices tu peux toujours les convertir en chemin pour supprimer les soucis de polices inconsistantes.

Je pense que ta théorie est contredite par la réalité :) "Ne devrait" marcherait ptete :)

Ah mais j'ai pas opposé les deux, j'ai parlé spécifiquement des purs littéraires réfractaires aux maths :) C'est une conjonction logique qui concerne ceux qui sont à la fois purement littéraires (littéraires finis) et réfractaires, pas une implication du style "tous les littéraires sont réfractaires aux maths".

Euh non, le zoom de 60 milliards est un zoom de 60 milliard, pas un truc qui boucle, d'ailleurs le point d'arrivée est très différent du point de départ. Il y a un certain degré d'autosimilarité entre les structures, mais les variations sont infinies et les structures ne sont jamais identiques (ou le existe-il un nombre infini de structure identiques mais la probabilité que deux structures prises au hasard soient identiques est nulle ?).

Mais le truc ce serait de superposer une vraie photo de kiwi. Genre les images pourraient être proposées comme défi par la communauté. Tu proposes un kiwi et le premier qui trouve une zone appropriée gagne.

Ya moyen, faudrait décider si le mapping image/fractale est bon. On peut imaginer plusieurs classes de mapping :

• le mapping exact, genre t'as trouvé exactement la spirale du coquillage
• le mapping "ya de l'idée" genre c'est pas mal mais il manque un truc
• le mapping "note artistique", genre ça colle pas du tout mais le résutat est marrant / joli / intéressant
• le mapping "éviscération instantanée", genre tu juges qu'il y a rien du tout et que c'est une erreur ou une arnaque. Je te laisse le choix de l'animation.

Faudrait genre une phase ou un utilisateur propose un truc, dans un mode "bac à sable" et se soumet à la sagacité de la communauté.

On sait pas, personne n'est encore allé au Bord du Monde. Des légendes prétendent que quand on y va on gagne un pouvoir de téléportation. D'autre prétendent qu'on tombe et qu'on respawn.

Ben dans Minecraft, il y a des poules, des cochons, des pieuvres et des zombies. Je crois que rien que ça disqualifie totalement la comparaison avec le jeu de la vie en terme d'austérité ;)

Une chose à la fois :) Les automates cellulaires, c'est cool, mais "le jeu de la vie" à beau s'appeler jeu, ça n'a pas le même effet sur les non geeks. Trop austère ?

Mais oui, un des trucs que toutes ces figures ont en commun c'est la notion d'itération qui est au coeur : on prend une règle (formule pour les fractales, règle d'évolution des cellules pour les automates) et on l'applique sur un état pour générer un autre état, on la réapplique un certain nombre de fois itérativement.

À l'extrême, ça marche aussi pour le vivant : on prend les lois de la physique comme règle, on prend l'ADN qui représente un état, et on génère un autre ADN. Informatiquement, l'ADN peut se voir comme un une chaîne de nombre. On pourrait par exemple le coder dans un nombre rationnel entre 0 et 1 avec un nombre fini de décimale, qui peut être arbitrairement grand - à la limite, un nombre réel quoi. En simplifiant outrancièrement et en ignorant l'environnement, on pourrait faire le rapprochement entre la complexification de l'ADN par le rallongement des chromosomes et le zoom de l'exploration de l'ensemble de mandelbroot, quand on zomme, on rajoute des détails et de la complexité, et des décimales aux nombres qui servent à décrire la zone sur laquelle on veut dessiner la figure.

Il y a pleins de mots pour parler grosso-modo de la même chose : classe, sorte, type, catégorie …

On a le choix :)

des rubans qui sautent de partout dès que la souris sort du cadre du dessin

Et c'est vraiment gênant ? En quoi ?

De plus, l'apparition de cette interface c'est accompagné d'une gourmandise phénoménale en ressources systèmes.

Ça soit ça n'a rien à voir, soit c'est parce qu'il y a une mauvaise implémentation, mais c'est pas trop la faute du concept.

C'est pratique d'avoir un synonyme dans un langage orienté objet, mais grosso-modo "taxonomie" c'est un synonyme de "classification".

Ce qui fait que "taxon", essentiellement, c'est la même chose que "classe". Bon, certes ici on fait de la classification d'expression, et nos classes ne sont pas des types de C++ :)

Certes, taxonomie est plus souvent employé de manière spécifique pour la classification du vivant, mais c'est aussi employable de manière plus générique.

Moui, si t'essayes d'enseigner ça dans un cours d'apprentissage de la programmation, tu vas perdre genre 90% des étudiants en quelques secondes.