Support de la communication effectuée pour la conférence "Web version 2 et les suivantes", Solution Linux 2009

1. L’apport des technologies du Web sémantique à la gestion des données structurées Alexandre Bertails - Gautier Poupeau Atos Origin, 31 mars 2009

2. Sommaire Les technologies du Web sémantique par la pratique À la recherche d’un modèle de données souple et universel Les limites du modèle relationnel

3. Les limites du modèle relationnel Voici un modèle relationnel classique décrivant les JO : Analysons les problèmes qu’ils posent NULL 241 NULL 1896/04/15 1896/04/06 1896 1 1 One World one Dream 11028 1 2008/08/24 2008/08/08 2008 2 2 motto athletes Number id athletes Representant closed Ceremony Date opened Ceremony Date year id ville id 116.400002 23.716667 longitude 39.900002 Beijing Pékin 2 37.966667 Athens Athènes 1 latitude label-en label-fr idville 張怡寧 label-cn 1981/10/05 birth Date NULL Zhang Yining Zhang Yining 1 death Date label-en label-fr id athlete

4. Les limites du relationnel (1) : la structure des données 1- Séparation entre la structure des données et les données elles-mêmes NULL 241 NULL 1896/04/15 1896/04/06 1896 1 1 One World one Dream 11028 1 2008/08/24 2008/08/08 2008 2 2 motto athletes Number id athletes Representant closed Ceremony Date opened Ceremony Date year id ville id 116.400002 23.716667 longitude 39.900002 Beijing Pékin 2 37.966667 Athens Athènes 1 latitude label-en label-fr idville 張怡寧 label-cn 1981/10/05 birth Date NULL Zhang Yining Zhang Yining 1 death Date label-en label-fr id athlete

5. Les limites du relationnel (1) : la structure des données 1- Séparation entre la structure des données et les données elles-mêmes Si on extrait les données de la base, il faut aussi en extraire la structure pour comprendre à quoi correspond chacune des données NULL 241 NULL 1896/04/15 1896/04/06 1896 1 1 One World one Dream 11028 1 2008/08/24 2008/08/08 2008 2 2 motto athletes Number id athletes Representant closed Ceremony Date opened Ceremony Date year id ville id 116.400002 23.716667 longitude 39.900002 Beijing Pékin 2 37.966667 Athens Athènes 1 latitude label-en label-fr idville 張怡寧 label-cn 1981/10/05 birth Date NULL Zhang Yining Zhang Yining 1 death Date label-en label-fr id athlete

6. Les limites du relationnel (1) : la structure des données 1- Séparation entre la structure des données et les données elles-mêmes Une donnée s’applique à un enregistrement car elle est associée à un champ. La relation est induite par la structure de la table. NULL 241 NULL 1896/04/15 1896/04/06 1896 1 1 One World one Dream 11028 1 2008/08/24 2008/08/08 2008 2 2 motto athletes Number id athletes Representant closed Ceremony Date opened Ceremony Date year id ville id 116.400002 23.716667 longitude 39.900002 Beijing Pékin 2 37.966667 Athens Athènes 1 latitude label-en label-fr idville 張怡寧 label-cn 1981/10/05 birth Date NULL Zhang Yining Zhang Yining 1 death Date label-en label-fr id athlete

7. Les limites du relationnel (1) : la structure des données 1- Séparation entre la structure des données et les données elles-mêmes Les données ne sont pas indépendantes les unes des autres. Elles se conçoivent dans le contexte de la base, d’un enregistrement et d’un champ. NULL 241 NULL 1896/04/15 1896/04/06 1896 1 1 One World one Dream 11028 1 2008/08/24 2008/08/08 2008 2 2 motto athletes Number id athletes Representant closed Ceremony Date opened Ceremony Date year id ville id 116.400002 23.716667 longitude 39.900002 Beijing Pékin 2 37.966667 Athens Athènes 1 latitude label-en label-fr idville 張怡寧 label-cn 1981/10/05 birth Date NULL Zhang Yining Zhang Yining 1 death Date label-en label-fr id athlete

