SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web

Posté par Thomas Douillard le 01 janvier 2017 à 15:49. Édité par Davy Defaud, bubar🦥, palm123, Benoît Sibaud et ZeroHeure. Modéré par Nils Ratusznik. Licence CC By‑SA.

Étiquettes :

jan.

2017

« Chère pêche »,

En ce début d'année, il ne me semble pas inutile de faire le pont entre la rétrospective et la perspective, afin de conjuguer l’avenir du Web au présent. :-)

Le but de cette dépêche est de faire un tour d’horizon de technologies permettant de faire des requêtes sur des données structurées : le Web sémantique. Comment il a évolué en dix ou quinze ans et ce qu’il permet de faire. Après une introduction contextuelle et historique, il sera question de Sparql et de linked data fragments, ainsi que de leurs usages en pratique chez Wikimedia Foundation.

Accrochez‐vous à votre fauteuil, il va être question de niveaux d’abstractions, d’enrichissement croisé de données, de manipulation de tables, de la pertinence du choix de RDF par rapport à SQL, des outils utilisés par les contributeurs Wikimedia mis au point par les développeurs du projet et, enfin, des limites actuelles et d’un avenir possible.

Sommaire

Contexte
SPARQL
Linked Data Fragment : des requêtes à l’échelle du Web

Contexte

Note : pour aller à l’essentiel, ceux qui connaissent déjà l’historique du Web et du Web sémantique peuvent passer les paragraphes suivants et sauter directement à la prochaine note en italique.

Le « requêtage » du Web fut et est toujours basé essentiellement sur l’indexation automatique de documents, trouvée grâce à des robots d’indexation, et un tri pertinent des résultats des recherches (par mots clefs) pour maximiser les chances que l’utilisateur trouve ce qu’il cherche dans les premiers résultats. Vous n’ignorez probablement pas que ce dernier point est la clef du succès du moteur de recherche Google, grâce au PageRank. Problème résolu.

Problème résolu ? Peut‐être pas totalement. Si les techniques présentées dans ce court paragraphe préliminaire se sont révélées capables de générer une des entreprises multinationales les plus puissantes du monde en à peine plus d’une décennie, l’initiateur même du Web a proposé très tôt une vision alternative basée sur des données, non pas textuelles, cette fois, mais des choses plus proches des structures de données qu’on utilise habituellement en programmation ou quand on conçoit et utilise des bases de données. Ça a créé toute une palette de technologies et d’articles de recherche regroupés sous le nom de Web sémantique et Linked data.

Malgré un certain nombre de critiques — c’est dur, ça ne marchera jamais, XML sapu —, ce domaine et la recherche autour ont dans un premier temps donné naissance à des technologies normalisées par le W3C, comme tout ce qui tourne autour de XML (XPath) et utilisées par des acteurs de l’industrie. La verbosité et la complexité de XML ont été progressivement complétées par des technologies plus légères pour l’échange de données. Mais l’idée sous‐jacente n’est pas très différente : les données sont représentées sous la forme d’un arbre. Tout comme une page Web traditionnelle en somme. Le Web s’est beaucoup développé autour des documents arborescents. Un aperçu et une explication de l’architecture de quelques‐unes de ces technologies sont lisibles dans l’article Wikipédia Semantic Web Stack.

Pourquoi ce domaine de recherche n’est pas mort ? Eh bien, j’ai envie de dire que ça devrait être évident pour n’importe quel informaticien et l’on en trouve des traces dans des projets comme cette présentation d’une personne de Microsoft autour de l’extraction de données structurées présentes dans les pages Web, comme les tableaux de données, mais encore le projet weboob, qui vise à récupérer des données facilement exploitables dans des programmes informatiques. Tim ne s’était pas trompé.

Après cette longue introduction, j’en viens au cœur du sujet : la présentation de quelques‐unes des technologies au travers d’une de leurs applications concrètes, d’un problème rencontré dans le cadre de ces utilisations et des pistes de résolution de ces problèmes.

SPARQL

Note : c’est là !

SPARQL est en particulier utilisé par Wikidata et c’est ce projet qui nous servira à illustrer son utilisation concrète et les problématiques.

La première technologie que je voudrais présenter, c’est SPARQL. SPARQL (« étincelle » en jeu de mots) est un langage qui ressemble beaucoup à SQL, dont il reprend d’ailleurs des mots clefs et des constructions, étendu pour pouvoir gérer des relations qui ne sont pas définies à la manière des schémas de données SQL classiques.

Les bases

En particulier, SPARQL ne possède pas de construction FROM pour définir les relations que l’on va requêter. Par défaut, on peut requêter n’importe quelle relation présente dans la base de données. Une « relation » n’a pas à être déclarée explicitement et peut être n’importe quelle URI ! SPARQL est donc par défaut vachement plus ouvert que SQL, vu que l’on n’est pas limité à utiliser les ressources définies dans notre instance de base de données. On peut utiliser n’importe quelle adresse Internet (prévue pour, c’est mieux).

Deuxième différence avec les bases de données SQL : les relations ont forcément deux uniques colonnes. En réalité, elles ne sont d’ailleurs pas représentées sous forme de triplets <sujet> <prédicat> <objet> dans les exportations de bases SPARQL. Les bases SPARQL correspondent au modèle de base de données orientée graphe. En conséquence, en SPARQL on n’écrira pas :

SELECT nom FROM personne

Mais plutôt :

SELECT ?nom WHERE {
   ?personne a personne .
   ?personne nom ?nom
}

Cette requête est construite à partir de deux « motifs de triplets » (triple pattern, TP). Je reviendrai sur le premier plus loin. Un TP comporte trois composantes qui correspondent respectivement au prédicat, au sujet et à l’objet. Ils servent à filtrer l’ensemble des triplets de la base de données pour ne retenir que ceux qui correspondent au motif. Chacune des composantes d’un BGP peut être soit une constante, soit une variable. Les noms de variables sont précédés d’un point d’interrogation.

Un motif de triplet correspond à un ensemble de triplets de la base de données. Par exemple, si l’on a les triplets suivants :

<personne1> <nom> "Bob" 
<personne1> <sexe> <Masculin> 
<personne2> <nom> "John"

Le motif ?personne nom ?nom va correspondre aux triplets 1 et 3. Pour chacun de ces triplets, les variables ?personne et ?nom auront pour valeurs respectives le sujet et l’objet qui conviennent.

Un point intéressant et qui diffère encore une fois avec SQL est qu’on peut mettre une variable sur les trois composantes du triplet, donc de la relation. C’est comme si on pouvait mettre une variable sur un nom de table en SQL. Il est ainsi possible de créer un motif ?s ?p ?o qui correspondra avec n’importe quel triplet de la table. On peut, par exemple, compter l’utilisation de chaque prédicat ainsi :

SELECT (count(?s) as ?nombre) {
 ?s ?p ?o .
} group by ?p

Un exemple dans le vrai store de Wikidata, ça donne ça).

Il est possible d’exclure certains de ces triplets grâce à la clause FILTER :

 ?personne nom ?nom filter (?nom != "John") .

Le critère de sélection supplémentaire est une expression booléenne pouvant utiliser les fonctions XPath.

Ces triplets peuvent se combiner en utilisant des points entre, pour former un « motif basique de graphe » (Basic Graph Pattern, BGP). Il devient alors possible de faire des jointures entre les résultats de ces triplets, simplement en réutilisant le même nom pour les variables :

 ?personne nom ?nom .
 ?personne sexe ?sexe .

Cela peut s’abréger en utilisant des points‐virgules pour éviter d’avoir à préciser l’objet, s’il se répète plusieurs fois. La requête suivante permet grâce à cela de reconstituer un équivalent d’une table SQL personne à partir de nos triplets :

SELECT ?personne ?nom ?sexe {
   ?personne  a personne ;
              nom ?nom   ;
              sexe ?sexe .
}

L’équivalent des jointures à gauche et à droite se fait grâce au mot clef optional, qui permet de définir des triplets dont les variables n’ont pas nécessairement de valeurs.

SPARQL et typage

Comme promis, on va revenir sur ce fameux a dans ?personne a personne. Ce n’est pas une propriété comme les autres. Techniquement, ce n’est pas une propriété d’ailleurs, mais un « chemin de propriété » (plus là‐dessus, plus loin…).

Il est ici pour une raison bien précise : SPARQL n’a pas vraiment de notion de type, en dehors des types de bases (qui sont d’ailleurs assez riches) du Web sémantique et de la couche sous‐jacente RDF : les types de données de base de RDF. Il délègue ainsi le typage des données qu’il manipule à RDF et RDFS.

Alors que dans une base SQL classique une sorte de typage est codé dans la notion de table et de ses champs, rien de tel n’existe dans une base SPARQL. Le type des URI est donné par des propriétés comme les autres : rdf:type et rdfs:subType, qui permettent de créer des hiérarchies de classes, comme dans un langage à objets.

Pour dire qu’une URI particulière est une personne, on doit avoir un triplet tel que personne1 rdf:type personne . dans notre dépôt. Ça marche aussi avec une sous‐classe de personne. Le mot clef a est un raccourci pour dire exactement ça. Teaser, avec un chemin de propriété, a s’écrit rdf:type/rdf:subClassOf*.

On peux ainsi réutiliser la propriété nom pour un chien, sans nécessairement avoir à créer un nouveau champ dans la table chien, comme on le ferait peut‐être en SQL si l’on avait une table chien et une table personne.

Il y aurait beaucoup à dire sur le typage dans le Web sémantique, mais c’est hors cadre de cet article. Ça concerne la notion d’ontologie formelle et les couches plus hautes de la pile du Web sémantique, comme OWL et les moteurs d’inférences. Ces couches rajoutent la possibilité de faire des schémas de données plus avancées et la possibilité de déduire des triplets qui ne sont pas explicites dans le dépôt, grâce à des règles logiques. Mais on n’en est pas du tout là sur Wikidata, en particulier, d’où le paragraphe qui suit.

SPARQL, le typage et Wikidata

Wikidata, ou plutôt ses développeurs, utilisent clairement SPARQL, RDF et son typage. Ils l’utilisent cependant uniquement pour définir le format d’exportation RDF des données de Wikidata et/ou le modèle de données Wikibase — qui a ses propres types de base encore enrichies, par rapport aux types de RDF, avec des notions comme la précision des données pour les quantités, les unités, etc. —, le format des déclarations Wikidata et compagnie.

Mais les contributeurs n’ont pas accès aux propriétés rdf:type ou « sous‐classe de ». Les données que les contributeurs enrichissent sont considérées comme ayant leur propre niveau d’abstraction. Wikidata n’est pas constitué de triplets, mais de « déclarations », qui sont plus complexes, possèdent des métadonnées, telles que les sources, par exemple.

La communauté est laissée totalement libre de la manière dont elle utilise ce modèle, et elle a créé des équivalents distincts de ces propriétés RDF : nature de l’élément, pour prendre le nom français, et sous‐classe de. Ainsi, la communauté n’est pas enchaînée à RDF ou à OWL, et peut utiliser les technologies qu’elle veut pour tout ce qui touche aux déductions par rapport aux données existantes, par exemple.

Les chemins de propriétés

Les chemins de propriétés, PropertyPath en anglais (PP), s’appuient sur la notion de chemin dans un graphe pour généraliser l’idée de triplet ?s ?p ?o, quand le sujet et l’objet sont reliés indirectement. Par exemple, une personne et ses ascendants sont souvent reliés par un chemin si ce ne sont pas son père ou sa mère.

Les PropertyPath ressemblent beaucoup à des expressions rationnelles. On y retrouve des opérateurs, comme l’étoile pour l’itération : personne1 père* ?ascendant va par exemple sélectionner tous les pères, grands‐pères, arrière‐grands‐pères de personne1. Les autres opérateurs intéressants sont l’oblique / — slash —, une sorte d’équivalent de la notation pointée des structures du C et la barre verticale |, qui exprime l’alternative entre plusieurs motifs (comme le ou logique).

Par exemple, là où l’on écrirait grandpère = personne.père.père en C ou en Java, on peut écrire ?personne père/père ?grandpère en SPARQL. Si l’on veut tous les ascendants de la personne, on pourra écrire ?personne (père|mère)* ?ascendant.

Les nœuds blancs

Une autre fonctionnalité intéressante, conceptuellement et syntaxiquement, est héritée de RDF. Il s’agit des « nœuds blancs » : une utilité de ces nœuds blancs est d’exprimer une « valeur quelconque ». Par exemple, si l’on veut sélectionner toutes les personnes qui ont des enfants, on pourra écrire le motif de triplet suivant : ?parent enfant [] ..

Conceptuellement, la chose va cependant plus loin et il est aussi possible d’utiliser des nœuds blancs comme valeurs de triplets dans la base de données. Quelque chose comme « né de père inconnu » pourra s’exprimer explicitement dans le dépôt en utilisant un nœud blanc comme valeur du père de la personne.

C’est ainsi qu’est implémentée la valeur spéciale « valeur inconnue » du modèle de données de Wikidata en RDF. Voici la requête pour trouver les éléments des gens que Wikidata sait être nés de pères inconnus :

select ?personne {
  ?personne wdt:P22 ?father filter(isBlank(?father)) .
}

L’autre intérêt des nœuds blancs est de fournir des raccourcis sympathiques d’écriture et d’éviter de créer des variables. Il suffit pour ça d’ajouter des choses entre les crochets. Plus précisément, des couples ?p ?o séparés par des « ; », le sujet étant notre nœud pour lequel on ne veut pas créer des variables. Pour trouver les habitants d’une capitale d’un pays démocratique, on pourrait s’en sortir avec :

?personne habite [a capitale ; capitale_de [a démocratie] ]

Hop, la requête sur query.wikidata.org.
La fonction isBlank() permet de savoir, comme son nom l’indique, si une valeur est effectivement un nœud blanc dans le dépôt.

Et le reste…

On peut bien entendu combiner joyeusement toutes ces fonctionnalités grâce à d’autres opérateurs comme union, pour faire :

une union de deux sous‐requêtes ;
utiliser des requêtes complètes dans des requêtes ;
faire de l’agrégation, exactement comme dans SQL ;
calculer des différences ensemblistes, pour prendre les résultats qui correspondent à une requête sauf ceux qui sont résultats d’une autre requête ;
etc.

