Antidot et Open Source : Pyckson

Antidot et l’Open Source

Antidot utilise pour le développement de ses produits beaucoup de logiciels Open Source. Et nous essayons, chaque fois que cela est possible, d’apporter en retour notre contribution à la communauté.

Open-SourceCela se fait sous forme de patches / pull request (nous proposons des correctifs qui sont intégrés au logiciel), d’éléments permettant d’enrichir nos plateformes (API, modules…) ou de logiciels autonomes (comme par exemple db2triples qui permet d’exploiter le contenu de bases de données relationnelles avec les technologies du Web Sémantique).

shutterstock_194620346

Il arrive que nos développeurs passionnés commencent sur leur temps personnel une brique technologique qui s’avère être particulièrement utile à notre travail. Nous encourageons alors cet effort et fournissons du temps et des ressources pour accompagner la finalisation d’une première version du projet et sa diffusion (par exemple lors de nos Brown Bags hebdomadaires)

La suite de ce billet de blog est rédigée par Jean Giard, développeur senior à la R&D d’Antidot, qui présente Pyckson, un outil permettant à un logiciel en Python d’importer / exporter facilement des objets en JSON.

Stéphane Loesel

PS – Vous retrouverez nos logiciels OpenSource sur le github d’Antidot à l’adresse :
https://github.com/Antidot

GitHub-Mark  GitHub-Logo

N’hésitez pas à utiliser notre code, le relire, nous poser des questions ou nous proposer des améliorations. Vous pouvez nous joindre à l’adresse [email protected]


Pyckson : un outil de mapping objet-JSON en python

Un peu d’histoire

Je travaille chez Antidot depuis plus de 5 ans, à ma sortie d’école.

J’ai travaillé pendant 4 ans en Python / C++ sur le moteur de recherche Antidot Finder Suite, où j’ai développé mes connaissances de bases en développement et méthodologie.

Il y a un an et demi je suis passé dans l’équipe qui travaille sur le produit Fluid Topics et développe en Java / Python. J’ai découvert tout un tas de nouveau design-pattern inaccessibles en Java : injection, orm, streams.

D’un autre coté je continuais à m’améliorer en Python mais un truc principal m’embêtait : sérialiser mes objets Python en JSON.

Alors qu’en Java tout avait l’air si simple avec un mix de Jackson / AutoValue, en Python je devais continuer à écrire des classes de sérialisation /désérialisation, ça ne pouvait plus durer !

Quelles solutions ?

J’ai cherché quelques temps si Python avait une librairie pour faire ce genre d’opérations mais je n’ai rien trouvé. Ce qui s’en rapprochait le plus était le module pickle mais il ne correspondait pas à mes principaux besoins :

  •  produire / lire du JSON « propre », i.e. sans contournement bizarre du genre insérer des infos pour parser l’objet
  •  du camelCase automatique pour respecter le coding-style Python tout en étant compatible avec le style des objects des web-services du serveur en Java
  •  la classe Python doit pouvoir être simple : rien d’autre qu’un constructeur et des attributs

Je me suis donc décidé à écrire ma propre librairie qui répondait a ce besoin : Pyckson

Principes de Pyckson

Pyckson fonctionne en introspectant les constructeurs des classes annotées et celles ci doivent correspondre à une structure bien particulière

  •  tous les paramètres doivent être annotés par leur type.
  •  les paramètres du constructeur doivent être assignés à des attributs du même nom.
  •  Pyckson camelCase automatiquement les noms des attributs pour la sérialisation.
  •  tous les attributs de type non primitif doivent aussi être annotés avec pyckson

Inconvénients

Bien entendu Python n’est pas aussi complet que Java en ce qui concerne le typage / l’introspection et on tombe vite sur quelques contraintes.

Les listes ne peuvent pas être typées, du coup Pyckson utilise une annotation supplémentaire pour indiquer le type du contenu d’une liste.

Les enum python3 ont un nom et une valeur, Pyckson utilise le nom de l’enum pour sérialiser, case sensitive par défaut.

Petits bonus

Pyckson utilise la librairie standard JSON et se charge de la transformation objet -> dictionnaire, du coup on peut aussi utiliser Pyckson pour faire du Yaml ou du Bson (avec MongoDB par exemple).

Pyckson supporte le fait d’utiliser une string pour typer un paramètre, par exemple pour définir une structure récursive.

Pyckson comprend qu’un paramètre est optionnel quand il a une valeur par défaut.

Exemple

Je définis mes objets en Python :

@pyckson
class Foo:
    def __init__(self, value: str):
        self.value = value

@pyckson
@listtype('my_foo_list', Foo)
class Bar:
    def __init__(self, my_foo_list: list):
        self.my_foo_list = my_foo_list

Puis j’appelle Pyckson :

:::python
foos = [Foo('first'), Foo('second')]
bar = Bar(foos)
print(serialize(bar))

> {"myFooList": [{"value": "first"}, {"value": "second"}]}

Lien vers le projet github : https://github.com/antidot/Pyckson

Voilà, vous savez tout sur Pyckson !

Jean Giard

Antidot publie la version 0.9.9 de db2triples

À la veille de WWW2012, la conférence mondiale consacrée aux technologies du web dont Antidot est un des sponsors, nous mettons à disposition de la communauté Open Source la version 0.9.9  de la bibliothèque db2triples. Cette nouvelle version apporte des évolutions majeures concernant le support des Candidate Recommendations des standards R2RML et Direct Mapping publiées le 23 février 2012 par le W3C.

R2RML et Direct Mapping : Candidate Recommendations du 23/02/2012

