Avant de commencer je précise que je sais de quoi je parle si c’est au sujet de Javascript, Vue.js et compagnie mais pas quand j’aborde RDF. Ma source d’information principale reste Wikipédia (plus clair que le jargon universitaire fréquent avec RDF) et plus particulièrement pour ce suit suit la page Wikipédia RDF Schema — Wikipédia. Donc si je dis des bêtises …
A la base mon problème est l’exploitation des « catégories » attachées aux POI : Il y en a 499 (le système est limité à 500 ?) et il est impossible de les proposer pour sélection aux utilisateurs.
J’ai donc creusé le problème :
- Dans la recherche ?s rdf:type ?o « ?o » identifie une classe, c’est dû à la définition de rdf:type. On pourrait s’attendre à ce que les prédicats rfds:label et rdfs:comment normalement associés aux classes soient renseignés mais ils ne le sont pas, ce qui rend la signification de ces classes incertaine. Quelle différence entre les classes :Organisation (classe Datatourisme) et foaf:Organization ?
- Au contraire rdfs:label et rdfs:comment sont inclus et utilisés dans les définitions des POI alors que les POI ne sont pas des classes mais des ensembles indéfinis de propriétés diverses décrivant le POI.
- La recherche parmi les classes serait facilitée - et en fait utilisable - si les triplets décrivant l’ontologie, si ils existent, étaient inclus dans l’export de la base. Il serait alors possible de rédiger des requêtes du genre
?s rdf:type / rdfs:subClassOf :EntertainmentAndEvent
Dans les faits j’ai recréé ma propre pseudo-ontologie de classes et sous-classes et je peux effectuer des recherches de ce type. Mais il ne faut pas oublier que les moteurs SPARQL ont (souvent) des capacités d’inférence basés sur les ontologies correctement structurées qui leur permettent des recherches performantes, ce que ma pseudo-ontologie ne permet évidemment pas.
Malgré tout ça fonctionne, et mon site (nad.blue) tourne correctement.
Mais un projet participatif créant en parallèle une seconde base Datatourisme, avec une ontologie simplifiée (franchement, 5 types de personnes à contacter ou le nombre de places assises, c’est utilisé ?), intégrée à la base et utilisable en SPARQL permettrait de dynamiser ces données. De même un point d’accès SPARQL accessible en interface graphique et API semble aussi indispensable que peu coûteux. Si il y en a que ça tente …