Bref, c’est un langage qui permet de faire plein de trucs chouettes :-), dont le fait de faire des requêtes très complexes demandant beaucoup au serveur de bases de données. Celui de Wikidata coupe le calcul d’une requête au bout de trente secondes et il arrive relativement souvent que des requêtes de tous les jours n’aboutissent pas.

Pour cette raison, entre autres, d’autres technologies ont émergé pour permettre au client de faire une partie du calcul, ce qui nous amène à la dernière partie de cette dépêche.

Linked Data Fragment : des requêtes à l’échelle du Web

On l’a vu, ne serait‐ce que pour Wikidata, qui possède un jeu de données conséquent mais dont le volume de données n’a pas de quoi faire peur à un informaticien moyen ou à un expert en [mégadonnées], les performances peuvent déjà être un problème. Les requêtes complexes ou certaines requêtes particulières ne se terminent pas. Qu’elles qu’en soit la raison. Jeunesse ou bogue du moteur ? Réelle complexité de la requête ? Peu importe.

Alors, qu’en est‐il du vieux rêve de faire des requêtes de bases de données à l’échelle du Web en temps réel, en croisant les données de différents endroits ? Impossible ? Il semblerait que non.

En faisant le constat que sur le Web, ce qui est rare ou limitant est probablement le temps de calcul des serveurs, l’idée est d’être gentil avec eux et de déporter le calcul sur les clients et ne demander aux serveurs que des choses qu’ils peuvent calculer rapidement, en laissant les clients faire les calculs complexes. Nos ordinateurs passent beaucoup de temps à ne rien faire…

Le prix à payer est sans doute à chercher du côté de la bande passante, mais la solution est séduisante : aider à la disponibilité des serveurs tout en pouvant facilement croiser les données, sans être limité par l’expiration du délai d’attente du serveur… Eh bien figurez‐vous qu’on peut déjà le faire, dans le langage que je vous ai présenté plus haut qui plus est : http://client.linkeddatafragments.org/.

J’avoue que je suis assez impressionné. Tout ça est encore jeune et il reste sans doute pas mal de réglages à faire, cf. http://linkeddatafragments.org/. Mais, ça « juste marche » ! Et Wikidata a mis ça en place très récemment, même si des questions se posent encore.

# Performance

Posté par Clorr le 01 janvier 2017 à 17:14. Évalué à 5.

Bravo et merci pour cet article très intéressant.

A propos de la performance, savez-vous si il existe un moyen d'évaluer la complexité de la requête et le volume de données à traiter avant de la lancer ?
- [^] # Re: Performance
  
  Posté par Jean Roc Morreale le 01 janvier 2017 à 21:29. Évalué à 5.
  
  Indépendamment du fonctionnement de chaque base de données, le SPARQL dispose de clauses comme FILTER ou LIMIT pour réduire le champ de la requête mais, dès que tu t'aventures hors de tes serveurs et dans l'univers du linked data et des endpoints tu peux oublier le tuning de planificateur de requêtes ou la vague garantie de temps de réponse vu que le résultat va dépendre du parcours d'un graphe sur lesquel tu n'as aucun contrôle.
# XML sapu et autres billevesées

Posté par Enzo Bricolo 🛠⚙🛠 le 01 janvier 2017 à 19:46. Évalué à 10.
L'article est très intéressant mais je n'en peux plus de lire des bêtises comme "XML sapu" :
1. Les structures arborescentes pour l'échanges de données, ça existait bien avant le web (X12, EDIFACT, etc.) - je ne parlerai pas des crétins qui nous gonflent à demander des échanges en CSV.
2. XML, les libs et les outils qui tournent autour, les métaformats basés dessus comme l'ebXML, le xCBL, les webservices de type SOAP ont leur raison d'être et couvrent un certains nombres de besoins fondamentaux dans le business moderne.
3. Si de nouveaux besoins apparaissent et qu'ils amènent la mise au point de nouvelles techniques comme JSON ou de nouvelles méthodes d'échanges comme des webservices RESTful, c'est très bien mais il faut arrêter de faire des commentaires de "hipster chiant" sur le fait que "le XML, c'est lourd".
Choisissez les bons outils et si vous avez de nouveaux besoins, créez les (sous licence libre).
- [^] # Re: XML sapu et autres billevesées
  
  Posté par Jean Roc Morreale le 01 janvier 2017 à 21:35. Évalué à 5.
  
  Pour les réfractaires au RDF/XML, il existe d'autres types de notations telles que Turtle, JSON
