bientôt appli web avec formulaire générique

27 views
Skip to first unread message

Jean-Marc Vanel

unread,
Jun 25, 2014, 6:32:08 AM6/25/14
to deduct...@googlegroups.com
Jeudi dernier on a passé un moment  avec Alexandre Bertails, l'auteur de Banana-RDF.

Il n'a pas trouvé à redire à ce petit projet :

Pour l'instant ça génère un formulaire abstrait FA à partir d'une resource,
puis à partir de FA un formulaire XHTML via le DSL XML de Scala.


Je vais faire une appli. web avec Play! autour de ce petit générateur de formulaire.

Avec ces éléments à ajouter l'un après l'autre:

- 1. un serveur SPARQL 1.1 disponible ( BigData(R) )
- 2. on entre un URI et la vue formulaire s'affiche avec les infos du serveur SPARQL
- 3. les URI dans le formulaire peuvent être cliqués pour afficher un autre formulaire avec les infos du serveur SPARQL
- 4. entrer des nouveaux triplets, soit comme dans DataGUI  , soit comme
  dans Ontowiki : http://aksw.org/source/edit
- 5. introduire le cache RDF , la création d'un nouvel URI par sa classe comme dans DomainApplication ..... etc etc ...

A un moment donné il faudra aussi introduire à la place de FA un vocabulaire RDF pour les formulaires, peut-être réutilisant Fresnel ;
 voir:
( désolé, c'est pas formatté HTML )


Certains utilisent un mapping Objet - Sémantique,
souvent via JPA ( comme Empire).
C'est la même voie que prennent certains qui font du Play! avec MongoDB.

Mon option est ne pas écrire ( ou même générer ) des classes métiers en Scala.
Pourquoi ?

- ça ne sert à rien
- on a déjà les infos en RDF dans SPARQL et dans Banana-RDF
 - la modélisation Orientée objet est moins adaptée aux objets métier que RDF

Je peux développer ce dernier point ...

--
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

Benjamin Cogrel

unread,
Jul 17, 2014, 3:42:46 PM7/17/14
to deduct...@googlegroups.com
Bonjour Jean-Marc,

Désolé pour cette réponse tardive, j'ai été assez pris ces dernières semaines par mon installation en Italie.

Ce projet s'annonce très intéressant, il partage quelques aspects avec mon projet OldMan (https://github.com/oldm/OldMan) même si je ne me suis pas intéressé pour l'instant à la génération de formulaires.

Je suis désormais d'accord avec le fait de ne pas utiliser de classes métier côté programmation orientée objet, qu'elles soient générées dynamiquement ou non.

Le modèle de données de RDF est effectivement plus intéressant que celui de la programmation orientée objet. Selon moi, la principale limite introduite par cette dernière est la relation classe-instance qui est trop rigide. C'est ce qui m'a motivé, dans mon projet, à ne plus associer les classes RDFS à des classes Python.

Hormis l'aspect déclaratif de RDF, si tu vois d'autres limites à la programmation orientée objet, je serais ravi d'en savoir plus.

Il reste cependant au moins trois types de fonctionnalités qui, selon moi, doivent rester liées à une classe (ici RDFS) :

 1. La génération d'IRI pour les nouvelles instances de certaines classes RDFS.
 2. La gestion de noms courts au lieu d'IRIs en s'appuyant sur la notion de contexte dans JSON-LD.
 3. La validation.

Le point n°2 ne semble pas nécessaire pour ton cas d'usage où l'édition des ressources Web se fait dans un formulaire HTML. Cette fonctionnalité est par contre très appréciable lorsque l'on souhaite écrire des scripts. Avec des langages interprétés comme Python on peut même faire apparaître des attributs aux objets "Resource", ce qui est assez sympathique (on retrouve alors, à l'exécution, des objets métiers).

Ciao
Benjamin
--

---
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,
Jul 25, 2014, 4:20:52 AM7/25/14
to deduct...@googlegroups.com, benjami...@bcgl.fr
Merci Benjamin pour ces commentaires.


Maintenant la page sur le formulaires est formattée en  HTML:
http://htmlpreview.github.io/?https://github.com/jmvanel/semantic_forms/blob/master/doc/fr/formulaires.html

Elle a été complétée avec un liste de fonctionalités et un tableau fonctionalités - outils .
Evidemment , tout ça devrait être en RDF :) .

Je vais commencer une page sur OO versus RDF.
En attendant, voici des références:
En plus de ce que tu dis, il y a comme plus pour RDF :
- le fait que les propriétés soient "enfermées" dans les classes en OO,
  ce qui fait par exemple, que pour avoir une notion de couleur partagée par plusieurs classes, il faut en OO créer une classe objectColoré 

Voir aussi
Comparaison SQL - web sémantique

Le jeudi 17 juillet 2014 21:42:46 UTC+2, Benjamin Cogrel a écrit :
Bonjour Jean-Marc,

Désolé pour cette réponse tardive, j'ai été assez pris ces dernières semaines par mon installation en Italie.

Ce projet s'annonce très intéressant, il partage quelques aspects avec mon projet OldMan (https://github.com/oldm/OldMan) même si je ne me suis pas intéressé pour l'instant à la génération de formulaires.

Je suis désormais d'accord avec le fait de ne pas utiliser de classes métier côté programmation orientée objet, qu'elles soient générées dynamiquement ou non.

