Sémantisation de JSON avec Web Karma

80 views
Skip to first unread message

Jean-Marc Vanel

unread,
Mar 18, 2014, 6:52:09 AM3/18/14
to deduct...@googlegroups.com
Avec Karma Web, on peut plaquer un un modèle RDF sur du JSON, CSV, ou base SQL.
C'est mieux que DataLift, qui ne fait que SQL.
C'est une application Java Web versionnée dans Github, qui stocke dans une base de triplets Sesame (OpenRDF).
Le développeur principal répond aux issues sur GitHub.

J'ai pris comme exemple cette table des pharmaciens d'Ile de France:
On peut l'avoir en CSV aussi, mais Karma ne comprend pas les séparateurs points-virgules:

J'ai préchargé dans Karma ces vocabulaires:
ls -l --dereference preloaded-ontologies/
total 1244
-rw-rw-r-- 1 jmv jmv 1150363 oct. 14 21:16 dbpedia_3.9.owl
-rw-r--r-- 1 jmv jmv 17568 mars 17 13:17 dc.rdf
-rw-rw-r-- 1 jmv jmv 43191 nov. 9 2011 foaf.rdf
-rw-r--r-- 1 jmv jmv 48977 mars 17 13:19 sioc.rdf
-rw-r--r-- 1 jmv jmv 7866 mars 17 13:20 wgs84_pos.rdf

Ce qui est troublant au premier abord, c'est que dès qu'on a associé deux colonnes chacune à une propriété RDF et une classe OWL, alors il essaye de chapeauter ça avec une classe qui se veut une représentation de la table. Il utilise pour ça les domaines et les plages de valeurs (ranges) des propriétés. On obtient ceci, chapeauté par Island:

On doit alors annuler les deux associations de colonnes, et en choisir deux qui ont du sens. Heureusement dans l'ontologie dbPedia on trouve son bonheur. Une pharmacie peut raisonnablement correspondre à un cas particulier de dbo:Organization. Ensuite il est assez simple d'associer chaque colonne soit à City, soit à Organization. on peut même modéliser les dates de première autorisation et d'ouverture:

Ensuite, pour d'autres tables, on pourra capitaliser sur les classes et les propriétés qui ont déjà été associées à une colonne. Mais je n'ai pas encore testé.
A noter que Karma sauve ses associations dans un document R2RML, le standard pour la sémantisation des bases RDF.