8. Les limites du relationnel (1) : la structure des données 2- La structure d’une base de données est rigide NULL 241 NULL 1896/04/15 1896/04/06 1896 1 1 One World one Dream 11028 1 2008/08/24 2008/08/08 2008 2 2 motto athletes Number id athletes Representant closed Ceremony Date opened Ceremony Date year id ville id 116.400002 23.716667 longitude 39.900002 Beijing Pékin 2 37.966667 Athens Athènes 1 latitude label-en label-fr idville 張怡寧 label-cn 1981/10/05 birth Date NULL Zhang Yining Zhang Yining 1 death Date label-en label-fr id athlete

9. Les limites du relationnel (1) : la structure des données 2- La structure d’une base de données est rigide Si une donnée est manquante pour un champ dans un enregistrement, une valeur « NULL » fictive est ajoutée. NULL 241 NULL 1896/04/15 1896/04/06 1896 1 1 One World one Dream 11028 1 2008/08/24 2008/08/08 2008 2 2 motto athletes Number id athletes Representant closed Ceremony Date opened Ceremony Date year id ville id 116.400002 23.716667 longitude 39.900002 Beijing Pékin 2 37.966667 Athens Athènes 1 latitude label-en label-fr idville 張怡寧 label-ja 1981/10/05 birth Date NULL Zhang Yining Zhang Yining 1 death Date label-en label-fr id athlete

10. Les limites du relationnel (1) : la structure des données 2- La structure d’une base de données est rigide Si une donnée de même nature est en double pour un enregistrement (même pour un seul), il est nécessaire de créer un autre champ ou ... 2 NULL id athletes Representant2 NULL 241 NULL 1896/04/15 1896/04/06 1896 1 1 One World one Dream 11028 1 2008/08/24 2008/08/08 2008 2 2 motto athletes Number id athletes Representant closed Ceremony Date opened Ceremony Date year id ville id NULL NULL NULL Toto Toto 2 張怡寧 label-ja 1981/10/05 birth Date NULL Zhang Yining Zhang Yining 1 death Date label-en label-fr id athlete 116.400002 23.716667 longitude 39.900002 Beijing Pékin 2 37.966667 Athens Athènes 1 latitude label-en label-fr idville

11. Les limites du relationnel (1) : la structure des données 2- La structure d’une base de données est rigide … ou une autre table… NULL 241 1896/04/15 1896/04/06 1896 1 1 One World one Dream 11028 2008/08/24 2008/08/08 2008 2 2 motto athletes Number closed Ceremony Date opened Ceremony Date year id ville id NULL NULL NULL Toto Toto 2 張怡寧 label-ja 1981/10/05 birth Date NULL Zhang Yining Zhang Yining 1 death Date label-en label-fr id athlete 2 2 1 2 idAthleteRepresentant idjo

12. Les limites du relationnel (1) : la structure des données 2- La structure d’une base de données est rigide Pour gérer le multilinguisme, il faut créer de champs correspondant à chacune des langues, alors que la signification du champ est exactement la même ou créer une table spécifique. NULL 241 NULL 1896/04/15 1896/04/06 1896 1 1 One World one Dream 11028 1 2008/08/24 2008/08/08 2008 2 2 motto athletes Number id athletes Representant closed Ceremony Date opened Ceremony Date year id ville id 北京市 NULL label-ja 116.400002 23.716667 longitude 39.900002 Beijing Pékin 2 37.966667 Athens Athènes 1 latitude label-en label-fr idville 張怡寧 label-ja 1981/10/05 birth Date NULL Zhang Yining Zhang Yining 1 death Date label-en label-fr id athlete

13. Les limites du relationnel (1) : la structure des données 3- Les relations entre deux tables sont induites NULL 241 NULL 1896/04/15 1896/04/06 1896 1 1 One World one Dream 11028 1 2008/08/24 2008/08/08 2008 2 2 motto athletes Number id athletes Representant closed Ceremony Date opened Ceremony Date year id ville id 116.400002 23.716667 longitude 39.900002 Beijing Pékin 2 37.966667 Athens Athènes 1 latitude label-en label-fr idville 張怡寧 label-ja 1981/10/05 birth Date NULL Zhang Yining Zhang Yining 1 death Date label-en label-fr id athlete

