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 …
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.
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.
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 :
<metaproperty="og:type"content="article"/><metaproperty="og:title"content="Le rôle du député - Marion Maréchal-Le Pen"/>
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 :
<headerclass="page-header pt-style-2"><h1class="page-title"><span>Le rôle du député</span></h1><divclass="entry-meta"></div></header><!-- .page-header --></div><divclass="grid-100 mobile-grid-100 tablet-grid-100"><divclass="entry-content clearfix"><pstyle="text-align: justify;"><divclass="su-row"><divclass="su-column su-column-size-1-2"><divclass="su-column-inner su-clearfix"><pstyle="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><pstyle="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.
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.
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 ?
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.
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.
[^] # Re: Lecteur m3u d'Url ? en fait c'est ça ?
Posté par Thomas Douillard . En réponse à la dépêche Sortie de Goodvibes 0.1, lecteur de radios Internet. Évalué à 2.
faut coder une fonction bash-completion. C'est pas très dur.
[^] # Re: Rien d‘anormal
Posté par Thomas Douillard . En réponse au journal Du choix discutable des sources de Google pour ses définitions automatiques. Évalué à 3.
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 …
[^] # Re: Module et type abstrait
Posté par Thomas Douillard . En réponse au journal Une petite histoire d'utilisation type fort dans Ocaml. Évalué à 0.
Curryfication ?
[^] # Re: Rien d‘anormal
Posté par Thomas Douillard . En réponse au journal Du choix discutable des sources de Google pour ses définitions automatiques. Évalué à 3.
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.
[^] # Re: Et l'assurance
Posté par Thomas Douillard . En réponse au journal Des conséquences d'un plâtre. Évalué à 9.
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 ?
[^] # Re: Rien d‘anormal
Posté par Thomas Douillard . En réponse au journal Du choix discutable des sources de Google pour ses définitions automatiques. Évalué à 3.
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 :
[^] # Re: Question idiote...
Posté par Thomas Douillard . En réponse au journal Du choix discutable des sources de Google pour ses définitions automatiques. Évalué à 6.
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.
[^] # Re: Algo
Posté par Thomas Douillard . En réponse au journal Du choix discutable des sources de Google pour ses définitions automatiques. Évalué à 4. Dernière modification le 15 janvier 2017 à 12:11.
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 :
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 :
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.
[^] # Re: Algo
Posté par Thomas Douillard . En réponse au journal Du choix discutable des sources de Google pour ses définitions automatiques. Évalué à 6.
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.
[^] # Re: Algo
Posté par Thomas Douillard . En réponse au journal Du choix discutable des sources de Google pour ses définitions automatiques. Évalué à 5.
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.
[^] # Re: Euh ???
Posté par Thomas Douillard . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 2.
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.
[^] # Re: Euh ???
Posté par Thomas Douillard . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 3.
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 ?
[^] # Re: De l'art de râler
Posté par Thomas Douillard . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 4.
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 :
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.
[^] # Re: Euh ???
Posté par Thomas Douillard . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 3.
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.
[^] # Re: Euh ???
Posté par Thomas Douillard . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 3.
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.
[^] # Re: Euh ???
Posté par Thomas Douillard . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 2.
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 …}
[^] # Re: Euh ???
Posté par Thomas Douillard . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 3.
Ah j'ai donc écris des bêtises dans la dépêches ! Merci de la correction. Je n'avais jamais eu à utiliser le
Fromet 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é
existscf. la doc qui en relève aussi.# Une vitre brisée avec un impact de balle
Posté par Thomas Douillard . En réponse au journal The Mandelgame. Évalué à 2.
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
[^] # Scie circulaire
Posté par Thomas Douillard . En réponse au journal The Mandelgame. Évalué à 2.
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
[^] # Re: Feuille ? cœur ?
Posté par Thomas Douillard . En réponse au journal The Mandelgame. Évalué à 2.
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.
# Feuille ? cœur ?
Posté par Thomas Douillard . En réponse au journal The Mandelgame. Évalué à 2.
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
[^] # Re: Euh ???
Posté par Thomas Douillard . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 3.
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.
[^] # Re: Euh ???
Posté par Thomas Douillard . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 4.
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 ?
[^] # Re: Euh ???
Posté par Thomas Douillard . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 4.
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é :)
[^] # Re: Euh ???
Posté par Thomas Douillard . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 4.
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.