Conclusion: un outils utile, et vu la quantité de JSON dans la nature on en a vraiment besoin.
Bien sûr, il y a pas mal d'imperfections dans l'IHM:
mais c'est assez utilisable après une période d'adaption d'un jour, et à condition de connaître suffisament les vocabulaires de base.
Mais aussi, vu la quantité de JSON disponible, on a besoin d'un agent plus intelligent, qui entre autres, analyse linguistiquement les noms des champs et les contenus.
De plus, Karma aide à appliquer des propriétés et des classes, mais ne propose rien pour lier les instances avec des URI existant ailleurs, ce qui est vraiment le but des LOD (Linked Open Data http://linkeddata.org/). Pour cela, je propose d'utiliser le lookup dbPedia (http://wiki.dbpedia.org/Lookup). Une entrée dans la colonne "comune", par exemple "BOURRON MARLOTTE", qui est associée au foaf:name d'une dbo:City via Karma, peut être via le lookup dbPedia associée de manière unique à l'URI:

grâce à la requête:

Cette fonctionalité devrait être implémentée de manière à être réutilisable dans DataGUI, dans Karma et ailleurs. Des tas de concepts sont présents dans dbPedia: Villes, personnages de tous types, chansons, espèces de plantes et d'animaux, oeuvres littéraires et autres, marques, etc. Bien sûr, il y a des cas où la solution n'est pas unique, même en indiquant QueryClass= dans la requête, comme Paris la ville: en France et aux USA. Dans ces cas, on pourrait utiliser un contexte RDF pour désambiguer.


--
Jean-Marc Vanel
Déductions SARL - Consulting, services, training,
Rule-based programming, Semantic Web
http://deductions-software.com/
+33 (0)6 89 16 29 52
Twitter: @jmvanel , @jmvanel_fr ; chat: irc://irc.freenode.net#eulergui

Jean-Marc Vanel

unread,
Mar 20, 2014, 11:57:14 AM3/20/14
to deduct...@googlegroups.com
A l'usage c'est lent à chaque association de colonne,
et surtout la quantité de mémoire utilisée (6Go) pour un JSON de 50 ko rend l'application inutilisable.
Dommage!
Mais c'est en maintenance active,
et je ne manque pas de leur mettre des issues GitHub.
A SUIVRE!

Cyril Hansen

unread,
Mar 24, 2014, 7:14:13 AM3/24/14
to deduct...@googlegroups.com
Sur ce sujet de la manipulation de JSON, je voulais indiquer que je viens de lire sur hacker news que Postgresql avait récemment intégré la gestion de données semi-structurées via JSON.

https://news.ycombinator.com/item?id=7457197

Votre dernière remarque sur les problèmes de performance des outils étiquetés "web sémantique" me pousse plutôt au compromis technique vers des outils plus traditionnels et validés en production.... En 2000, les web services en XML ont bien démarré sans pile XML complète avec les moyens du bord...




--

---
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "Déductions et EulerGUI en Français".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse deductions-f...@googlegroups.com.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

Jean-Marc Vanel

unread,
Mar 24, 2014, 7:55:33 AM3/24/14
to deduct...@googlegroups.com
Le 24 mars 2014 12:14, Cyril Hansen <cyril....@gmail.com> a écrit :
Sur ce sujet de la manipulation de JSON, je voulais indiquer que je viens de lire sur hacker news que Postgresql avait récemment intégré la gestion de données semi-structurées via JSON.

https://news.ycombinator.com/item?id=7457197

Merci pour la nouvelle.

Mais ne pas aimer JSON ce n'est pas à la mode, mais ça ne veut pas dire qu'on a tort.
JSON est la mouture moderne de XML, et à les mêmes défauts:

- accent mis sur la structure, et non sur la sémantique
- pas possible de concaténer 2 XML ou 2 JSON
- pas d'identifiants globaux comme les URI, donc difficultés pour croiser les données.


Votre dernière remarque sur les problèmes de performance des outils étiquetés "web sémantique" me pousse plutôt au compromis technique vers des outils plus traditionnels et validés en production....

Quelle remarque ?

SQL c'est un vieux truc qui date de bien avant le Web:
- 1. les protocoles réseaux ne sont pas standardisés
- 2. le SQL , bien que standardisé, en pratique a de nombreux dialectes;
- 3. SQL induit des mauvaises pratiques par sa rigidité excessive: clés étrangères non déclarées parce ça complique la programmation, colonnes ayant des données structurées, colonnes fourre tout
- 4. peu adapté à l'orienté objet, d'où l'usage de ORM qui complique beaucoup et pose des problèmes de performance et de maintenance
- 5. le langage de déclaration du schema est différent du langage pour les données

Le NoSQL, c'est un monde où il n'y a aucun standard.

Au contraire, avec SPARQL :
 1. les protocoles réseaux ne sont parfaitement standardisés
- 2. le langage SPARQL est standardisé par le W3C, y compris les mises à jour de la base
- 3. le web sémantique encourage les bonnes pratiques:
  * réutilisation de vocabulaires et de données
  * flexibilité mais qui n'empêche pas une sémantique rigoureuse des ontologies et des inférences attendues
- 4. adapté à l'orienté objet, les notions de classe, de sous-classe, et même de sous-propriété existent; l'usage de O-S Mapping est possible, mais on peut mapiuler diretment les triplets
- 5. le langage de déclaration du schema est RDF, le même que pour les données
- 6. les transactions et les triggers existent, mais je ne sais s'il y a un standard 

Et, grâce aux points 1 et 2, on a une réelle facilité à changer de fournisseur, et un large choix de bases de données:
Open Source:
- Jena TDB et SDB
- OpenRDF (alias Sesame)
- BigData
- Mulgara
- Virtuoso
Commerciaux:
- Oracle
- IBM
- Exalead

Jean-Marc Vanel

unread,
Mar 24, 2014, 8:12:36 AM3/24/14
to deduct...@googlegroups.com
Pardon, je relis ma remarque sur Karma Web;
clairement c'est un outil en attente de maintenance,
ça ne remet pas en cause le Web Sémantique.
J'attend que l'équipe s'en occupe; leur dernier commit a carrément cassé le truc; je remarque que c'est basé sur Sesame; moi j'utilise plutôt Jena.

Pas plus que les problèmes sur dbPedia propulsé par Virtuoso ne 
remettent en cause le Web Sémantique. Il y a des arrêts très fréquents pour maintenance, alors même que les données sont figées sur 
( mais pas sur live.dbpedia.org/sparql )
Je ne sais pas si c'est Virtuoso (un truc semi open source et basé sur du relationnel ), ou si la machine n'est pas dimensionnée au trafic, ou un pb d'administration .
C'est clairement un problème pour la communauté, mais il suffi d'avoir un mirroir dbPedia local pour un site en production; voir la recette ici:


J'ai oublié de dire aussi que des organisations de taille conséquente se tournent vers le Web Sémantique dans une démarche d'urbanisation et de MDM (master data management).

Reply all
Reply to author
Forward
0 new messages