14. Les limites du relationnel (1) : la structure des données 3- Les relations entre deux tables sont induites La relation entre les données de deux tables est induite par l’utilisation d’identifiants communs dites clés étrangères. La nature de la relation n’est pas exprimée clairement ni dans la structure, ni dans la donnée. NULL 241 NULL 1896/04/15 1896/04/06 1896 1 1 One World one Dream 11028 1 2008/08/24 2008/08/08 2008 2 2 motto athletes Number id athletes Representant closed Ceremony Date opened Ceremony Date year id ville id 116.400002 23.716667 longitude 39.900002 Beijing Pékin 2 37.966667 Athens Athènes 1 latitude label-en label-fr idville 張怡寧 label-ja 1981/10/05 birth Date NULL Zhang Yining Zhang Yining 1 death Date label-en label-fr id athlete

15. Les limites du relationnel (1) : la structure des données 3- Les relations entre deux tables sont induites L’extraction d’une base de données ne met pas en lumière ces relations. Il faut extraire les données des différentes tables pour conserver la relation. NULL 241 NULL 1896/04/15 1896/04/06 1896 1 1 One World one Dream 11028 1 2008/08/24 2008/08/08 2008 2 2 motto athletes Number id athletes Representant closed Ceremony Date opened Ceremony Date year id ville id 116.400002 23.716667 longitude 39.900002 Beijing Pékin 2 37.966667 Athens Athènes 1 latitude label-en label-fr idville 張怡寧 label-ja 1981/10/05 birth Date NULL Zhang Yining Zhang Yining 1 death Date label-en label-fr id athlete

16. Les limites du relationnel (1) : la structure des données 4- L’identifiant d’un enregistrement est une donnée comme les autres NULL 241 NULL 1896/04/15 1896/04/06 1896 1 1 One World one Dream 11028 1 2008/08/24 2008/08/08 2008 2 2 motto athletes Number id athletes Representant closed Ceremony Date opened Ceremony Date year id ville id 116.400002 23.716667 longitude 39.900002 Beijing Pékin 2 37.966667 Athens Athènes 1 latitude label-en label-fr idville 張怡寧 label-cn 1981/10/05 birth Date NULL Zhang Yining Zhang Yining 1 death Date label-en label-fr id athlete

17. Les limites du relationnel (1) : la structure des données 4- L’identifiant d’un enregistrement est une donnée comme les autres L’identifiant d’un enregistrement n’a pas une forme normalisée. Il est dépendant de la base voire de la table (donc de la structure). NULL 241 NULL 1896/04/15 1896/04/06 1896 1 1 One World one Dream 11028 1 2008/08/24 2008/08/08 2008 2 2 motto athletes Number id athletes Representant closed Ceremony Date opened Ceremony Date year id ville id 116.400002 23.716667 longitude 39.900002 Beijing Pékin 2 37.966667 Athens Athènes 1 latitude label-en label-fr idville 張怡寧 label-cn 1981/10/05 birth Date NULL Zhang Yining Zhang Yining 1 death Date label-en label-fr id athlete

18. Les limites du relationnel (1) : la structure des données Résumons-nous : Le modèle relationnel impose une structure rigide, difficile à faire évoluer et indépendante des données elles-mêmes . Il induit les relations et n’offre pas un système claire d’identifiants.

19. Les limites du relationnel (2) : l’interopérabilité des données 1- Les identifiants sont locaux et spécifiques à une base de données Il n’est pas possible d’identifier nativement deux ressources équivalentes entre deux bases de données différentes. NULL 241 NULL 1896/04/15 1896/04/06 1896 1 1 One World one Dream 11028 1 2008/08/24 2008/08/08 2008 2 2 motto athletes Number id athletes Representant closed Ceremony Date opened Ceremony Date year id ville id Beijing Pékin 2 Athens Athènes 1 label-en label-fr idville 張怡寧 label-cn 1981/10/05 birth Date NULL Zhang Yining Zhang Yining 1 death Date label-en label-fr id athlete 39.900002 116.400002 beta 37.966667 23.716667 alpha latitude longitude idville