Le modèle de données de RDF est effectivement plus intéressant que celui de la programmation orientée objet. Selon moi, la principale limite introduite par cette dernière est la relation classe-instance qui est trop rigide. C'est ce qui m'a motivé, dans mon projet, à ne plus associer les classes RDFS à des classes Python.

Hormis l'aspect déclaratif de RDF, si tu vois d'autres limites à la programmation orientée objet, je serais ravi d'en savoir plus.

Il reste cependant au moins trois types de fonctionnalités qui, selon moi, doivent rester liées à une classe (ici RDFS) :

 1. La génération d'IRI pour les nouvelles instances de certaines classes RDFS.
 2. La gestion de noms courts au lieu d'IRIs en s'appuyant sur la notion de contexte dans JSON-LD.
 3. La validation.

Tout à fait d'accord, et c'est ce que fait DomainApp:
La validation pourrait être en language de règles comme N3.

Benjamin Cogrel

unread,
Jul 28, 2014, 5:15:33 PM7/28/14
to deduct...@googlegroups.com
Bonsoir,


Le 25/07/2014 10:20, Jean-Marc Vanel a écrit :
Merci Benjamin pour ces commentaires.


Maintenant la page sur le formulaires est formattée en  HTML:
http://htmlpreview.github.io/?https://github.com/jmvanel/semantic_forms/blob/master/doc/fr/formulaires.html

Elle a été complétée avec un liste de fonctionalités et un tableau fonctionalités - outils .
Evidemment , tout ça devrait être en RDF :) .

Ravi de voir que le sujet avance bien. Intéressant ce parallèle entre nœuds anonymes et suppression en cascade. Je me demande cependant comme étendre cette dernière à des ressources identifiées. Peut-être en me basant sur des propriétés requises, mais c'est peut-être excessif.


Je vais commencer une page sur OO versus RDF.
En attendant, voici des références:
Merci pour ces références, le tableau "Comparison of semantic modeling and object-oriented modeling" résume bien ces différences.


En plus de ce que tu dis, il y a comme plus pour RDF :
- le fait que les propriétés soient "enfermées" dans les classes en OO,
  ce qui fait par exemple, que pour avoir une notion de couleur partagée par plusieurs classes, il faut en OO créer une classe objectColoré
Je n'ai pas apporté de précision sur ce que j'entends par "relation classe-instance trop rigide" mais l'aspect que tu décris est très proche de cela. J'apprécie l'approche visant à associer autant que possible des propriétés à des classes dans le sens où si une ressource est instance d'une classe, on peut s'attendre à trouver occasionnellement certaines propriétés (par exemple dans Hydra, une hydra:Class a la propriété hydra:supportedProperty). Ce qui est bien dans RDF, c'est qu'une ressource peut être instance de nombreuses classes indépendantes, ce qui évite le problème que tu as cité.
C'est encore un autre sujet, lui aussi très intéressant. Pour ma part, j'ai envie de bien comprendre la contre-partie en matière de performance de l'aspect générique des triplestores qui font disparaître les contraintes apportées par les bases de données relationnelles et No-SQL. Je viens d'intégrer une équipe travaillant sur l'Ontology-Based Data Access (https://github.com/ontop/ontop), j'espère obtenir quelques éléments de réponse dans les mois à venir.

Benjamin

Jean-Marc Vanel

unread,
Aug 1, 2014, 6:30:14 AM8/1/14
to deduct...@googlegroups.com
Le mercredi 25 juin 2014 12:32:08 UTC+2, Jean-Marc Vanel a écrit :
ce petit projet :

Pour l'instant ça génère un formulaire abstrait FA à partir d'une resource,
puis à partir de FA un formulaire XHTML via le DSL XML de Scala.


J'ai fait une appli. web avec Play! autour de ce petit générateur de formulaire.
Avec ces éléments à ajouter l'un après l'autre:

- 1. un serveur SPARQL 1.1 disponible ( BigData(R) )
- 2. on entre un URI et la vue formulaire s'affiche avec les infos du serveur SPARQL
- 3. les URI dans le formulaire peuvent être cliqués pour afficher un autre formulaire avec les infos du serveur SPARQL
- 4. entrer des nouveaux triplets, soit comme dans DataGUI  , soit comme
  dans Ontowiki : http://aksw.org/source/edit
- 5. introduire le cache RDF , la création d'un nouvel URI par sa classe comme dans DomainApplication ..... etc etc ...

 
Les points 1, 2, 3 sont implémentés,
mais pas avec la base SPARQL embarquée (Jena TDB).
On télécharge juste les URI, s'ils sont en Turtle ou RDF/XML,
et on les met dans la base SPARQL embarquée,
avant de les afficher.

A noter qu'on utilise Play! Framework de façon minimaliste;
on n'utilise pas le composant Form.

A FAIRE en plus de ci-dessus:
  1. afficher les noeuds anonymes;
  2. recherche simple SPARQL d'une chaîne de caractère;
  3. téléchargement automatique des ontologies référencées;
  4. passer à BigData(R) comme base SPARQL embarquée;
  5. création d'une resource d'un certain type
  6. enregistrement des données du formulaire (pour l'instant formulaire en affichage seul)
  7. mise en ligne d'un fragment RDF ou d'un fichier;
  8. authentification minimale.

Si quelqu'un peut fournir un hébergement pour cette application ce serait formidable;
on pourrait bientôt l'utiliser comme stockage de FOAF par exemple.
Reply all
Reply to author
Forward
0 new messages