Parmi les améliorations figurent donc le support natif de MySQL et PostGreSQL ainsi que d’autres bases de données SQL via des pilotes JDBC, la gestion des types binaires (encodage base64), la prise en compte des caractères de langue spéciaux ainsi que le typage implicite des données et leur conversion selon la norme XML Schema du W3C, la gestion des formes canoniques des littéraux en fonction de leur type et de la casse des identifiants SQL. Pour la liste complète des évolutions, se reporter à la Release Note.

Le Linked Data opérationnel en entreprise

Cette nouvelle version de db2triples constitue une avancée majeure pour le web sémantique, et particulièrement pour la réalisation de projets exploitant les standards du Linked Data en entreprise. En effet, les technologies R2RML et Direct Mapping supportées par db2triples fournissent une réponse standardisée à la problématique de transformation des données relationnelles en graphes RDF pour le chargement automatique d’entrepôts.

Ainsi db2triples s’avère particulièrement intéressant dans le cadre de projet Open Data ou Linked Data nécessitant la publication dans le web des données d’informations vivantes, bien plus facilement réexploitables que la mise en ligne de fichiers Excel ou PDF dont la réutilisation automatique est complexe, voire impossible.

Mise à jour le 24 juillet 2012 : db2triples est pleinement compatible avec le Working Draft du 29 mai 2012 des recommandations R2RML et DirectMapping : en effet, db2triples a passé avec succès les tests de conformité édictés par le groupe de travail RDB2RDF du W3C. Du coup ce composant logiciel, fourni en Open Source, figure dans la liste des implémentations validées  par l’organisme international de normalisation du web. Plus d’information dans notre communiqué de presse diffusé ce jour, en français et en anglais.

Grande semaine pour l’Open Data français !

Cette première semaine de décembre 2011 aura marqué le vrai démarrage du mouvement Open Data en France, avec en l’espace de 3 jours une succession dense d’événements importants : lundi a eu lieu  le lancement par la mission Etalab, dirigée par Séverin Naudet,  de la plateforme officielle data.gouv.fr. Mardi soir se tenait la seconde édition des Data Tuesdays, qui montent en puissance et où Antidot était présente. Enfin mercredi a été ouverte la plateforme de réflexion collaborative de la SNCF data.sncf.com.

Chez Antidot, l’approche Open Data nous enthousiasme vraiment, car nous sommes convaincus que c’est le début d’un mouvement qui, en ouvrant les données publiques, va permettre à l’intelligence individuelle et collective des citoyens d’exprimer sa créativité.

Désormais, les données commencent à être publiées, et les standards, technologies et outils sont disponibles : et du coup, tout le monde va comprendre que l’Open Data n’est plus un problème de « comment faire« , mais bien de « que faire » et surtout « pourquoi le faire« .

Or le « que faire » et le « pourquoi le faire » peuvent justifier d’interconnecter des jeux de données issus de producteurs très différents, et de mailler des informations de nature très diverses pour les réutiliser d’une façon qui n’avait pas encore été imaginée. Et du coup, on en vient à considérer qu’il faut partager des données les plus brutes possibles, sans le filtre d’APIs qui présupposent des usages et en limitent d’autres. Espérer que des APIs propriétaires associées à chaque jeu de données vont être vraiment utiles est illusoire, pour une raison très simple : si, pour bâtir une application exploitant 13 jeux de données différents, il faut intégrer 13 APIs de fournisseurs différents, alors le résultat du développement sera un monstre totalement impossible à maintenir et à faire évoluer dans le temps, et donc au final inutile.

Il faut donc que les organisations qui se lancent dans l’Open Data publient des données non seulement ouvertes mais pleinement réutilisables : à cet égard, on ne saurait se contenter de proposer de sous forme d’une collection, aussi riche soit-elle, de fichiers XLS, PDF ou même CSV qui vont nécessiter beaucoup de travail pour que les données qu’ils renferment soient vraiment exploitées. Comme l’a dit fort justement Tim Berners-Lee à TED 2009 : « Raw data now! »

Le W3C a défini des standards pour l’accès aux données brutes, via l’approche du « web sémantique » ou « web des données » qui seul permet une réutilisation généralisée des données, par la mise en réseau massive des silos de données ouvertes où qu’ils se trouvent sur le web. 
Ces standards publiés par le W3C s’appellent RDF, OWL et  SPARQL. ils sont désormais matures et de nombreux outils existent pour les mettre en œuvre.

Nous considérons que la donnée brute en RDF, publiée dans le « nuage du Linked Open Data » ou « LOD cloud » est la seule vraie façon pérenne de permettre une réexploitation massive des données. Et nous ne sommes pas les seuls à le penser, si l’on en juge par la croissance formidable du LOD en l’espace de 4 ans : cliquez sur ces images de 2007, 2009 et 2011  pour les agrandir et mesurer la puissance de ce phénomène.



Pour découvrir l’approche ouverte du « web des données », nous vous conseillons le lire 3 billets de blog très pédagogiques écrits par notre collaborateur Gautier Poupeau, grand spécialiste du web des données et de l’Open Data. Vous pouvez aussi consulter les différentes présentations d’Antidot sur Slideshare.

Enfin, nous vous rappelons que  notre solution Antidot Information Factory (PDF – 4 pages) permet, de manière industrielle, de mailler très largement des données de provenance et de nature très diverses, de les exploiter et de les valoriser, notamment dans le cadre de projets Open Data ou Linked Data. Par ailleurs, nous avons publié en Open Source une bibliothèque en Java appelée db2triples qui simplifie la transformation en graphe RDF de données issues de bases de données relationnelles classiques. Nos solutions et notre expertise sont à votre disposition, n’hésitez pas à faire appel à nous dans le cadre d’un projet pilote ou d’un « proof of concept » !