20. Les limites du relationnel (2) : l’interopérabilité des données 2- Les noms des champs sont spécifiques à une base de données La structure d’une base de données est locale. Il n’existe pas de normes pour dénommer les propriétés et les rattacher à une normalisation de tel ou tel type de données. NULL 241 NULL 1896/04/15 1896/04/06 1896 1 1 One World one Dream 11028 1 2008/08/24 2008/08/08 2008 2 2 motto athletes Number id athletes Representant closed Ceremony Date opened Ceremony Date year id ville id Beijing Pékin 2 Athens Athènes 1 label-en label-fr idville 張怡寧 label-cn 1981/10/05 birth Date NULL Zhang Yining Zhang Yining 1 death Date label-en label-fr id athlete Pékin Athènes name 39.900002 116.400002 beta 37.966667 23.716667 alpha latitude longitude idcity

21. Les limites du relationnel (2) : l’interopérabilité des données 3- La structure d’une base ne s’appuie sur aucun mécanisme d’héritages Il n’est pas possible de relier une table à un modèle générique de description local ou externe dont il peut hériter les caractéristiques ce qui impose de construire un MCD à zéro ou presque. La table athlete une spécialisation de description d’une personne ? La table JO une spécialisation de description d’un événement ? NULL 241 NULL 1896/04/15 1896/04/06 1896 1 1 One World one Dream 11028 1 2008/08/24 2008/08/08 2008 2 2 motto athletes Number id athletes Representant closed Ceremony Date opened Ceremony Date year id ville id Beijing Pékin 2 Athens Athènes 1 label-en label-fr idville 張怡寧 label-cn 1981/10/05 birth Date NULL Zhang Yining Zhang Yining 1 death Date label-en label-fr id athlete Pékin Athènes name 39.900002 116.400002 beta 37.966667 23.716667 alpha latitude longitude idcity

22. Les limites du relationnel (2) : l’interopérabilité des données 4- Il n’existe aucune représentation normalisée pour échanger des BDR sur un réseau. L’extraction d’une base de données est spécifique pour chaque base, il n’existe aucune syntaxe normalisée pour échanger les données d’une base et les fusionner avec une autre base. NULL 241 NULL 1896/04/15 1896/04/06 1896 1 1 One World one Dream 11028 1 2008/08/24 2008/08/08 2008 2 2 motto athletes Number id athletes Representant closed Ceremony Date opened Ceremony Date year id ville id Beijing Pékin 2 Athens Athènes 1 label-en label-fr idville 張怡寧 label-cn 1981/10/05 birth Date NULL Zhang Yining Zhang Yining 1 death Date label-en label-fr id athlete Pékin Athènes name 39.900002 116.400002 beta 37.966667 23.716667 alpha latitude longitude idcity

23. Les limites du relationnel (2) : l’interopérabilité des données 5- Il n’existe aucun moyen normalisé de requêter directement une BDR sur le Web. L’extraction d’une base de données est spécifique pour chaque base, il n’existe aucune syntaxe normalisée pour échanger les données d’une base et les fusionner avec une autre base. NULL 241 NULL 1896/04/15 1896/04/06 1896 1 1 One World one Dream 11028 1 2008/08/24 2008/08/08 2008 2 2 motto athletes Number id athletes Representant closed Ceremony Date opened Ceremony Date year id ville id Beijing Pékin 2 Athens Athènes 1 label-en label-fr idville 張怡寧 label-cn 1981/10/05 birth Date NULL Zhang Yining Zhang Yining 1 death Date label-en label-fr id athlete Pékin Athènes name 39.900002 116.400002 beta 37.966667 23.716667 alpha latitude longitude idcity

24. Les limites du relationnel (1) : la structure des données Résumons-nous : Le modèle relationnel est un modèle centralisé . Il ne gère pas nativement l’interopérabilité entre différentes bases de données réparties sur un réseau.

