Début 2010, pour répondre à une directive européenne, Renault mettait en oper sa première application basée sur les techniques du semantic web : un système de publication des documents et données de sa documentation technique après-vente, en charge d’alimenter un site web à destination des réparateurs indépendants. Aujourd'hui, on veut faire évoluer la solution, pour prendre en compte de nouvelles sources de données, et élargir son audience. La solution initiale peut-elle évoluer facilement ? est-elle scalable et supportera-t-elle un important surcroit de charge ? Certains parlent d’un échec du Semantic Web : les choix techniques faits se sont-ils révélés pertinents ? Que ferait-on différemment aujourd'hui ? Cinq années ont passé : de nouvelles techniques sont apparues (JSON-LD, par exemple), d'autres ont mûri (Solr), JSON et javascript sont devenus incontournables. Ce qui faisait défaut est-il maintenant disponible ? Par exemple, comment intégrer les formulaires (ou les templates d’URI) dans une API basée sur les Linked Data ? (alors que le web repose à la fois sur les liens hypertextes et les formulaires, les linked data ne connaissent que les liens) Après avoir expliqué la particularité de la recherche documentaire dans le contexte automobile (qui fait nécessairement sortir du cadre du modèle relationnel - et donc de SPARQL - pour l’évaluation de la pertinence d’un document en fonction du véhicule auquel on s’intéresse), nous reviendrons brièvement sur ce qui avait fait le succès de la solution initiale - en particulier, les capacités d’agrégation de RDF, qui avaient permis de réconcilier facilement des données de sources variées. Nous dirons ce que nous avons abandonné - pour faire bref, disons que SPARQL n’est plus aussi central dans la solution, ou du moins qu’il n’en est plus le seul cœur. Mais surtout, nous verrons comment il a été possible de modifier assez profondément l'architecture initiale en intégrant des techniques nouvelles et en s’inspirant d’idées récentes (“Hypermedia driven web APIs”, Hydra, JSON-LD, web components, etc). Nous verrons aussi quelques limites ou promesses pas complètement tenues par les techniques en œuvre. Nous ferons la démonstration d’un prototype d’IHM en javascript construite sur la solution, montrant une recherche documentaire complexe, entièrement guidée par les données, avec un minimum de couplage entre serveur et client. Par François-Paul Servant.

1. Évolution d’un système de publication de données
techniques automobiles, modélisées en RDF
François-Paul Servant francois-paul.servant@renault.com
SemWeb.Pro 2015

2. SemWeb.pro 2015
! Début 2010 :
! mise en oper d’un système de publication des données et documents de la doc
technique APV Renault
! basé sur les technologies “semantic web”
! mi 2015 :
! coût pour supporter de nouvelles sources de données ?
! scalabilité ?
2

3. SemWeb.pro 2015 3
Sélection
du véhicule (VIN)
Recherche : entité, code défaut,
symptôme…

4. SemWeb.pro 2015 4
Liste des “documents”
pour l’entité “filtre à air”
(pour le véhicule considéré)

5. SemWeb.pro 2015 5
Procédure de diagnostic
lien vers
Manuel de Réparation

6. SemWeb.pro 2015 6
Manuel de Réparation

7. SemWeb.pro 2015 7
Pièce de Rechange
référence désignation

8. SemWeb.pro 2015
RDF
8
identifies identifies
http://../xxx http://.../element/78dc:subject
has subject
identifies
“Air Filter”
Subject Property Value

9. SemWeb.pro 2015
RDFisation des données sources
(et modélisation du domaine)
9
DiagnosticPièces
Manuels
Réparations
Temps Main
d'œuvre
Systèmes Auteur
XML, XL, etc.
Triple store
etc...
ModélisationConversion en RDF
Données et modèle
partageables

10. SemWeb.pro 2015
Spécificité de la doc technique automobile
! Chaque document a une “Applicabilité”
! l’ensemble des véhicules pour lesquels il est pertinent
! une formule booléenne sur des valeurs de variables véhicules
! ne se représente pas bien avec le modèle relationnel
10

11. SemWeb.pro 2015
API ?
! Documents about “air filter”, for my vehicle?
! http://.../element/78?veh=VF123...
! 2 composantes aux requêtes
! une query SPARQL standard :
! SELECT ?doc WHERE {?doc dc:subject element:78.}
! le véhicule
! typiquement identifié par son VIN
! à défaut, couples variable=valeur (du RDF)
11

12. SemWeb.pro 2015
Schema de fonctionnement
12
Service Doc.
SPARQL Endpoint
Service évaluation
applicabilités
Triple store
BD description
des veh.
Filtered RDF List of docs
http://.../?query=[SPARQL query]&vin=VF123...
vin=VF123…
Client

13. SemWeb.pro 2015
! + une Api cliente en java (création des requêtes SPARQL)
! c’était bête !
! il aurait mieux fallu créer les requêtes côté service
! mais ce n’est jamais qu’un peu de refactoring de code
! Quels autres changements ?
13

14. SemWeb.pro 2015
5-6 ans plus tard…
! Plus “d’API SPARQL”, plus API cliente Java -> API REST
! Moins RDF / SPARQL centric, mais encore plus “Linked Data”
! “HyperMedia driven APIs”
! JSON-LD
! Hydra
! (au moins comme source d’inspiration)
! http://www.hydra-cg.com
! Lucene était utilisé de façon marginale -> SolR plus largement
! (y compris pour des choses qui étaient faites avec SPARQL/TripleStore)
! Performances ?
! Utilisation de représentations plus efficaces que RDF pour certaines données
! Indexations sur des paires de valeurs de propriétés
14

15. SemWeb.pro 2015 15
URI de “Filtre à
Air”
Vehicle query
param
Recherche de “Filtre à Air”
pour “Laguna III”
Variables à
définir pour statuer sur
l’applicabilité de certains
docs

16. SemWeb.pro 2015 16
‘Air Filter’
A List Of
Documents
The list of (document,
applicability evaluation) pairs
Unknown variables
The vehicle
One (document, applicability
evaluation) pair

17. SemWeb.pro 2015
Linked Data
17
Une des variables
manquantes
Une des valeurs
possibles
Même recherche,
avec cette valeur
sélectionnée
le client suit des liens,
c'est le serveur qui
crée les requêtes

18. SemWeb.pro 2015
Linked Data : une limite
! formulaires
! voir Hydra (templated links)
! http://www.hydra-cg.com
18

19. SemWeb.pro 2015
Conclusion : éléments techniques déterminants
! Architecture "REST / Linked Data"
! architecture web pour les données
! construction d'une IHM avec un minimum d'effort : en gros, afficher les données
retournées, et les liens qui y sont inclus
! garantit la qualité des requêtes
! scalabilité
! Modélisation des concepts et entités du domaine
! JSON-LD
! RDF
! intelligibilité des données publiées
! agrégation des données de sources diverses
! mais peut avoir un coût en termes de performances
19