- [^] # Re: XML sapu et autres billevesées
  
  Posté par barmic le 02 janvier 2017 à 07:22. Évalué à 10.
  
  Il y a eu une époque où il y a eu des abus avec XML, des usages un peu trop partout ou des formats pas très bien défini (trop verbeux, limitant,…). Ce fut notamment le cas dans l'écosystème Java.
  
  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
  - [^] # Re: XML sapu et autres billevesées
    
    Posté par Alex G. le 03 janvier 2017 à 17:08. Évalué à 7.
    
    Oui c'est exactement ce genre d'abus qui a rendu impopulaire XML.
    Perso je trouve XSLT immonde par exemple (utiliser XML pour faire un langage de programmation), mais je sais qu'il a ses défenseurs. Il y a également l'utilisation de XML pour des fichiers de configurations édités par des humains, qui pourraient par ailleurs être super simples.
    Les spécifications de type SOAP ont également joué leur part (comment tout ré-inventer de manière lourde et imbuvable).
    
    En soit XML c'est bien qu'en on en a des problématique qui s'y prêtent (j'apprécie en particulier les espaces de noms), mais si c'est pour une édition par des humains, je préfère YAML.
    
    En particulier pour RDF je préfère des notations plus simples.
    - [^] # Re: XML sapu et autres billevesées
      
      Posté par Jehan (site web personnel, Mastodon) le 13 janvier 2017 à 16:03. Évalué à 2.
      
      si c'est pour une édition par des humains, je préfère YAML.
      
      J'ai eu une fois à implémenter un parseur YAML. C'était vraiment l'horreur. Ils ont fait des choix vraiment bizarres et ont défini plein de façons de noter la même donnée. On ne s'en rend pas compte côté utilisateur car on va en général utiliser la même notation partout. Mais quand on fait un parseur, il faut être exhaustif (pour ce 1% de gens qui vont envoyer des fichiers avec cette syntaxe). Très mauvaise expérience.
      
      Si pour une édition par des humains, je préfère quelque chose de bien plus simple encore, type fichiers clé-valeur simple. Il y a des formats de ce type standardisés, typiquement celui de FreeDesktop qui fut défini pour les fichiers .desktop (donc utilisés par la plupart des — sinon tous les — bureaux libres). Ce type de format reste simple à parser (et en général, y a même pas besoin de faire soi-même, si on utilise une bibliothèque de bureau, par exemple glib). Ce format peut contenir des chaînes de caractères, nombres, booleans et des listes, des sections (même la localisation est prise en charge si besoin est, et elle peut être automatisée avec extraction du texte original par gettext puis génération de fichiers qui contiennent toutes les localisations; c'est ce qui est fait en général pour localiser les fichiers desktop!) et il n'emploie pas 10 variantes par type ni de logique super-compliquées.
      
      Sinon y a aussi des formats encore plus simples, plus proches du INI de Microsoft (le format standardisé par Freedesktop est d'ailleurs très proche, bien qu'avec quelques différences) qui est aussi beaucoup utilisé, même sur nos systèmes libres.
      
      Ces formats sont souvent suffisants et je ne vois pas l'utilité d'apporter la complexité du YAML pour un fichier destiné à être édité par des humains. Ensuite je dis pas, YAML a des fonctionnalités plus avancées et peut-être dans des cas d'usage très particuliers, il convient de monter d'un cran et d'utiliser ce format. Mais je n'ai jamais eu le cas. En général, lorsque le besoin devient vraiment complexe, ce n'est plus un format que je destine à l'édition par des humains, mais par un programme (et à ce moment, ce n'est pas non plus le YAML que je vais choisir).
      
      Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
- [^] # Re: XML sapu et autres billevesées
  
  Posté par Dabowl_75 le 02 janvier 2017 à 12:28. Évalué à 5.
  
  Le plus amusant avec JSON, c'est qu'on finit par se poser les mêmes questions et avoir les mêmes besoins qu'avec XML… schema, namespace.
  
  Bref, on change les balises par autre chose mais les besoins fondamentaux restent identiques.
  
  L'informatique est un éternel recommencement.
  
  "Celui qui ne connait pas l'histoire est condamné à la revivre"
  - [^] # Re: XML sapu et autres billevesées
    
    Posté par whity le 02 janvier 2017 à 14:40. Évalué à 6.
    
    Json a quelques avantages intrinsèques par rapport à xml :
    - meilleur rapport signal / bruit (moins d’octets perdus)
    - pas de différentiation entre attribut et valeur du nœud
    - encodage fixé par la norme
    - types de base existants dans le langage (liste, flottants, chaînes), faisant partie de la norme, là où XML n’a que des chaînes
    
    XML a un avantage intrinsèque par rapport à JSON : différentiation entre le nom d’un nœud et ses attributs.
    
    Ensuite, les namespace manquent à JSON (je n’ai rien vu de standardisé), et côté schémas, XML garde l’avantage. Idem côté signatures, où la encore il n’y a rien de standardisé en JSON. Je ne considère pas que ne pas avoir d’équivalent à XSLT pour JSON soit un manque, par contre :).
    
    Néanmoins, les défauts de JSON peuvent être corrigés dans la mesure où ce sont des manques, là où ceux de XML ne le peuvent pas, car ils sont intrinsèques au format. XML a encore son utilité aujourd’hui, mais JSON a tous les atouts pour le remplacer dans tous les domaines : c’est un meilleur compromis lisibilité humaine / machine que ne l’est XML.
    
    Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
    - [^] # Re: XML sapu et autres billevesées
      
      Posté par Enzo Bricolo 🛠⚙🛠 le 02 janvier 2017 à 16:31. Évalué à 7.
      
      "XML a encore son utilité aujourd’hui, mais JSON a tous les atouts pour le remplacer dans tous les domaines : c’est un meilleur compromis lisibilité humaine / machine que ne l’est XML."
      
      Donc tu n'as pas bien lu mon post qui était concentré sur les cas d'usages "business" ou "machine to machine" dans lesquels on se cogne pas mal de la lisibilité par un humain.
      
      Ceci posé, je dirai "challenge accepted" et j'attendrai impatiemment de voir du déploiement de JSON sur des échanges "business" dans mes différents périmètres d'intervention …
      - [^] # Re: XML sapu et autres billevesées
        
        Posté par whity le 03 janvier 2017 à 09:11. Évalué à 4.
        
        Donc tu n'as pas bien lu mon post qui était concentré sur les cas d'usages "business" ou "machine to machine" dans lesquels on se cogne pas mal de la lisibilité par un humain.
        
        Je répondais plutôt à Dabowl_75, effectivement. Mais puisque tu rebondis sur le machine to machine, XML n’est pas spécialement un bon choix de ce point de vue : on se cogne de la lisibilité par un humain, et par contre on se tape un bruit énorme. Au final, tu paies de la cpu et de la bande passante pour rien. Il existe bien des « binary XML » pour corriger ces défauts, mais malheureusement rien de standard (contrairement à BSON qui est un standard unique).
        
        Après, XML est un standard établi, et très répandu. Comme tout standard, il lui faudra du temps pour être remplacé, et il subsistera très certainement très longtemps (il est tellement présent dans l’écosystème java que je le vois mal y disparaître). En revanche, côté web, c’est clairement le json qui s’impose (plus grand monde ne fait de l’ajax, et de la même manière, SOAP n’est considéré comme à utiliser que quand il n’y a pas le choix, à cause de l’intégration à de l’existant).
        
        Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
        
        [^] # Re: XML sapu et autres billevesées
        
        Posté par Enzo Bricolo 🛠⚙🛠 le 03 janvier 2017 à 12:23. Évalué à 2.
        
        "on se tape un bruit énorme" ça se discute "tu paies de la cpu" c'est mon choix, mes cpus ne foutent rien "et de la bande passante" ben non, c'est compressé …
        "côté web, c’est clairement le json qui s’impose" de quel coté du web ? pour quels usages ? je ne vois toujours rien venir de mon coté du web (par contre, j'ai des besoins MQTT qui m'arrivent du coté industriel).
```

[^] # Re: XML sapu et autres billevesées

Posté par trancheX le 04 janvier 2017 à 12:37. Évalué à 3.

C'est quoi le rapport entre MQTT et XML ?
MQTT n'est il pas data agnostique ?

[^] # Re: XML sapu et autres billevesées

Posté par barmic le 04 janvier 2017 à 14:26. Évalué à 4.

Surtout que MQTT, c'est pas du web, non ?

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

[^] # Re: XML sapu et autres billevesées

Posté par Enzo Bricolo 🛠⚙🛠 le 04 janvier 2017 à 19:05. Évalué à 2.

MQTT est un protocole, tu peux l'implémenter coté web si tu veux.

[^] # Re: XML sapu et autres billevesées

Posté par Enzo Bricolo 🛠⚙🛠 le 04 janvier 2017 à 19:08. Évalué à 1.

Soit, ce n'était pas le sujet. J'attends toujours, comme la sœur Anne, de voir poindre le "grand remplacement" de mes payloads en XML par des payloads en JSON, tel que me le promet whity, et pour l'instant, je ne vois rien venir sur ce front.

[^] # Re: XML sapu et autres billevesées

Posté par whity le 06 janvier 2017 à 17:19. Évalué à 2.

En fait, tu travailles à la RATP, c’est ça ?

Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0

[^] # Re: XML sapu et autres billevesées

Posté par Enzo Bricolo 🛠⚙🛠 le 06 janvier 2017 à 17:50. Évalué à 2.

Pas dans ce type de transport, mais j'ai aussi une petite base installée …

Le métier s'est pointé cette semaine avec des demandes d'intégration d'application en SaaS
qui exposent à la fois des APIs de type SOAP et REST.
J'ai cru que j'allais enfin pouvoir passer du coté hype de la force mais ce que j'ai vu était
juste affreux. Ces gens là méritent de se faire trouer, je plains leurs clients.
Je suis à deux doigts de poster l'url de l'API ici pour leur foutre la honte.
- [^] # Re: XML sapu et autres billevesées
  
  Posté par claudex le 04 janvier 2017 à 09:05. Évalué à 6.
  
  Il manque les commentaires à JSON.
  
  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
- [^] # Re: XML sapu et autres billevesées
  
  Posté par groumly le 05 janvier 2017 à 06:52. Évalué à 9.
  
  Rajoute deux trucs tres chiant en json, qui limitent son intérêt à l'utiliser pour des config:
  - pas de commentaires possible. Ca c'est un GROS problème pour la lisibilité humaine.
  - l'ordre des champs n'est pas spécifié. Si t'as un outil qui modifie l'objet et serialize à nouveau, ca peut te faire un diff monstre pour pas grand chose, et json est un tres mauvais choix pour ca.
  
  Et les schémas, c'est quand même super pratique pour s'assurer qu'on écrit pas de la merde (ou juste pour éviter les typos). Et avec un ide décent, ca facilite vachement l'écriture d'un document.
  
  L'absence d'attribut sur les champs peut vite devenir problématique aussi. L'exemple de base, c'est la serialization d'objet, ou la class est perdue, et ne peut pas être inclue sans faire de trucs bien crades.
  
  Les défauts ne sont pas tous simples à corriger, bon courage pour intégrer les commentaires ou la validation xsd sans tout peter. Pour rappel, le js de json, c'est pour Javascript, la spec est base sur les objects literals de JavaScript, ca va être compliqué de faire évoluer le standard sans faire évoluer Javascript en même temps.
  
  Bref, c'est comme tout, ca dépend.
  Le meilleur compromis dépend surtout de ce que tu cherches à faire. Json est léger, tres simple à comprendre, et tres simple à vérifier (spec courte). XML est beaucoup plus complet et offre un grand nombre de garde fous.
  Si t'écrit un microservice pour un service grand public ou la philosophie est "c'est pas cassé tant que PagerDuty gueule pas trop", json est probablement un bon choix.
  Si t'écrit un service un peu plus critique que ca, ou la validation des données échangées est tres importante, xml est probablement un bon choix.
  
  Linuxfr, le portail francais du logiciel libre et du neo nazisme.
  - [^] # Re: XML sapu et autres billevesées
    
    Posté par barmic le 05 janvier 2017 à 08:38. Évalué à 4.
    
    l'ordre des champs n'est pas spécifié. Si t'as un outil qui modifie l'objet et serialize à nouveau, ca peut te faire un diff monstre pour pas grand chose, et json est un tres mauvais choix pour ca.
    
    Tu as le même genre de résultats avec XML
    
    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
    
    [^] # Re: XML sapu et autres billevesées
    
    Posté par groumly le 05 janvier 2017 à 10:12. Évalué à 3.
    
    Je trouve pas de source, mais il me semble que l'ordre des éléments se doit d'être conservé. Si l'appli s'en fout, c'est son problème, mais le format force les parseurs/serializeurs à conserver l'ordre.
    A l'inverse du json, ou 2 arbres avec un ordre différent représentent le même objet (vu que c'est une hashmap dans la plupart des implementation, l'ordre n'a pas vraiment de sense de toute façon).
    
    Linuxfr, le portail francais du logiciel libre et du neo nazisme.
    
    [^] # Re: XML sapu et autres billevesées
    
    Posté par barmic le 05 janvier 2017 à 10:42. Évalué à 5.
    
    Tu peux déserialiser puis reserialiser ton document, en changeant l'ordre, en changeant les prefixe de namespace, etc
    
    Beaucoup de projet sont très fort pour générer des fichiers XMl dont la moindre modification dans par leur outil produit un gros changement dans le document (beaucoup d'outil d'Oracle font ça, jenkins 1 -je sais pas pour jenkins 2-, etc).
    
    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
    
    [^] # Re: XML sapu et autres billevesées
    
    Posté par groumly le 05 janvier 2017 à 19:04. Évalué à 5.
    
    tu peux le faire, oui, mais si tu veux pas le faire, c'est possible.
    Avec json, ca depend de la fonction de hash utilisée par ta lib et de l'age du capitaine, et t'as aucun moyen de garantir que changer la valeur d'un champ ne pas te réordonner tout ton document. Perso toutes les api dom que j'ai utilisée maintiennent l'ordre quand tu parse un document et le reserialize. C'est un arbre, donc c'est assez facile de maintenir l'ordre. Apres is ton process reconstruit le document from scratch, l'ordre peut changer oui, mais c'est en dehors du scope de la spec. La spec dit que si elementA vient avant elementB dans le document, cet ordre doit être conservé quand le document est parsé.
    
    Linuxfr, le portail francais du logiciel libre et du neo nazisme.
    
    [^] # Re: XML sapu et autres billevesées
    
    Posté par barmic le 06 janvier 2017 à 09:12. Évalué à 4.
    
    Perso toutes les api dom que j'ai utilisée maintiennent l'ordre quand tu parse un document et le reserialize.
    
    C'est bien, mais l'api DOM c'est pas la seule et je suis pas certain que ce soit la plus utilisée. XPath, SAX et PAX font pareil évidement, ils ne s'intéressent qu'à la déserialisation donc c'est pas vraiment comparable et la sérialisation comme le fait JAXB (alors c'est le nom de l'api java : c'est du mapping d'objet) se fout de la sérialisation.
    
    Je ne suis pas un spécialiste de la norme mais pour moi il est mauvais de considérer comme différent :
    
    <xml> <as> <a>foo</a> <a>bar</a> </as> </xml>
    
    et
    
    <xml> <as> <a>bar</a> <a>foo</a> </as> </xml>
    
    À partir de là, on s'en fout que l'une des tes api va garder ou non, l'ordre. Tu peut avoir 2 documents dont le diff est importants, mais qui représentent la même chose.
    
    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
    
    [^] # Re: XML sapu et autres billevesées
    
    Posté par whity le 06 janvier 2017 à 10:47. Évalué à 4.
    
    Tu compares deux choses complètement différentes.
    
    En XML comme en JSON, l’ordre des attributs n’est pas censé être important. En xml, on n’est pas censé faire de différence entre :
    
    <toto attr1="titi" attr2="tutu"/>
    
    et
    
    <toto attr2="titi" attr1="tutu"/>
    
    En ce qui concerne le cas :
    
    <toto><attr1>tutu</attr1><attr2>titi</attr2></toto>
    
    qui conserve l’ordre, en json on l’écrira plutôt :
    
    {"toto":[{"attr1":"tutu"},{"attr2":"titi"}]}
    
    Qui là aussi conserve l’ordre.
    
    Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
    
    [^] # Re: XML sapu et autres billevesées
    
    Posté par flan (site web personnel) le 06 janvier 2017 à 07:55. Évalué à 7.
    
    Dans XML l'ordre est important, tu ne peux pas inverser deux balises. Heureusement, sinon un texte en XHTMLrisquerait de perdre un peu de son sens…
  - [^] # Re: XML sapu et autres billevesées
    
    Posté par whity le 06 janvier 2017 à 11:05. Évalué à 2.
    
    pas de commentaires possible. Ca c'est un GROS problème pour la lisibilité humaine.
    
    Ça peut manquer. Certains (je crois même que c’est le cas de la plupart) parseurs autorisent les commentaires javascript /* */, mais là pour le coup on est hors de la norme. Dans le cas d’échanges de données, c’est pas trop gênant, dans le cas de fichiers de conf, ça l’est plus, effectivement. Cela dit, j’ai souvent vu ajouter un attribut "comment" sur certains objets, là où on veut insérer des commentaires.
    
    l'ordre des champs n'est pas spécifié.
    
    l’ordre des attributs ne l’est pas non plus en xml. Cf mon autre réponse plus loin à ce sujet quand tu as besoin d’un ordre.
    
    L'exemple de base, c'est la serialization d'objet, ou la class est perdue, et ne peut pas être inclue sans faire de trucs bien crades.
    
    Je suis curieux de savoir ce que tu appelles « bien crade ». À comparer avec sérialiser automatiquement une classe « s$ » qui est un nom de classe tout à fait valide (au moins en c++ et java) mais un nom de nœud xml tout à fait invalide… Et de la nécessité des [CDATA] suivant le contenu, ce qui peut te péter pas mal d’outils qui n’en tiendront pas compte parce que ça te rajoute un nœud supplémentaire dans ton arbre dom…
    
    bon courage pour intégrer […] la validation xsd sans tout peter.
    
    Ça existe déjà. Par contre, ce n’est pas standardisé comme peut l’être xsd. Et c’est effectivement un problème pour l’instant.
    
    Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
    
    [^] # Re: XML sapu et autres billevesées
    
    Posté par groumly le 06 janvier 2017 à 19:54. Évalué à 5.
    
    Ça peut manquer
    
    Non, pas peu, ca manque, point à la ligne. En tout cas, si tu veux l'utiliser en remplacement de xml.
    Ton champs comment est un gros hack degueu:
    - tu ne peux avoir qu'un champs comment par objet. Si tu veux mettre un commentaire par champs, ben tu l'as dans l'os
    - si ton objet mappe a déjà un champ comment, tu l'as dans l'os. Oui, on va pas se voiler la face, 95% des objets json sont un mapping direct d'objet/structure en mémoire. C'est tout l'intérêt du format, il puise sa spec dans ce pattern, et des que tu dévies de ca, tu perds une grosse partie de l'intérêt de json. Alors, oui, certains langage permettent un mapping compliqué, mais pas tous.
    
    l’ordre des attributs ne l’est pas non plus en xml. Cf mon autre réponse plus loin à ce sujet quand tu as besoin d’un ordre.
    
    Les attributs, non, mais on s'en fout, ca a jamais dérangé persone. L'ordre des éléments par contre est crucial, cf l'exemple du xhtml donne plus haut. Ou le cas de la config modifiée par un process puis reserializee (genre un pom par exemple. Ca fait pas plaisir de voir le bordel dans son pom après une release (c'est ce qui m'a fait partir sur du xml la dernière fois que j'ai écrit un outil du genre).
    Ta technique de remplacer l'objet par un array est affreuse, tu changes complètement la semantique de l'objet, et perd la contrainte d'unicité des champs — ah ben tiens, un truc qui n'est pas spécifié par json, et qui est parfaitement specifie par xml (donc pas du tout ambiguë).
    Le contrat implicite de json, c'est que ca mappe directement un objet en mémoire, et que donc chaque champ est unique dans son parent.
    Le problème c'est que c'est implicite, donc pas spécifié. Techniquement, c'est valide. En pratique, tu fais ca, tu vas recevoir un email vener du mec qui consomme ton document, parce que son mappeur lance une exception.
    
    Perso tu m'envoie un objet avec ta technique "un array d'objet a un seul champ", tu vas recevoir un email,pas piqué des hannetons de ma part. Ca fout en l'air tout mon mapping, et quitte à me prendre la tête sur le mapping, je préfère encore me taper du xml.
    
    Je suis curieux de savoir ce que tu appelles « bien crade »
    
    Devoir stocker des metadata dans l'objet lui même. Ton champs s$, il a rien à faire sur l'objet lui même, il n'en fait pas partit, il sert juste à décrire l'objet pour une autre partie du système. Typiquement, tu vas utiliser un attribut pour ca:
    
    <object type="com.foo.Bar"> <field name="s$" type="Integer">42</field> <field name="anArray" type="ArrayList">etc je te laisse fermer les balise, c'est pete couille sur un ipad, le backticks sont déjà suffisamment chier à taper.
    
    Et de la nécessité des [CDATA] suivant le contenu, ce qui peut te péter pas mal d’outils qui n’en tiendront pas compte parce que ça te rajoute un nœud supplémentaire dans ton arbre dom…
    
    Heu, ouais, enfin xml est largement spécifie, les autres outils doivent soit implémenter la spec (pas facile, certes), soit utiliser une lib qui le fait. Autant je veux bien comprendre que certains cas à la marge passent à la trappe (bug, tout ca), autant zapper les cdata, c'est un peu gros quand même.
    
    Ça existe déjà. Par contre, ce n’est pas standardisé comme peut l’être xsd. Et c’est effectivement un problème pour l’instant.
    
    J'ai pas l'impression que tu comprends l'intérêt d xml dans ce genre de choses. Plusieurs choses:
    - la feuilles xsd est incluse DANS le document. T'envoies un doc xml a un process, et il peut valider la structure de l'arbre tout seul, et le rejeter s'il est pas bon. Ou le rejeter parce qu'il n'as pas la bonne xsd.
    - Cet echange de document n'arrive pas nécessairement par http — batch job, config offline, que sais je encore.
    
    Y'a un clair besoin d'embarquer des metadata dans le document lui même. Sans ca, y'a un paquet de choses que tu ne peux pas faire - tout ce qui tourne autour de la validation, ou tous les cas où t'as besoin de décrire un élément, mais ou cette description ne fait pas partie de l'objet lui même.
    JSON ne supporte pas du tout ce cas. Et n'essaie pas, ni meme ne pretend. Si t'as besoin de meta donnees, va voir ailleurs. Et y'a pas de problème avec ca, tour le monde n'as pas besoin de ca. Mais pour ceux qui en ont besoin, c'est un besoin critique. Tout le monde ne fait pas des services grands public avec 15 deployments par jour, ou indisponibilité/bug veut dire "10 personnes ne peuvent pas poster une photo de chats".
    ya des gens qui ecritvent des services qui ne peuvent pas se permettre de pondre un format incorrect, et pour qui la seule option dans ce cas est de refuser le traitement et lancer une alerte. C'est vachement plus chiant comme approche de development, mais ils ont pas le choix, c'est la seule solution au problème qu'ils doivent résoudre.
    
    Entends moi bien, json est tres bien, et je l'utilise allègrement tous les jours. Mais quand je lit des trucs genre "JSON a tous les atouts pour le remplacer dans tous les domaines " je bondit un peu au plafond. Json est populaire parce qu'il est super simple et tres tolérant aux erreurs, on les passe sous silence, et on continue comme on peut. Cette approche marche tres bien pour beaucoup de monde. Mais c'est clairement inacceptable pour beaucoup d'autres personnes.
    
    'Fin c'est comme si tu disais "les camionnettes, c'est vachement bien ca va remplacer tous les véhicules de livraison, les 36 tonnes c'est vachement plus chiant à conduire". Ca répond juste pas aux même problématiques.
    Le,problème, c'est qu'au début des années 2000, on a vendu des 36 tonnes a tout le monde, et la camionnette n'a été inventée qu'après, alor,s oui, c'est sur que livrer un pauvre bouquin a un gars dans un patelin paume en 36 tonnes, c'est relou. Ca veut pas dire que les 36 tonnes vont disparaître.
    
    Linuxfr, le portail francais du logiciel libre et du neo nazisme.
    
    [^] # Re: XML sapu et autres billevesées
    
    Posté par whity le 07 janvier 2017 à 09:52. Évalué à 1.
    
    Ton champs comment est un gros hack degueu
    
    Oui, c’est pas terrible. Mais à part pour des fichiers de conf, les commentaires, ça ne sert pas à grand chose. Si tu m’envoies en communication M2M des xmls avec des commentaires, c’est moi qui vais hurler :).
    
    Perso tu m'envoie un objet avec ta technique "un array d'objet a un seul champ", tu vas recevoir un email,pas piqué des hannetons de ma part. Ca fout en l'air tout mon mapping, et quitte à me prendre la tête sur le mapping, je préfère encore me taper du xml.
    
    J’en déduis que le concept de list<pair<int,int> > est interdit chez toi ?
    
    Tu veux une liste ordonnée, c’est une array. Tu veux un tableau associatif, c’est un un objet. Dans ton xml, dès que tu as plusieurs types d’enfant, tu te retrouves souvent à :
    
    <root> <apples> <apple type="golden" count="12"> <apple type="pinklady" count="23"> </apples> <oranges>
    
    (je te laisse compléter). Elle est où la différence ?
    
    Heu, ouais, enfin xml est largement spécifie, les autres outils doivent soit implémenter la spec (pas facile, certes), soit utiliser une lib qui le fait. Autant je veux bien comprendre que certains cas à la marge passent à la trappe (bug, tout ca), autant zapper les cdata, c'est un peu gros quand même.
    
    <?xml version="1.0"?> <toto><![CDATA[écrire ]]]]><![CDATA[> c’est compliqué]]></toto>
    
    C’est gros, mais pourtant, plusieurs évaluateurs xpath ne me donnent pas le même résultat pour toto/text()…
    
    la feuilles xsd est incluse DANS le document. T'envoies un doc xml a un process, et il peut valider la structure de l'arbre tout seul, et le rejeter s'il est pas bon. Ou le rejeter parce qu'il n'as pas la bonne xsd.
    
    Je suppose que tu veux dire que la (les) feuille à xsd à utiliser est déclarée dans le document. Oui, c’est pratique car ça permet à un tiers de valider en partie les données. Par contre, c’est insuffisant car tout n’est pas exprimable avec. Se reposer uniquement là-dessus, c’est casse gueule. Mais oui, c’est pratique. Par contre, signer le document (par exemple) casse cette validation… Tout embarquer dans le même document ça n’a pas que des avantages.
    
    Cet echange de document n'arrive pas nécessairement par http — batch job, config offline, que sais je encore.
    
    Là c’est toi qui te limite complètement arbitrairement. Le transport est complètement agnostique aussi du point de vue json (même s’il est né sur le web et dans les navigateurs).
    
    Après, oui, XML a aujourd’hui un écosystème beaucoup plus riche (et j’avais déjà souligné certains points dès le départ). JSON manque énormément de standardisation à ce niveau. Mais ces points peuvent être ajoutés, en partant d’un format qui est plus simple et plus efficace que XML.
    
    Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
    
    [^] # Re: XML sapu et autres billevesées
    
    Posté par Enzo Bricolo 🛠⚙🛠 le 07 janvier 2017 à 10:55. Évalué à 2.
    
    "signer le document (par exemple) casse cette validation"
    
    Il faut signer avec le bon stylo et au bon endroit.
    
    [^] # Re: XML sapu et autres billevesées
    
    Posté par whity le 07 janvier 2017 à 12:07. Évalué à 2.
    
    Plutôt que d’indiquer la spec (que je connais vaguement pour l’avoir mise en œuvre), je veux bien que tu pointes le paragraphe précis.
    
    Parce que là, j’en suis à :
    
    « element Signature: Schemas validity error : Element '{http://www.w3.org/2000/09/xmldsig#}Signature': This element is not expected. Expected is one of { … } ».
    
    Signer un document modifie sa structure, et donc casse la validation xsd. Ça parait logique, mais il y a peut être effectivement une astuce que j’ignore (à la réflexion : je peux peut-être déclarer la signature comme optionnelle dans mon xsd, mais dans ce cas il faut que je me retape toute la structure ?). Sinon je peux virer la signature avant validation xsd, ça reste une solution pourrie.
    
    Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
    
    [^] # Re: XML sapu et autres billevesées
    
    Posté par Enzo Bricolo 🛠⚙🛠 le 07 janvier 2017 à 12:31. Évalué à 2.
    
    Je ne comprends pas bien ce que tu veux faire mais peut être qu'un document en bon français pourra t'aider. Quel type de signature veux tu générer ?
    
    [^] # Re: XML sapu et autres billevesées
    
    Posté par whity le 08 janvier 2017 à 08:33. Évalué à 1.
    
    Pour faire simple :
    - je génère une signature enveloppée, pas de soucis, ça marche, je sais vérifier ma signature.
    
    En revanche, ce que je ne sais pas faire, c’est faire une validation xsd sur mon xml signé. Sur mon xml non signé, pas de soucis. Mais comme je suis sur une signature enveloppée, ça fait foirer ma validation xsd (fatalement, le nœud Signature rajouté ne figure pas dans mon xsd).
    
    Ce n’est pas super grave, je vis bien avec, mais néanmoins si tu connais une solution (options à passer au validateur xsd ? modification du xsd ?) je suis preneur.
    
    Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
    
    [^] # Re: XML sapu et autres billevesées
    
    Posté par Enzo Bricolo 🛠⚙🛠 le 15 janvier 2017 à 02:05. Évalué à 2.
    
    Chapitre 4.2.2
    
    [^] # Re: XML sapu et autres billevesées
    
    Posté par whity le 17 janvier 2017 à 00:36. Évalué à 1.
    
    Je dois mal m’exprimer, parce qu’il n’y a rien dans le lien que tu donnes qui réponde à ma problématique.
    
    À moins que ta solution, ce soit de passer par une signature détachée, c’est ça ? Mais ça ne me convient pas : ça me fait deux fichiers (avec les problématiques de rapprochement qui vont avec) au lieu d’un -> c’est largement pire que mon problème de validation xsd.
    
    Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
    
    [^] # Re: XML sapu et autres billevesées
    
    Posté par groumly le 07 janvier 2017 à 19:49. Évalué à 2.
    
    Oui, c’est pas terrible. Mais à part pour des fichiers de conf, les commentaires, ça ne sert pas à grand chose
    
    Ben ouais, mais quand tu parles de remplacer xml dans tous les domaines, c'est un peu un gros,problème, tu penses pas?
    
    J’en déduis que le concept de list > est interdit chez toi ?
    
    Pas si ca correspond bien à la semantique du document.
    Si la semantique du document, c'est un objet avec des champs, fourrer tous les champs dans un array n'est pas une bonne idee. Surtout si tu fais ca à cause d'une limitation de ton format de persistence.
    
    Tu veux une liste ordonnée, c’est une array. Tu veux un tableau associatif, c’est un un objet. Dans ton xml, dès que tu as plusieurs types d’enfant, tu te retrouves souvent à :
    
    Yen a pas de différence, tu modélise une liste d'objet, donc un array est la bonne structure. Mon problème est sur la technique que tu décrivais, de modifier fondamentalement la structure et semantique du document pour contourner une limite du format. Tu passes aussi allègrement sous silence le fait que répéter le même champs est non spécifié en json.
    Ca contrevient clairement à la philosophie du format, mais est techniquement valide, donc on fait quoi?
    
    Tout embarquer dans le même document ça n’a pas que des avantages.
    
    J'ai jamais fait de signatures en xml, donc je vais te croire sur parole. Toujours est il que la discussion était "json peut facilement remplacer xml dans tous les domaines", et visiblement, c'est pas le cas. Ce cas tres courant est pas supporté, et ne vas pas pouvoir être supporté sans peter la compat avec l'existant.
    
    Là c’est toi qui te limite complètement arbitrairement. Le transport est complètement agnostique aussi du point de vue json (même s’il est né sur le web et dans les navigateurs).
    
    Ta spec ne dit absolument rien sur comment déclarer la feuille de validation offline, le seul exemple qu'elle donne est pour du transport http, en utilisant le content type header. Pour valider un document offline, y'a absolument rien dans ta spec.
    
    Linuxfr, le portail francais du logiciel libre et du neo nazisme.
    
    [^] # Re: XML sapu et autres billevesées
    
    Posté par barmic le 07 janvier 2017 à 10:50. Évalué à 2.
    
    Tout le monde ne fait pas des services grands public avec 15 deployments par jour, ou indisponibilité/bug veut dire "10 personnes ne peuvent pas poster une photo de chats".
    
    Il y a moyen de débattre technique sans attaque ridicule de ce genre ? Ça donne juste envie de plonker l'auteur
    
    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
    
    [^] # Re: XML sapu et autres billevesées
    
    Posté par groumly le 07 janvier 2017 à 19:34. Évalué à 3.
    
    Faut pas le prendre mal.
    C'est une philosophie qui tient la route, on se préoccupe trop pas de la QA tant qu'une métrique de performance ne s'effondre pas. Quand tu bosses pas sur un service critique, et que la plupart du temps t'as pas de problème, pourquoi s'emmerder?
    
    Tu balances tout en prod, et quand PagerDuty te gueule dessus, tu rolles back (ou forward si c'est suffisament simple).
    La grande majorité des apps/sites grand public tombent dans cette catégorie, si le service est partiellement indisponible, c'est pas une catastrophe. C'est la,philosophie que je suis tant que je contrôle les déploiements.
    
    Je pense que ca fait pas de mal de rappeler que la qualité dans l'industrie web grand publique est au ras des pâquerettes, c'est pas sale, mais c'est clairement pas généralisable a tout le monde.
    
    Linuxfr, le portail francais du logiciel libre et du neo nazisme.
    
    [^] # Re: XML sapu et autres billevesées
    
    Posté par barmic le 08 janvier 2017 à 09:36. Évalué à 3.
    
    Arrête, j'ai vu différentes boîtes industrielles qui sont typiquement dans le "notre service est critique" faire absolument n'importe quoi. J'ai vu des raté à tous les niveaux et :
    
    soit ça marche (pour le moment) par chance
    
    soit ça marche pas et la boîte se casse la gueule
    
    soit c'est une grosse boîte qui est assez solide pour en survivre
    
    À côté de ça des boîtes pures web, n'ont pas le droit de se planter. Livrer n fois par jours je ne suis pas sûr qu'il y ait beaucoup de monde en France qui le fasse et quand ça te coûte 2h, c'est suffisamment chère pour que tu le prenne plus au sérieux que ça.
    
    Bref tout ça pour dire que les gens que j'ai rencontré qui m'expliquent que eux ils font de la qualité contrairement à (choisi la tête de turc que tu veux) ont toujours soit était des menteurs qui balancent ce discours parce qu'ils savent que c'est ce qu'ils devraient faire, soit ne se rendent carrément pas compte de ce que c'est que la quantité logiciel.
    
    Par extension j'ai tendance à me foutre de la gueule de tout ceux qui affirment faire de la qualité. La qualité c'est un chemin sans fin, une démarche que tu prends, pas quelque chose de binaire. Et ça n'a rien de simple ! C'est complexe et extrêmement chronophage.
    
    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
- [^] # Re: XML sapu et autres billevesées
  
  Posté par Jehan (site web personnel, Mastodon) le 13 janvier 2017 à 15:32. Évalué à 2.
  meilleur rapport signal / bruit (moins d’octets perdus)
  
  Le XML (comme tout format texte avec syntaxe répétitive) est très compressible, rendant l'argument obsolète. Tous les formats ou protocoles qui sont basés sur XML le compressent dans l'usage "normal" (hors débuggage où on désactivera la compression temporairement).
  
  pas de différentiation entre attribut et valeur du nœud
  
  Je ne comprends pas ce que tu veux dire.
  
  encodage fixé par la norme
  
  Si c'est pour de l'échange de fichier, le fichier XML définit simplement son codage dans sa déclaration. Ensuite le décodage est quand même un truc de base sur tous les systèmes. La seule problématique est lorsqu'un format de fichier ne déclare pas le codage donc il faut faire de la détection (ce qui n'est pas du 100% de réussite). Mais comme XML le fait, y a pas de problème ici.
  En plus dans les faits, très souvent les sous-formats vont imposer un codage unique (souvent UTF-8). C'est le cas par exemple de XMPP.
  
  types de base existants dans le langage (liste, flottants, chaînes), faisant partie de la norme, là où XML n’a que des chaînes
  
  Si tu fais du XML bête et méchant, sans schéma, oui il n'y a pas vraiment de types. Mais un format XML est fait pour être défini (en fait XML en soi est un format générique pour faire des formats spécifiques!), par exemple dans un schéma XML et là tu as tous les types que tu veux.
  En outre, là où XML va avoir une étape de validation générique au niveau de ton parseur (que tu n'as donc en général pas à implémenter dans le code; en utilisant une bibliothèque XML externe, on se contente de fournir le schéma et la validation est faite pour nous), tu dois en général implémenter de la validation spécifique pour un format json.
  
  Sans compter la reprise sur erreur: comme XML a une étape de validation du schéma, il est capable d'ignorer tout erreur de contenu (mauvais type, attributs inconnus, etc.), mais en le prenant en compte, avec par exemple simplement un avertissement dans le programme qu'il y a une corruption possible du fichier. En très peu de ligne (encore une fois, en se reposant sur une bibliothèque générique), on va définir de la gestion d'erreur précise pour divers cas et on ne sortira en erreur complète que sur les problèmes majeurs. C'est même la base de certains sous-formats de XML, par exemple XMPP encore, qui est extensible par nature, a certaines caractéristiques obligatoires mais peut aussi accueillir des extensions (et un client/serveur peut les ignorer s'il ne les prend pas en charge mais sans jamais casser la connexion ou le transfert fiable et complet des données).
  Json pourrait faire tout cela bien sûr, mais nécessite beaucoup de code spécifique et sera donc bien plus prompt aux erreurs de programmation. Surtout en gestion d'erreur, on sait tous que c'est exactement le genre de trucs chiants que beaucoup vont laisser "pour plus tard"; et le manque dans le code ne se voit pas pendant longtemps — puisque logiquement en général le contenu utilisé est valide — jusqu'au jour où on tombe sur un bout de données corrompu et là, le programme risque de vraiment mal le prendre!
  
  Ensuite XML est clairement beaucoup plus lourd à mettre en place et ce n'est pas à utiliser selon moi pour des usages simples. Genre effectivement pour une API web, on va peut-être éviter de la compression (quoique ça dépend; même pour du json, si l'API est faite pour transporter pas mal de données, cela peut être rentable de compresser). De même pour plein de petits formats très courts (typiquement dans une API web, on peut considérer que chaque réponse à une fonction a potentiellement un format différent), on veut peut-être pas écrire plein de mini-schémas XML. Ce serait vite ennuyeux.
  Dans plein de cas, json est bien plus léger, simple et flexible. Donc c'est plus agréable pour tous ces petits usages simples. Par contre dans le cas de la création d'un format long et complexe, beaucoup utilisé et structuré, je ne choisirai probablement jamais json. C'est juste le moyen idéal pour se retrouver avec des fichiers invalides sans même s'en rendre compte pendant des semaines (jusqu'au jour où notre programme a besoin de parser ce bout du fichier et saute à notre figure).
  
  Quant à des fichiers de conf (si on prévoit édition par un humain), je n'utiliserais ni json ni XML, mais un format simple "attribut: valeur" ou "attribut = valeur", type fichiers INI. Parce que quand on parle d'édition et lisibilité possible par un humain, je suis désolé mais ni json ni XML ne sont de bons choix. Typiquement c'est très facile de casser un fichier de l'un ou l'autre format (classique: oublier le tag fermant en XML ou le crochet fermant en json).
  Par contre lisibilité par un développeur (pour débugguer par exemple), je trouve les 2 aussi lisibles du moment qu'ils indentés pour faciliter le débuggage (et les 2 aussi illisibles s'ils sont pas indentés ou sans retour à la ligne).
  
  Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
  - [^] # Re: XML sapu et autres billevesées
    
    Posté par whity le 13 janvier 2017 à 16:32. Évalué à 1.
    
    Tous les formats ou protocoles qui sont basés sur XML le compressent dans l'usage "normal" (hors débuggage où on désactivera la compression temporairement).
    
    Ce n’est pas le cas de soap (par exemple). La compression HTTP ne s’est pendant très longtemps faite que pour la réponse (je crois que désormais il y a aussi des choses pour le faire sur la requête, mais je ne suis pas sûr que ça soit tout standardisé). J’avais développé des extensions pour de la compression de requête, vers la fin des années 2000, il n’y avait à l’époque rien de standard. Ça fonctionnait bien, mais ce n’était plus du tout interopérable, du coup (on s’en foutait car on maîtrisait le client et le serveur, mais de manière générale c’est un manque).
    
    pas de différentiation entre attribut et valeur du nœud
    
    Je ne comprends pas ce que tu veux dire.
    
    La différence entre <toto attr="tutu" /> et <toto><attr>tutu</attr></toto> . Sémantiquement, c’est compliqué de savoir lequel est la « forme à utiliser ».
    
    le fichier XML définit simplement son codage dans sa déclaration.
    
    Oui, ça veut dire que ton parseur doit connaître tous les encodages de la terre (ou qu’on puisse lui apprendre).
    
    En plus dans les faits, très souvent les sous-formats vont imposer un codage unique (souvent UTF-8). C'est le cas par exemple de XMPP.
    
    Contrainte que… tu ne peux pas exprimer avec un schéma. C’est ballot, mais logique car du point de vue XML l’encodage n’est pas censé être différenciant (deux documents xml d’encodage différents mais de contenu identique une fois normalisé en utf-8 ont la même signature, par exemple). Un protocole qui impose l’encodage va quelque part à l’encontre de la norme.
    
    En outre, là où XML va avoir une étape de validation générique au niveau de ton parseur (que tu n'as donc en général pas à implémenter dans le code; en utilisant une bibliothèque XML externe, on se contente de fournir le schéma et la validation est faite pour nous)
    
    Valider uniquement avec un schéma est complètement casse gueule (cf exemple précédent :) ). C’est complètement insuffisant, tu as quand même une validation à faire en complément. L’intérêt de la validation XSD est réel, mais je ne me reposerai pas dessus, et certainement pas comme première passe avant lecture car en plus c’est coûteux. C’est plus utile en validation de données produites, par contre.
    
    Si tu veux un exemple simple, une contrainte comme « date < date_du_jour » (contrainte métier tout à fait raisonnable) n’est pas exprimable. Au final, la validation xsd ne te dispense pas de faire ton boulot correctement.
    
    Quant à des fichiers de conf (si on prévoit édition par un humain), je n'utiliserais ni json ni XML, mais un format simple "attribut: valeur" ou "attribut = valeur", type fichiers INI.
    
    Par curiosité, comment tu fais quand tu as des données arborescentes à représenter dans tes fichiers de conf (ou simplement des listes) à plat ? Parce que pour l’instant, tous les trucs que j’ai vus relèvent du bricolage vraiment pas beau (cf les fichiers que pond QSettings).
    
    Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
    
    [^] # Re: XML sapu et autres billevesées
    
    Posté par Jehan (site web personnel, Mastodon) le 13 janvier 2017 à 17:41. Évalué à 4. Dernière modification le 13 janvier 2017 à 17:42.
    
    La différence entre et tutu . Sémantiquement, c’est compliqué de savoir lequel est la « forme à utiliser ».
    
    Ben quand tu as un truc unique qui peut être exprimé en valeur simple, tu fais un attribut. Ensuite dès que c'est une donnée compliquée (qui va être composée de plusieurs valeurs), ou que tu peux en avoir plusieurs, c'est forcément un nœud fils. Quand tu crées ton schéma, c'est à toi de connaître tes données.
    
    Un protocole qui impose l’encodage va quelque part à l’encontre de la norme.
    
    Pas du tout. On avait ce type de remarques régulièrement sur XMPP, du type "XMPP, c'est pas du vrai XML car vous n'utilisez qu'une partie des fonctionnalités" (voir les restrictions XML). Mais non, ce n'est pas vrai. Tout flux XMPP est un document XML absolument bien formé qui sera traité sans erreur dans n'importe quel parseur XML générique.
    Encore une fois, XML n'a pas pour but d'être un format final en soi. Il n'y a aucune sémantique dans XML. D'ailleurs si tu fais une recherche sur la spec du terme "semantic", ça ne retourne qu'une seule occurrence qui dit exactement cela:
    
    This specification does not constrain the application semantics, use, or (beyond syntax) names of the element types and attributes, except that names beginning with a match to (('X'|'x')('M'|'m')('L'|'l')) are reserved for standardization in this or future versions of this specification.
    
    C'est à chacun de faire un format et d'y ajouter de la sémantique. La création du format final peut ainsi passer par se limiter à un sous-ensemble de XML. C'est comme l'utilisation d'un langage de programmation: cela n'oblige absolument pas les développeurs à utiliser toutes les fonctionnalités du dit-langage, voire même les autorise à en interdire certaines dans leur programme (exemple très courant: le C++ où beaucoup de développeurs vont interdire l'utilisation de certains fonctionnalités dans leur code, comme dans le Google C++ style guide; notamment les exceptions sont une fonctionnalité interdite dans beaucoup de gros projets C++). Est-ce à dire que le code C++ de Google ou d'ID Software (Doom 3) n'est pas du C++ parce qu'ils n'utilisent qu'un sous-ensemble (clairement interdisant pas mal de fonctionnalités)?
    
    Enfin pour revenir plus précisément à cette fonctionnalité (codage de caractères dans XML), la spéc dit clairement:
    
    (processors are, of course, not required to support all IANA-registered encodings)
    
    Puis un peu plus bas:
    
    Unless an encoding is determined by a higher-level protocol, it is also a fatal error if an XML entity contains no encoding declaration and its content is not legal UTF-8 or UTF-16.
    
    Comme tu vois, la spéc XML est clairement préparée à ce que le codage puisse être déterminé non par la déclaration, mais par le protocole de plus haut niveau (par exemple XMPP). XML est vraiment fait dans l'optique qu'il va en général y avoir une spéc de plus haut niveau qui donnera une vraie sémantique aux éléments et attributs. Sans cela, XML n'est qu'une sorte de syntaxe ou grammaire générique.
    
    Si tu veux un exemple simple, une contrainte comme « date < date_du_jour » (contrainte métier tout à fait raisonnable) n’est pas exprimable. Au final, la validation xsd ne te dispense pas de faire ton boulot correctement.
    
    Bien sûr, tu ne peux pas tout valider dans un schéma XML (qui est aussi un format générique et n'a bien entendu aucune logique par rapport à ton besoin particulier, ou "logique métier" comme on dit), mais tu parlais pas de ça. Tu parlais des types de base et comme quoi XML n'en avait pas hormis string, contrairement à json. Je te réponds que si, avec les schémas. Et maintenant tu réponds que ça fait pas le café non plus! Faut pas changer non plus d'argument à chaque phrase! Non parce que json non plus ne fait le café! :P
    
    Le fait est que XML a des types de base, et c'était donc ma réponse à ton assertion comme quoi il n'y en avait pas; et qu'en plus la validation de ces types peut être faite avant le code spécifique (pas en json, où ça doit être fait dans le code, à moins d'ajouter un mécanisme de schéma spécifique au json). Ça n'empêche en effet absolument pas une validation complémentaire dans le code si nécessaire (comme ton exemple de date). Mais au moins, on sait que les données arrivent directement dans le bon type si on valide avec un schéma.
    
    Par curiosité, comment tu fais quand tu as des données arborescentes à représenter dans tes fichiers de conf (ou simplement des listes) à plat ?
    
    Je l'explique plus haut, dans un autre commentaire. En gros, si tu as un besoin super complexe dans un fichier destiné à être édité par un humain de manière régulière, j'aurais tendance à dire qu'y a un problème plus profond de design logiciel. Si tu dois représenter des données très complexes, faut alors avoir une interface graphique adaptée et compréhensible (et en interne, un format adapté, pas du clé=valeur). Parce que je suis désolé, mais que ce soit du json ou du XML, si y a plusieurs niveaux et une arborescence avancée, c'est juste imbitable pour un non-programmeur. Je mets pas ça entre les mains des gens par design comme étant dans le fonctionnement normal de l'application.
    
    Un truc que tu veux éditable par les gens dans le fonctionnement habituel du programme, c'est un fichier très simple. Sinon y a vraiment un problème de design.
    
    Ensuite ces formats clé=valeur ont tout de même des types de base (chaînes de caractère, nombre et booléen), et des listes (ex: le format clé=valeur standardisé par Freedesktop, dont je donne déjà le lien plus haut a des listes avec séparation des éléments par des point-virgules). Et puis il y a des groupes (mais ca s'arrête là au niveau "arborescence", pas de niveau supplémentaire au delà).
    Il y a un minimum de fonctionnalité tout de même! :-)
    Cela devrait être bien suffisant pour un fichier destiné à édition manuelle.
    
    Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
    
    [^] # Re: XML sapu et autres billevesées
    
    Posté par groumly le 14 janvier 2017 à 23:15. Évalué à 2.
    
    Ce n’est pas le cas de soap (par exemple). La compression HTTP ne s’est pendant très longtemps faite que pour la réponse (je crois que désormais il y a aussi des choses pour le faire sur la requête, mais je ne suis pas sûr que ça soit tout standardisé). J’avais développé des extensions pour de la compression de requête, vers la fin des années 2000, il n’y avait à l’époque rien de standard. Ça fonctionnait bien, mais ce n’était plus du tout interopérable, du coup (on s’en foutait car on maîtrisait le client et le serveur, mais de manière générale c’est un manque).
    
    J'ai du mal à comprendre, soap pass par http, qu'est ce qui t'empêche de compresser la requête et mettre le header content encoding qui va bien? Et en quoi c'est pas standard? Et dernièrement, en quoi json est épargné?
    
    Linuxfr, le portail francais du logiciel libre et du neo nazisme.
    
    [^] # Re: XML sapu et autres billevesées
    
    Posté par whity le 17 janvier 2017 à 00:33. Évalué à 1.
    
    J'ai du mal à comprendre, soap pass par http, qu'est ce qui t'empêche de compresser la requête et mettre le header content encoding qui va bien?
    
    C’est effectivement comme ça que je l’avais implémenté à l’époque.
    
    Et en quoi c'est pas standard?
    
    Parce que ça ne l’est pas, à ma connaissance. Je veux bien que tu me trouves le standard, sinon. Mais les différents standards relatifs à HTTP que je connais ne parlent que de compression des réponses (et c’est relativement logique : le client ne peut pas à priori savoir si le serveur supporte la compression des requêtes).
    
    Et dernièrement, en quoi json est épargné?
    
    json n’est pas épargné. Mais un document json est généralement plus petit que le document xml équivalent, ce qui est exactement l’avantage que je soulignais. On m’a rétorqué que « de toute façon, on compresse donc c’est pas si grave » (ce qui se tient), sauf que dans les faits, c’est loin d’être toujours vrai.
    
    Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
# ça juste marche ?

Posté par pseudovalide le 02 janvier 2017 à 00:10. Évalué à -3.

bon autant dire " IT JUST WORKS".
# dolphin et semantic search

Posté par YBoy360 (site web personnel) le 02 janvier 2017 à 07:37. Évalué à 7.

ça me rappelle Nepomuk, ça permettait de faire des requêtes SPARQL directement dant la barre de recherche. Il y avait aussi les activités. On pouvait faire des requêtes du style quel ficher ODF j'ai ouvert il y a 3 jours et contient le mot TOTO?

https://uoccou.wordpress.com/tag/sparql/
- [^] # Re: dolphin et semantic search
  
  Posté par gipoisson le 04 janvier 2017 à 16:13. Évalué à 5.
  ça me rappelle Nepomuk, ça permettait de faire des requêtes SPARQL […]
  
  Certes, ce n'est pas KDE¹ et ce n'est plus dans la barre de recherche², mais les ontologies de Nepomuk sont toujours utilisées, j'avais évoqué cela dans un autre commentaire et oublié de revenir dans ce fil pour montrer comment les s'en servir.
```
sh$ tracker sparql --help
sh$ cat > la_requête.rq << EOF
```
```
SELECT ?dateModif ?nomFichier
WHERE {
    ?uriFichier nfo:fileLastModified ?dateModif .
    ?uriFichier nfo:fileName ?nomFichier .
    FILTER ( ?dateModif > "2017-01-01T00:00:00Z"^^xsd:dateTime )
    FILTER regex( ?mime, ".odt"^^xsd:string )
} ORDER BY ?dateModif
```
```
EOF

sh$ tracker sparql --file=la_requête.rq
```
  Ça pourrait même être le meilleur moyen d'apprendre SPARQL car ça demande zéro configuration pour tout ce qui est outillage SPARQL.
  1. En fait j'ignore si tracker est packagé dans KDE. ↩
  2. Quoique ce serait possible d'écrire une extension GNOME qui lancera un shell après une requête saisie à cet endroit. ↩
# Euh ???

Posté par barmic le 02 janvier 2017 à 07:41. Évalué à 8.

En faisant le constat que sur le web, ce qui est rare ou limitant est probablement le temps de calcul des serveurs, l'idée d'être gentil avec eux et de déporter le calcul sur les clients et de ne demander aux serveurs que des choses qu'ils peuvent calculer rapidement, en laissant les clients faire les calculs complexes. Nos ordis passent beaucoup de temps à ne rien faire…

Ça c'est ce qu'on pouvait dire en 2010. Maintenant non la part des internautes mobiles est trop grande pour qu'on puisse accepter : de leur déporter du boulot "parce que le serveur est fatigué" ni de leur faire télécharger des trucs pour le fun.

À moins que l'on parle d'utilisation serveur à serveur ?

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
- [^] # Re: Euh ???
  
  Posté par Thomas Douillard le 02 janvier 2017 à 18:12. É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.
  - [^] # Re: Euh ???
    
    Posté par barmic le 02 janvier 2017 à 18:27. Évalué à 4.
    
    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.
    
    En vrai je pense que j'ai rien compris à tout ça… En pratique il s'agit de faire quoi ? Faire des recherches sur un site ? Sur une fédération de site ? C'est au dessus de HTTP ? De TCP ? Tout ce que j'ai croisé là dessus parlait de concepts plutôt que de cas pratique. J'ai vu qu'il y a une page sur wikidata pour faire des requêtes sur une partie des données de wikipedia, c'est bien pour un POC et pour comprendre le format des requêtes SPARQL, maintenant je fais quoi ? Ça devrait remplacer les webservices que j'utilise pour qu'un client angular accède aux données de son site ? Je devrais créer une ontologie de mes données à partir de ma base comme on crée un index elasticsearch ?
    
    Je ne sais pas trop réfléchir en top-down (malgrès que c'est ce que j'ai dû faire pendant toute ma scolarité), j'ai plutôt besoin de commencer petit et de faire du bottom-up.
    
    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
    - [^] # Re: Euh ???
      
      Posté par Thomas Douillard le 02 janvier 2017 à 19:13. Évalué à 4.
      
      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é :)
      - [^] # Re: Euh ???
        
        Posté par barmic le 03 janvier 2017 à 00:41. Évalué à 4.
        
        Ouai mais ça ne m'a pas vraiment convaincu et je ne crois pas que ça sortira des domaines d'expérimentation. Ton lien montre peu de site et il n'est pas à jour (le fait même que ce ne soit pas à jour monté le peu d'enthousiasme).
        
        Il y a un besoin de faire ce genre de croisement de données, mais au lieu de la solution qui au bout de quelques dizaines d'années manque encore de performance, demande à ce que tout le monde travail beaucoup (il y a un effort important à faire pour fournir les données et pour les consommer). Tout ça pour des résultats limité (tu ne peux pas appliquer véritablement les traitements que tu veux).
        
        Il y a des solutions et/ou des architectures qui vont te permettre de prendre n'importe quelle source de données, les joindre, y faire les transformations les plus exotiques imaginables et pouvoir scaler sur le volume de données linéairement… C'est le genre de choses que storm, spark, flink ou les architectures lambdas font aujourd'hui là maintenant, en open source et non-opiniated.
        
        Je vous pas l'intérêt de proposer un endpoint sparql par rapport à des ws (et non dire que les endpoint sparql c'est cool parce que ça permet de faire des requêtes sparql ça ne me paraît pas suffisant).
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Euh ???
        
        Posté par Thomas Douillard le 03 janvier 2017 à 08:17. É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 whity le 03 janvier 2017 à 09:22. Évalué à 2.
        
        ws = webservice
        scaler linéairement = augmentation linéaire du temps de traitement avec la taille des données. Ici on a plutôt l’impression que c’est exponentiel.
        
        Sinon, comme barmic, je dois bien dire que je ne comprends pas grand chose. Au langage sparql, déjà, à la fin de la lecture de la dépêche je ne suis pas sûr de savoir écrire une requête simple (même après la deuxième lecture). Fondamentalement, ça me rappelle ce qu’on pouvait faire avec prolog, avec une syntaxe encore plus obscure.
        
        Sinon, par rapport au croisement de données inter-site, logiquement, les croisements ne vont fonctionner que si tout le monde utilise les mêmes noms d’attributs. Or, dans les exemples, je vois que tout est en français. C’est traduit, ou bien chacun fait ce qu’il veut, il n’y a pas de norme établie ?
        
        Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
        
        [^] # Re: Euh ???
        
        Posté par gipoisson le 03 janvier 2017 à 11:24. Évalué à 3.
        
        Sinon, comme barmic, je dois bien dire que je ne comprends pas grand chose. Au langage sparql, déjà, à la fin de la lecture de la dépêche je ne suis pas sûr de savoir écrire une requête simple (même après la deuxième lecture).
        
        Les requêtes écrites directement dans de la dépêche sont là pour introduire la syntaxe et certaines notions mais elles ne sont pas exécutables. Un triplet est comme la traditionnelle formule grammaticale une phrase = SUJET + VERBE + OBJET ; en RDF, le verbe est appelé prédicat. On s'exprime en triplets sur le contenu d'une base de connaissances (BC) et ça c'est seulement au niveau de la syntaxe. C'est au moteur de requêtes de voir si les triplets écrits correspondent à quelque chose contenue dans la BC.
        
        La notion de nœud blanc est à comprendre comme un quantificateur existentiel : on est persuadé qu'il existe quelque chose dans la BC mais on ne sait pas comment le nommer, i.e. on ignore son URI et donc, on s'y réfère avec un nœud blanc¹.
        
        La requête envoyée sur WikiData masque la déclaration des préfixes et la spécification du graphe par défaut (la BC). Chaque nœud SPARQL possède un graphe par défaut ; comme l'expression « par défaut » l'indique, on peut changer le graphe à interroger et ça se fait avec la clause FROM ou FROM NAMED. En omettant ledit graphe par défaut, la requête complète se réécrit ainsi :
        
        PREFIX wdt: <http://www.wikidata.org/prop/direct/> select ?personne ?personneLabel { ?personne wdt:P22 ?father filter(isBlank(?father)) . SERVICE wikibase:label { bd:serviceParam wikibase:language "fr,en" . } }
        
        Comme pour toute autre ressource en RDF, un graphe est identifié par un URI. Si le graphe à interroger était identifié par foo:bar, la requête serait (ne pas exécuter ça !)
        
        PREFIX wdt: <http://www.wikidata.org/prop/direct/> FROM <foo:bar> select ?personne ?personneLabel { ?personne wdt:P22 ?father filter(isBlank(?father)) . SERVICE wikibase:label { bd:serviceParam wikibase:language "fr,en" . } }
        
        Le protocole indique comment et où un moteur de requêtes va chercher le graphe indiqué par FROM. Enfin, les PREFIXs évitent de réécrire l'espace des noms dans chaque triplet. Mais ici, comme il n'y a qu'une seule ressource utilisée dans cet espace, on peut omettre le préfixe :
        
        select ?personne ?personneLabel { ?personne <http://www.wikidata.org/prop/direct/P22> ?father filter(isBlank(?father)) . SERVICE wikibase:label { bd:serviceParam wikibase:language "fr,en" . } }
        
        Fondamentalement, ça me rappelle ce qu’on pouvait faire avec prolog, avec une syntaxe encore plus obscure.
        
        Le langage est plutôt conçu pour envahir le champ syntaxique du SQL. Il y a même une norme qui réalise un mapping cohérent entre SQL et SPARQL, ça s'appelle R2RML. Et c'est génial, car on peut se mettre à vider les bases de données relationnelles pour remplir des graphes RDF et faire des trucs très avancés, de la gageure si c'était à faire absolument en SQL².
        
        Ce que je trouve plutôt obscur, c'est cette volonté de continuer à forcer une syntaxe imaginée pour des données tabulaires sur des graphes. C'est typiquement le genre de situations où les types de données algébriques auraient fait des merveilles.
        
        Or, dans les exemples, je vois que tout est en français. C’est traduit, ou bien chacun fait ce qu’il veut, il n’y a pas de norme établie ?
        
        Les triplets, les graphes (ensembles de triplets) peuvent être typés. La syntaxe est en Unicode mais la sémantique est déterminée par un schéma. Il y a plusieurs types de schémas avec des niveaux d'expressivités variables : vocabulaires contrôlés, taxonomies, corpus, ontologies, … Les schémas sont eux-mêmes écrits en triplets. On ne dit pas ce qu'on veut a priori, on dit tout ce que le graphe (avec schéma ou non) permet. Mais on peut ajouter de nouveaux triplets arbitraires dans le graphe, donc a posteriori on peut écrire tout ce qu'on veut, c'est l'hypothèse du monde ouvert.
        
        Je simplifie énormément, il faudra rectifier le tir avec un peu d'expérience car les nœuds blancs constituent un sujet vaste et problématique ; on doit notamment adopter des stratégies pour les sérialiser, les skolémiser … ↩
        
        Revers de la médaille, à ma connaissance, il n'y a pas d'implémentation libre et crédible de R2RML. Il y a une équipe à l'université du Texas qui semble l'avoir solidement implémenté, malheureusement ils ont embrigadé leur code et se contentent de pondre régulièrement des articles pour annoncer comment leur outil est super. Oui oui, j'ai une dent contre cette équipe car elle comporte des personnes à qui on doit essentiellement la norme : pourquoi s'impliquer tellement dans un processus de normalisation W3C, en appartenant à une université, pour enfin se précipiter à fermer les outils ayant servi à tester que la norme est implémentable ? Pour mémoire et à ma connaissance, le seul outil crédible qui implémente la norme est Oracle Database à partir de la version 12. Mais peut-être que je me goure, j'aimerais que Thomas partage des infos là-dessus s'il en a (Thomas, si tu m'entends !) car lui il est immergé dans le Web Sémantique, il est à même d'acquérir ces infos. ↩
        
        [^] # Re: Euh ???
        
        Posté par Thomas Douillard le 03 janvier 2017 à 21:08. É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 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.
        
        [^] # Re: Euh ???
        
        Posté par gipoisson le 04 janvier 2017 à 10:06. Évalué à 2.
        
        De rien ! Peut-être que tu pourrais proposer une reformulation du § concerné aux modos.
        
        Désolé de pinailler mais EXISTS et la quantification existentielle ne sont pas AMHA deux notions équivalentes. La première renvoie à un opérateur sur un (mini-)graphe tandis que la deuxième est basiquement un opérateur sur une variable. C'est d'ailleurs pour cela qu'on peut remplacer une variable par un bnode et avoir le même résultat dans les deux cas.
        
        EXISTS est tellement conçu pour les graph patterns que la norme en dote une fonction dans l'algèbre des requêtes. Cela dit, l'équivalence bnodes ≣ variables devrait être utilisé au sein de basic graph patterns car en dehors de ça, les implémentations ont (auraient ?) la latitude d'adopter des stratégies qui leur chantent, sans oublier que si l'on passe à OWL, c'est quasi-garanti de se tirer une balle dans le pied avec cette équivalence. Lecture supplémentaire sur les bnodes avec une enquête sur leur utilisation dans des applications concrètes : DOI : 10.1007/978-3-642-25073-6_27. Le W3C en parle succinctement dans les sections 3.4 et 3.5 de ce document.
        
        Qu'est-ce que ça donne en pratique sur le nœud que tu as présenté ? Tout d'abord, les moteurs de recherche me renvoient sur la spéc. des dumps de WikiData où on peut lire ceci :
        
        Special values
        Wikibase data model has two special values - somevalue (unknown) and novalue, specifying value that is known to exist but its exact value is unknown and the value that is known to not exist.
        
        Somevalue
        Unknown value is represented as RDF blank node in both simplified and full statements (le dernier graissage est de moi).
        
        Ensuite, un peu de code pour accompagner toute cette exégèse : en reprenant la ressource que tu as introduite dans la dépêche, demandons au graphe des connaissances de WikiData s'il y aurait des pères qui sont encore vivants alors que leur progéniture a été touchée par la mort.
        
        PREFIX wdt: <http://www.wikidata.org/prop/direct/> PREFIX wikibase: <http://wikiba.se/ontology#> SELECT DISTINCT ?pèreLabel ?enfantLabel ?enfant WHERE { ?enfant wdt:P22 ?père . FILTER NOT EXISTS { ?père wdt:P570 ?dateDécèsPère . } # L.a-1 FILTER EXISTS { ?enfant wdt:P570 ?dateDécèsEnfant . } # L.b-1 SERVICE wikibase:label { bd:serviceParam wikibase:language "fr" . } }
        
        La requête illustre bien que EXISTS opère sur des graph patterns. Dans L.a-1 et L.b-1, les variables dateDécèsPère et dateDécèsEnfant peuvent être substituées par des bnodes, façon
        
        # […] FILTER NOT EXISTS { ?père wdt:P570 _:x . } # L.a-2 FILTER EXISTS { ?enfant wdt:P570 _:y . } # L.b-2 # […]
        
        et le résultat sera identique au premier.
        
        Enfin, nul doute que tu étais déjà au courant de tout ça ― ton passif sur ces sujets est éloquent de soi-même ― certainement que la phrase a été rapidement écrite entre deux itérations de zoom sur des fractales :p Bref, j'écris tout ce qui précède pour faire de la retape auprès des néophytes dans le domaine.
        
        P.S. Le résultat de la requête contient des choses rigolotes à cause de notices incomplètes sur certains personnages. Ainsi apprend-on par exemple que Sun Tzu est mort et que son père, Sun Ping, est toujours vivant. Le patriarche aurait-il trouvé et appliqué victorieusement l'art de la guerre … contre la mort ?
        
        [^] # Re: Euh ???
        
        Posté par Thomas Douillard le 04 janvier 2017 à 11:35. É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 gipoisson le 04 janvier 2017 à 15:42. Évalué à 1.
        
        Informellement, oui ça pourrait être ainsi, surtout dans une discussion visant à donner une « douce » introduction. Au-delà de ça, on se rappellera que la sémantique de SPARQL a été montrée équivalente à la logique de premier ordre. De là, il ressort déjà qu'on ne peut pas quantifier sur « des ensembles » (objets d'ordre supérieur, le premier ordre étant celui des triplets, pour continuer dans l'informel), or les graph patterns en sont ; on est limité à quantifier sur les éléments « simples » des ensembles.
        Mais il y a aussi la clause OPTIONAL : si on permet de quantifier sur les graph patterns, un EXISTS+OPTIONAL mènera à l'incohérence du graphe dès lors qu'il n'y aura pas de binding utilisable à l'intérieur de OPTIONAL.
        Sans oublier que EXISTS appelle NOT EXISTS. Dans une base de connaissances BC où cette dernière clause met le graphe dans une valeur de vérité T, il suffit de trouver un triplet P tel que BC+P conduira à ¬T pour ruiner la tentative de quantification sur EXISTS. La norme garantit que BC+P est cohérent : c'est un graphe donné par la clause UNION.
        
        [^] # Re: Euh ???
        
        Posté par Thomas Douillard le 04 janvier 2017 à 16:01. É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 gipoisson le 04 janvier 2017 à 17:13. Évalué à 1.
        
        Basic graph patterns are sets of triple patterns. SPARQL graph pattern matching is defined in terms of combining the results from matching basic graph patterns. […] Any other graph pattern terminates a basic graph pattern.
        
        The filter expression EXISTS is also provided. It tests whether the pattern can be found in the data; it does not generate any additional bindings.
        
        In situations where stronger identification is needed, systems MAY systematically replace some or all of the blank nodes in an RDF graph with IRIs. Systems wishing to do this SHOULD mint a new, globally unique IRI (a Skolem IRI) for each blank node so replaced.
        
        Dans l'article Mallea et al. donné dans un autre commentaire, on lit :
        
        In first-order logic (FO), Skolemization is a way of removing existential quantifiers from a formula in prenex normal form (a chain of quantifiers followed by a quantifier-free formula). […] The central idea of Skolemization is to replace existentially quantified variables for “fresh” constants that are not used in the original formula.
        
        Si tu quantifies existentiellement un graph pattern qui ne saurait générer de nouvelles ressources, ça va être compliqué de le skolémiser, surtout lorsqu'il s'agira de le typer fortement (stronger identification) pour lui conférer une sémantique non-ambigüe.
        Et, encore une fois, qu'est-ce qui va se passer si tu as introduit un GP avec OPTIONAL et qu'on admet que la quantification est permise ? Ça s'appellera une « inception-quantification » vu que OPTIONAL peut mener à un GP vide ?
        
        Mais encore une fois, je vois bien pourquoi tu assimiles la quantification ∃ à un parcours d'un graphe à la recherche d'une certaine propriété. Au début, de ce thread, je disais même que j'allais pinailler.
        
        [^] # Re: Euh ???
        
        Posté par Thomas Douillard le 04 janvier 2017 à 17:22. É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 gipoisson le 04 janvier 2017 à 18:26. Évalué à 1. Dernière modification le 04 janvier 2017 à 18:28.
        
        Ou alors file des exemples.
        
        Facile ! Soient les triplets suivant :
        
        PREFIX foo: <bar://woe.truc.machin/> _:a foo:x _:b . _:c foo:y [ foo:x foo:d ] .
        
        Contrat d'implémentation. Mon moteur SPARQL garantira qu'après sérialisation-désérialisation de ce graphe, on aura toujours le graphe suivant :
        
        PREFIX foo: <bar://woe.truc.machin/> PREFIX bar: <bar://woe.truc.skolem/> bar:a foo:x bar:b . bar:c foo:y bar:e . bar:e foo:x foo:d .
        
        Maintenant, saurais-tu retourner la faveur et filer des exemples de skolémisation de graph patterns passés au à l'opérateur booléen FILTER EXISTS ?
        
        [^] # Re: Euh ???
        
        Posté par Thomas Douillard le 04 janvier 2017 à 18:59. É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: Euh ???
        
        Posté par gipoisson le 04 janvier 2017 à 19:09. Évalué à 1.
        
        Voir ce wiki et la discussion qui est référencée.
        
        [^] # Re: Euh ???
        
        Posté par gipoisson le 05 janvier 2017 à 10:24. Évalué à 1.
        
        Compléments sur les implémentations de la skolémisation en regardant ce qui se fait chez
        
        Apache Jena : le commentaire reflète la nature polémique qu'a toujours véhiculé cette notion. On notera d'ailleurs que la discussion du groupe W3C chargé de normaliser le concept s'est terminée en queue de poisson. À souligner que chez le W3C la controverse ne portait pas sur ce qu'est la skolémisation, tout le monde était d'accord que ça porte sur des bnodes. Andy Seaborne écrit “Skolemization of blank nodes to IRIs : Don't ask, just don't ask.” sans doute pour éviter de réveiller la controverse.
        
        Blazegraph : ça c'est l'outil actuel qu'on trouve sur le nœud SPARQL de WikiData. Dans la javadoc, Brad Bebee écrit que l'outil génère des UUIDs pour les bnodes. Ailleurs dans le code, il est précisé comment on retrouve le même UUID pour un bnode donné après (dé-)sérialisation. Je lie le code source pour mémoire.
        
        RDFLib : pour essayer de casser la monoculture Java évoquée par ailleurs, je mentionne cette lib écrite en Python (voir aussi le point ici-bas) ; dans le code lié, le nom de la méthode est des plus explicites et se passe de commentaire !
        
        rdf4h : un paquet écrit en Haskell. Le commentaire de Rob Stewart sur la comparaison de bnodes est très intéressant, je le cite en le traduisant : « J'hésite à tester l'égalité entre des bnodes normaux et des bnodes générés automatiquement parce qu'un bnode qui a été sérialisé est parsé tel quel¹. L'autre facteur de doute est que chaque parseur RDF est libre de choisir son format pour les bnodes.»
        
        Eh bien ! revenons aux fondamentaux en rebondissant sur ce qu'écrit R.S. Dans le Mallea et al. déjà mentionné deux fois ailleurs dans les commentaires², dans la sous-section 4.1, on peut lire ceci sous l'intertitre “Issues with blank nodes” : « Les stratégies de parsing de bnodes à partir d'un graphe sérialisé, i.e. un document, varient suivant le parseur considéré et dans le temps. La conséquence en est que pour vérifier si deux graphes proviennent d'une même source, on sera obligé de prouver un isomorphisme or on ne connait pas d'algorithmes généraux à complexité polynomiale répondant à cette tâche. » Cela est écrit bien sûr après une section explicitant sur quoi porte la skolémisation.
        
        En somme, je crois que j'ai apporté suffisamment d'eléments sur la skolémisation en RDF. Jusqu'à maintenant, je n'ai vu aucune source melant cette notion avec les graph patterns et les opérateurs qui leur sont applicables.
        
        Dans le parseur, il n'y a pas de risque de créer une IRI valide à partir de quelque chose qui avait été sauvegardée à partir d'un bnode. ↩
        
        C'est un article bien écrit et qui fait un tour quasi-exhaustif de la question des bnodes, à lire sans modération ! ↩
        
        [^] # Re: Euh ???
        
        Posté par Thomas Douillard le 08 janvier 2017 à 11:26. É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 le 03 janvier 2017 à 13:51. É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 gipoisson le 03 janvier 2017 à 10:09. Évalué à 10.
        
        Ouai mais ça ne m'a pas vraiment convaincu et je ne crois pas que ça sortira des domaines d'expérimentation. Ton lien montre peu de site et il n'est pas à jour (le fait même que ce ne soit pas à jour monté le peu d'enthousiasme).
        
        En supplément de la réponse de Thomas, voici d'autres cas d'utilisation du Web Sémantique (WS) et qui sont tirés d'horizons diversifiés.
        
        Projets d'envergure des GAFAM
        
        Dans cette catégorie, ce sont les applications de type knowledge graph qui prédominent. De la même manière que SQL est systématiquement associé à la notion de table, SPARQL a sa structure de données de prédilection, le graphe (ou le tenseur pour généraliser). Il se trouve qu'une palanquée de situations sont mieux capturées dans des graphes plutôt que dans des tables. C'est ce qu'ont constaté
        
        Google qui a avalé Freebase pour plus tard verser une partie de son contenu dans dbPedia et surtout, pour créer leur Knowledge Graph. Il est difficile de trouver des détails sur son implémentation mais c'est un projet qui est omniprésent dans leur moteur de recherche. Par contre, Freebase reposait bien entendu sur les langages du WS. Google propose tout de même une API non-WS exposant son graphe de connaissances.
        
        Microsoft avec son Satori dont il est difficile de trouver des détails qui ne sont pas du mainstream, un paradoxe … lorsq'on regarde l'étymologie de l'appellation donnée à leur outil. Cependant, cet article ne laisse pas de place au doute que SPARQL est utilisé dans Satori.
        
        Google, Microsoft, Yahoo et Yandex en joignant leurs forces pour concevoir des schémas en RDFa à usage de moteurs de recherche.
        
        Apple en rendant Siri friand des données structurées selon les pratiques du WS. Dit en passant, c'est ce Tom Gruber qu'on cite à chaque fois qu'on veut donner une définition de ce qu'est une ontologie informatique.
        
        IBM en faisant ingurgiter à Watson une immense quantité de données tirées du WS. L'article dit que parmi les sources de données filées à W., il y avait des « bases de données, des taxonomies ou vocabulaires contrôlés et des ontologies telles dbPedia, WordNet et Yago.»
        
        Nvidia avec son Blazegraph décliné en deux versions, une pour GPUs et une autre pour CPUs. C'est ce même outil qu'utilise le nœud SPARQL de WikiData et il passe très bien à l'échelle vu qu'il se permet de battre Apache Spark dans des benchmarks.
        
        Oracle en mettant en place Spatial and Graph RDF Semantic Graph. Mais on ne s'est pas arrêté aux données géospatiales chez Oracle car on propose aussi une implémentation de la norme W3C appelée R2RML. Ainsi, on peut faire des aller-retour entre SQL et SPARQL sans perdre la sémantique des données.
        
        Et beaucoup d'autres ! Mentions spéciales pour Virtuoso, Jena, RDF4J, AllegroGraph ainsi que Stardog.
        
        Projets Spécialisés à Certaines Disciplines
        
        Il y en a des myriades, ça va de l'archivage, à la configuration de pièces composant un produit mécanique, en passant par les sciences biomédicales. Deux exemples pour faire court :
        
        NELL, une machine qui apprendra jusqu'à ce que mort s'en suive !
        
        Portail où sont déposées beaucoup d'ontologies conçues pour la Bioinformatique.
        
        Année™ du™ Desktop™ sur™ Linux™ (ADL)
        
        Même dans ton GNU, il y a des triplets qui moulinent pour indexer le système de fichiers. Le projet original s'applelait Nepomuk et avait été repris dans FreeDesktop. Depuis, KDE l'a éliminé pour le remplacer avec Baloo. Son leg se retrouve dans Zeitgeist et dans Tracker. Pour dire que si tu utilises GNOME, tu as déjà des cas très concrets où SPARQL fonctionne sans même t'en douter.
        
        Si des iGadget-Users nous narguent nous autres GNOMErs en disant que notre outil n'a pas d'assistant personnel, on pourrait leur rétorquer qu'à la base, Siri est une sorte de moteur de requêtes fédérées sur des vocabulaires et que GNOME en a depuis Nepomuk ; bref que l'ADL c'est pas de la fixion !
        
        P.S. 1- Pour « mélanger » des graphes provenant de plusieurs sources, on fait des opérations d'alignement, de matching, de fédération sur leurs schémas (ontologies). Mais ces traitements sont quasi superflus si on ne s'oriente pas vers des questions d'inférence sans qui on peut manipuler des corpus dotés des centaines d'ontologies, pourvu que le moteur SPARQL tienne. Voir par exemple sur sur cette page même s'il y a un peu de curation de ce côté-là.
        
        P.S. 2- Le Center for Data Science à Paris-Saclay héberge des nœuds SPARQL très hétérogènes, cela peut être un moyen de s'exercer au WS en travaillant sur des jeux de données qui n'ont été conçus ni au même endroit ni en poursuivant les mêmes objectifs.
- [^] # Re: Euh ???
  
  Posté par Alex G. le 03 janvier 2017 à 17:15. Évalué à 1.
  
  Perso je trouve ça intéressant aussi pour le serveur à serveur. Si on veut un web décentralisé, il faudra certainement explorer ces techniques où la charge est répartie de serveur en serveur, surtout si les accès sont contrôlés (ainsi je peux faire ma recherche dans mes documents du boulot, ceux de mon projet open-source et ceux de mon groupe d'activiste pour le contrôle des chats pour internet).
- [^] # Re: Euh ???
  
  Posté par rpnpif le 07 janvier 2017 à 09:28. Évalué à 1.
  
  En faisant le constat que sur le web, ce qui est rare ou limitant est probablement le temps de calcul des serveurs, l'idée d'être gentil avec eux et de déporter le calcul sur les clients et de ne demander aux serveurs que des choses qu'ils peuvent calculer rapidement, en laissant les clients faire les calculs complexes.
  
  J'ai relu 3 fois cette lononongue phrase pour la comprendre. Ne manquerait-il pas quelque chose ?
  
  « l'idée d'être gentil avec eux est de déporter »… ?
  - [^] # Re: Euh ???
    
    Posté par Benoît Sibaud (site web personnel) le 07 janvier 2017 à 11:37. Évalué à 3.
    
    Corrigé, merci. (« l'idée est d'être avec eux et de déporter »)
# Bof

Posté par barmic le 02 janvier 2017 à 07:57. Évalué à 5.

Merci pour la dépêche, j'ai eu du mal à comprendre (par exemple, avec le mot clé a tu parle d'uri mais elles interviennent où ?).

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.

Ton introduction parle des moteurs de recherche texte pleins. C'est la seule façon de faire des requêtes sur du contenu non structuré. Ce dont tu parle s'attaque à un problème différent : les données structurées.

Aujourd'hui les webservices (soap, rest ou pas vraiment rest) répondent à ce problème. Ils sont faciles à apprendre et à implémenter. Ça répond très bien et très vite.

Je présume que ce sont tu parle permet d'adresser la forme des requêtes qui du coup deviennent standards (enfin pas normalisé de ce que j'ai compris) et le fais de pouvoir faire des jointures entre site.

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

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
- [^] # Re: Bof
  
  Posté par damaki le 02 janvier 2017 à 13:26. Évalué à 0. Dernière modification le 02 janvier 2017 à 13:30.
  
  Je pense que le principal souci est que cette techno recrée le même problème qui a provoqué la naissance du pagerank de Google : les sites qui trichaient avec leurs keywords et leur contenu. Ça part du principe que les sites sont sincères. Et ça part aussi du principe, clairement obsolète, que les métadonnées fournies par le site sont suffisantes pour mesurer la pertinence et la qualité d'un site.
  Le principe même de la SEO, quelle que soit l'époque, c'est soit de mentir (dans le pire des cas) soit de customiser le site pour plus ressortir que les autres. Et même regarder le contenu même des pages est à peine suffisant pour en déduire la qualité, d'où l'ancien système pagerank avec le compte du nombre de liens hypertextes existants vers la page. Et inversement dans un cas de non optimisation des métadonnées, un site excellent pourrait aussi être ignoré par l'index d'un tel moteur de recherche.
  
  Alors non, la main-mise de Google n'est pas une bonne chose, mais cette techno n'est en aucun cas une solution.
  - [^] # Re: Bof
    
    Posté par damaki le 02 janvier 2017 à 16:45. Évalué à 1.
    
    Faut pas que je poste quand je suis malade. 75% de hors-sujet. Je sors…
- [^] # Re: Bof
  
  Posté par Thomas Douillard le 02 janvier 2017 à 14:17. Évalué à 3.
  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.
# De l'art de râler

Posté par gipoisson le 02 janvier 2017 à 10:21. Évalué à 10. Dernière modification le 02 janvier 2017 à 11:20.
Sommaire
Merci de cette dépêche sur ces sujets plutôt en retrait dans ces lieux, si ce n'est Thomas Dᴏᴜɪʟʟᴀʀᴅ qui en parle régulièrement pour nous instruire sur la vie de WikiData. Je vais aller un peu hors sujet de la dépêche et pousser quelques grognements à partir des extraits infra.

[…] ce domaine et la recherche autour ont dans un premier temps donné naissance à des technologies normalisées par le W3C […]
[…] est un langage qui ressemble beaucoup à SQL, dont il reprend d'ailleurs des mots clés et des constructions, étendu pour pouvoir gérer des relations qui ne sont pas définies à la manière des schémas de données SQL classiques […]
[… SPARQL] délègue ainsi le typage des données qu'il manipule à RDF et RDFS. […] Il y aurait beaucoup à dire sur le typage dans le web sémantique, mais c'est hors cadre de cet article. Ça concerne la notion d'ontologie formelle, et les couches plus hautes de la pile du web sémantique comme OWL et les moteurs d'inférences. Ces couches rajoutent la possibilité de faire des schémas de données plus avancées, et la possibilité de déduire des triplets qui ne sont pas explicites dans le dépôt grâce à des règles logiques.

Ça dévisse

En creusant un peu divers documents traitant du Web Sémantique (WS), il devient apparent que la communauté autour souhaite vivement attirer les individus habitués au WWW. La perspective de passer d'une toile de pages à une toile d'URIs ne manque pas de fringuant, un de ses effets de bord coïncidant avec les thèmes souvent abordés ici pourrait être la sortie de la googlisation rampante. Toutefois, il me semble que les dévs. SQL n'ont pas massivement migré vers SPARQL, au contraire, ce dernier reste un langage confidentiel si l'on se fie à une pifométrie comme celle-ci : plus de 365 kilo-questions versus environ 3 kilos. Il n'y aurait même pas la possibilité de mettre cette disproportion (perçue) sur le dos de la jeunesse, les initiatives de normalisation du WS ayant débuté quelques années après celles sur le WWW.

Tout cela pour en arriver à un ensemble de questions qui me taraudent et que j'aimerais poser à vous qui êtes plus au fait de ce qui se fait dans le WS.
- Est-ce justifié de continuer à chercher de « faciliter la vie » aux aficionados du SQL ? Si oui, pourquoi faire et pour quoi faire ?
- Pourquoi se trimbaler un système de typage qui est, si ce n'est bancal, volontairement bridé alors que si l'on pousser à fond du côté des ontologies, on pourrait augmenter significativement son expressivité ?
- Est-ce la même volonté de louvoyer vers des « dévs. standards » qui est derrière la monoculture Java qui semble régner dans ce milieu ? Dès qu'on examine l'outillage, on ne manquera sans doute pas de remarquer que les outils Java se sont taillés une part de lion dans le WS.
Hors-sujet approfondi

Bien que les logiques de description soient déjà limitées, notamment par rapport aux logiques d'ordres supérieurs, il est étonnant de voir un langage comme OWL encore réduit dans ses implémentations pratiquement à son sous-ensemble compatible avec la Programmation Orientée Objet. Là où il serait légitime de s'attendre à ce qu'un tel langage soit implémenté dans des langages plus ou moins proches de son cadre théorique¹, on se retrouve avec une API officielle déclinée en Java. Lorsqu'un contributeur de ladite API s'interroge à haute voix s'il ne faudrait pas accorder sa chance au monde hors JVM, il se heurte à un silence assourdissant.

Lors de mes premiers pas dans les ontologies, c'était enthousiasmant d'apprendre que l'on pourrait vérifier la cohérence d'une base de connaissances de façon complètement automatique, qu'on se permettrait de lâcher un moteur d'inférence sur un amas de triplets afin d'observer de la connaissance cachée émerger. Quelques temps après, déchanter n'était pas si difficile, ayant constaté, comme tant d'autres, qu'on passe surtout un temps non-négligeable à contourner les plus de 220 kilo-classes de l'API d'OWL pour la faire dialoguer correctement avec des outils souvent codés en C++. Finalement, le fait que WikiData décide de ne pas s'entêter dans cette direction n'est pas si paradoxal.

Pour parer à la traditionnelle rengaine du « code la fonctionnalité manquante par toi-même », j'admets tout de go mon incompétence. C'est dans ce sens que les efforts que font les personnes derrière WikiData sont vraiment admirables. D'ailleurs en tentant de jouer avec l'exemple de la dépêche à l'aide de quelques paquets codés en Haskell, on se rend compte de l'étendue du parcours que ces derniers ont encore à faire : le nœud RDF de WikiData est accessible en TLS, la page pointée par un http:// étant redirigée vers un https:// ; normal dirait-on, on est en 2017 après tout. Sauf que le paquet Haskell qui gère les nœuds RDF utilise actuellement une implémentation du HTTP qui date du début des années 2000 ne supportant pas le HTTPS. Le contournement que j'avais imaginé était de passer par DBpedia dont le nœud passe en HTTP mais son jeu de données ne semble pas englober tout WikiData. Ce qui m'amène à d'autres questions :
- au niveau de leurs backends, quelle est la différence entre WikiData et DBpedia ?
- on lit dans le texte que « [sur WikiData], on n'en est pas du tout » porté vers OWL et des inférences ; pourquoi alors le schéma du graphe de WikiData comporte des choses comme celles de l'extrait ici-bas ?
```
<vocabulary xmlns="http://rdfs.org/ns/void#" rdf:resource="http://www.w3.org/2002/07/owl"/>
<property xmlns="http://rdfs.org/ns/void#" rdf:resource="http://www.w3.org/2002/07/owl#sameAs"/>
<property xmlns="http://rdfs.org/ns/void#" rdf:resource="http://www.w3.org/2002/07/owl#complementOf"/>
<property xmlns="http://rdfs.org/ns/void#" rdf:resource="http://www.w3.org/2002/07/owl#onProperty"/>
<property xmlns="http://rdfs.org/ns/void#" rdf:resource="http://www.w3.org/2002/07/owl#someValuesFrom"/>
<property xmlns="http://rdfs.org/ns/void#" rdf:resource="http://www.w3.org/2002/07/owl#imports"/>
<class xmlns="http://rdfs.org/ns/void#" rdf:resource="http://www.w3.org/2002/07/owl#Restriction"/>
<class xmlns="http://rdfs.org/ns/void#" rdf:resource="http://www.w3.org/2002/07/owl#ObjectProperty"/>
<class xmlns="http://rdfs.org/ns/void#" rdf:resource="http://www.w3.org/2002/07/owl#DatatypeProperty"/>
<class xmlns="http://rdfs.org/ns/void#" rdf:resource="http://www.w3.org/2002/07/owl#Class"/>
<class xmlns="http://rdfs.org/ns/void#" rdf:resource="http://www.w3.org/2002/07/owl#Ontology"/>
```
Fin de l'aparté

Pour mémoire, la tentative en Haskell évoquée plus haut est celle-ci :
```
{-# LANGUAGE OverloadedStrings #-}

import Database.HSparql.Connection
import Database.HSparql.QueryGenerator

main :: IO ()
main = do
    (Just t) <- selectQuery "http://dbpedia.org/sparql" selectFatherless
    print t

selectFatherless :: Query SelectQuery
selectFatherless = do
    wdt <- prefix "wdt" (iriRef "http://www.wikidata.org/entity/")

    person  <- var
    father <- var
    concept <- var
    lang <- var

    -- Cette ligne retourne un graphe vide probablement parce que
    -- les arcanes de DBpedia diffèrent de celles de WikiData.
    -- S'il y avait eu des résultats, filtrer les nœuds blancs aurait été une formalité.
    -- _ <- triple person (wdt .:. "P22") father

    -- On se rabat sur cette ligne pour explorer la notion de « patternel » dans diverses langues.
    _ <- triple (wdt .:. "P22") concept lang

    -- L'exhaustivité n'est pas requise.
    limit 100

    return SelectQuery { queryVars = [concept, lang] }
```
Échantillon de sorties :
```
"Vater" "de"
"father" "en"
"その項目は主題に対し男性の親" "ja" -- Pour les amateurs du kan'ji qui postent de temps en temps ici.
…
"isä" "fi" -- Pour mupuf (voir http://www.mupuf.org/blog/2016/11/07/learning-finnish/)
…
"père" "fr"
…
"lien familial, parent direct de sexe masculin" "fr"
"male parent" "en"
…
"Papa" "fr"
…
```
Pour voir jusqu'où on peut aller avec des outils versatiles, se référer par exemple à Swish de G. Klyne dans cet article qui date, certes mais dont l'intuition est des plus actuelles.
1. Voir par exemple dans les archives ici, là ou là-bas. ↩
- [^] # Re: De l'art de râler
  
  Posté par Thomas Douillard le 04 janvier 2017 à 17:51. É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 :
  - 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.
  - [^] # Re: De l'art de râler
    
    Posté par gipoisson le 05 janvier 2017 à 10:37. Évalué à 1.
    
    O.K., je vois pourquoi vous ne voulez pas modéliser intensivement. Notons tout de même qu'il y a déjà une ontologie en place, elle est seulement embryonnaire.
    J'ai parcouru quelques pages de documentation à la recherche d'un document expliquant les choix des constructions OWL retenues pour WikiData, en vain. Aurais-tu des pointeurs ? Il y a les pages répertoriées ici mais elles ne parlent pas des choix déjàs faits et implémentés.
# du côté de la culture et des bibliothèques

Posté par Thierry Pasquier (site web personnel, Mastodon) le 03 janvier 2017 à 20:31. Évalué à 8.

Je vous invite à jeter un œil sur le dossier Créer du lien, faire sens - Un nouveau souffle sur les données dans la dernière livraison de la revue Arabesques, la revue de l'agence bibliographique de l’enseignement supérieur (ABES). L'ABES gère le catalogue collectif SUDOC comprenant 12 millions de notices bibliographiques accessibles en RDF.

La BnF expose une partie de ses données en RDF grâce à data.bnf.fr avec comme point d'accès sparql associé data.bnf.fr/sparql/.

Europeana (portail numérique du patrimoine européen, plus de 53 millions d’objets numériques issus de plus de 3300 institutions nationales : bibliothèques, archives, musées et fonds audiovisuels) propose aussi un point d'accès sparql.

Huma-Num, l'infrastructure des humanités numériques, propose aussi des ressources et des compétences aux labos dans ces domaines.

…