25. Sommaire Les technologies du Web sémantique par la pratique À la recherche d’un modèle de données souple et universel Les limites du modèle relationnel

26. A la recherche d’un modèle de données souple et universel Question : Quels seraient les caractéristiques d’un modèle de données répondant aux limites du relationnel ? Il devra être souple , universel et compatible avec le fonctionnement du Web.

27. Identifier et localiser les ressources Besoin L’item décrit doit posséder un identifiant unique , pérenne et universel et doit être localisé sur un réseau . 116.400002 23.716667 longitude 39.900002 Beijing Pékin 2 37.966667 Athens Athènes 1 latitude label-en label-fr idville

28. Identifier et localiser les ressources Solution Attribuer à chaque item une URI (Uniform Resource Identifier), c’est-à-dire en faire une ressource. Conséquence L’identifiant d’une ressource n’est pas une donnée. Il est le point d’entrée vers la description de la ressource. 116.400002 23.716667 longitude 39.900002 Beijing Pékin http://dbpedia.org/resource/Beijing 37.966667 Athens Athènes http://dbpedia.org/resource/Athens latitude label-en label-fr

29. Exprimer clairement les attributs et les propriétés Besoin Exprimer clairement les relations entre la ressource décrite et une donnée… … ou une autre ressource 23.716667 longitude 37.966667 Athènes http://dbpedia.org/resource/Athens latitude label-fr NULL 1896/04/15 1896/04/06 1896 http://dbpedia.org/resource/Athens http://linkedsportdb.org/resource/1234 motto closed Ceremony Date opened Ceremony Date year id ville

30. Exprimer clairement les attributs et les propriétés Solution Décrire les données selon la logique des prédicats du premier ordre, c’est-à-dire sous la forme de triplets ou de phrase simple, SUJET – PREDICAT – OBJET <http://dbpedia.org/resource/Athens> <label> « Athènes »@fr <http://dbpedia.org/resource/Athens> <longitude> « 23.716667 »^^float Conséquence Chaque triplet est indépendant ; une propriété peut être répétable pour une même ressource ; une valeur qui n’existe pas ne fait pas l’objet d’un triplet.

31. Exprimer clairement les attributs et les propriétés Solution Décrire les relations entre les ressources sous la forme de graphe http://dbpedia.org/resource/1896_Summer_Olympics http://dbpedia.org/resource/Athens http://purl.org/NET/c4dm/event.owl#place Conséquence La structure des données fait partie de la donnée elle-même ; chaque membre du triplet est identifiable par une URI et est donc une ressource.

32. Une syntaxe normalisée pour décrire les données Besoin Disposer d’une syntaxe normalisée pour décrire les données de manière indépendante d’un environnement matériel ou logiciel Solution Utiliser la syntaxe XML <dbpedia:city rdf:about=&quot; http://dbpedia.org/resource/Athens &quot;> < rdfs:label xml:lang=&quot;fr&quot;> Athènes </rdfs:label> </dbpedia:city>

33. À la recherche d’un modèle de données souple et universel Résumons-nous Des URIs pour identifier Des triplets pour décrire Des graphes pour relier Une syntaxe normalisée pour écrire Ce modèle n’est ni plus ni moins que le modèle R D F , R essource D escription F ramework, à la base du Web sémantique

34. Décrire les ressources Besoin Égalité sur des concepts http://dbpedia.org/resource/1896_Summer_Olympics http://dbpedia.org/resource/Athens http://purl.org/NET/c4dm/event.owl#place http://linkedsportdb.org/resource/2e13d6c1 1896 atYear ?

35. Décrire les ressources Solution Se mettre d’accord sur une propriété particulière : sameAs http://dbpedia.org/resource/1896_Summer_Olympics http://dbpedia.org/resource/Athens http://purl.org/NET/c4dm/event.owl#place http://linkedsportdb.org/resource/2e13d6c1 1896 sameAs atYear

36. Décrire les ressources Besoin Décrire les types de ressources et les propriétés http://linkedsportdb.org/resource/2e13d6c1 1896 atYear WinterOlympicGames type

38. Décrire les ressources Résumons-nous Il suffit de se mettre d’accord pour décrire les ressources et les relations avec un vocabulaire commun. Ça existe déjà ! OWL - W eb O ntology L anguage owl:Class rdfs:property rdfs:subPropertyOf rdfs:domain … owl:equivalentClass equivalent:Property owl:sameAs … owl:ObjectProperty owl:DatatypeProperty owl:inverseOf … owl:Restriction owl:someValuesFrom owl:allValuesFrom …

39. Interroger les données Besoin Requêter des données Solution Exprimer des patterns de graphes Exprimer des phrases SUJET – PREDICAT – OBJET à trous S PARQL P rotocol a nd R DF Q uery L anguage

40. Interroger les données 1 2 3 4 5 6 7 8 Soit le graphe suivant enregistré dans une base de données RDF (un triple store) : SPARQL permet d’extraire un sous-ensemble de ce graphe par l’expression de contraintes sous la forme d’équations Je cherche les ressources liées à 1 par prédicat « rouge » et la chaîne de caractères liée à ces ressources par le prédicat « bleu » : X Y Exemple : 1. Les ressources liées à 1 par le prédicat « rouge » (<1> <rouge> ?resources) 2. La chaîne de caractères liée à ces ressources par le prédicat « bleu » (?resources <bleu> ?string)

41. Interroger les données Dans dbpedia.org, je veux connaître l’URI et le lieu des JO de 1928 : Les JO de 1928 se déroulent à un endroit un endroit a pour nom ??? . SELECT ?place ?placename WHERE { <http://dbpedia.org/resource/1928_Winter_Olympics> property:hostCity ?place . ?place rdfs:label ?placename . }

42. Sommaire Les technologies du Web Sémantique en pratique À la recherche d’un modèle de données souple et universel Les limites du modèle relationnel

44. De l’Open Source à l’Open Data : Linking Open Data Communauty Project

45. Apports du SemWeb à l’évolution de l’architecture du SI B A Silos applicatifs indépendants et non connectés B A Silos de services Indépendance des trois niveaux (applicatif, service, données) Les technos du semWeb le permettent

46. Contraintes d’intégrité (2) athlete:David_Douillet sport:medal medal:Silver Question : Le triplet suivant peut-il être exprimé ? <owl:ObjectProperty rdf:about=&quot; sport:medal &quot;> < rdfs:range rdf:resource=&quot; Medal &quot;/> </owl:ObjectProperty> <owl:Class rdf:about=&quot; Medal &quot;> < owl:oneOf rdf:parseType=&quot; Collection &quot;> <owl:Thing rdf:about=&quot;#Gold&quot;/> <owl:Thing rdf:about=&quot;#Silver&quot;/> <owl:Thing rdf:about=&quot;#Bronze&quot;/> </owl:oneOf> </owl:Class> Soit l’ontologie suivante : Oui, car la ressource medal:Silver est une ressource possible de la classe Medal, même si ce triplet est faux du point de vue de la réalité.

47. Contraintes d’intégrité (1) athlete:Gautier_Poupeau sport:medal medal:Chocolate Question : Le triplet suivant peut-il être exprimé ? <owl:ObjectProperty rdf:about=&quot; sport:medal &quot;> < rdfs:range rdf:resource=&quot; Medal &quot;/> </owl:ObjectProperty> <owl:Class rdf:about=&quot; Medal &quot;> < owl:oneOf rdf:parseType=&quot; Collection &quot;> <owl:Thing rdf:about=&quot;#Gold&quot;/> <owl:Thing rdf:about=&quot;#Silver&quot;/> <owl:Thing rdf:about=&quot;#Bronze&quot;/> </owl:oneOf> </owl:Class> Soit l’ontologie suivante : Non, car la ressource medal:Chocolate n’est pas une ressource possible de la classe Medal.

50. Questions / Réponses Merci pour votre attention ! Alexandre Bertails, [email_address] Gautier Poupeau, [email_address]