DATAtourisme

Structure Json non uniforme

Bonjour,

J’ai constaté que la structure des fichiers Json n’est pas la même dans tous les fichiers résultats correspondant pourtant à une même requête SPARQL exécutée par API JSON.
Cela oblige à analyser la structure de chaque fichier avant de pourvoir exploiter les données de chaque membre. Il faut coder tous les cas rencontrés pour pouvoir en extraire l’information.
Au final les traitements sont très longs, difficiles à maintenir et se terminent souvent en erreur car de nouveaux cas de déstructuration apparaissent ici ou là.

Il peut s’agir, par exemple, d’un membre déclaré en tableau, puis déclaré comme membre unique quelques lignes plus loin dans la même structure.
Egalement, la structure « Offers » varie énormément selon les fichiers, il est difficile de s’y retrouver.

Exemples ci-dessous.

■ Pour la même information, ici le libellé du tarif, certains fichiers utilisent le membre eligibleQuantity et d’autres fichiers utilisent l’information rdfs:label.

offers[].'schema:priceSpecification'[].schema:eligibleQuantity
offers[].'schema:priceSpecification'[].hasEligiblePolicy.rdfs:label.fr[]

■ Au sein d’un même fichier, certains membres n’ont pas la même déclinaison.
Exemple ci-dessous, « hasEligiblePolicy » est à la fois membre unique et tableau.
« Festival : la BD prend l’air | DATAtourisme »
« offers »:[
{
« @id »:« La ressource demandée n'existe pas ! | DATAtourisme »,
« schema:priceSpecification »:[
{
« @id »:
« schema:eligibleQuantity »:
« schema:minPrice »:[],
« schema:price »:
« schema:priceCurrency »:"
« @type »:[]

       **"hasEligiblePolicy":[ ]	membre sous forme de tableau**
              },
{
           "@id":
           "schema:eligibleQuantity":
           "schema:minPrice":[],
           "schema:price":
           "schema:priceCurrency":
           "@type":[]
>>           **"hasEligiblePolicy":{ }	membre unique**
        },

Savez-vous si, à terme, une structure identique pourra être générée dans chaque fichier Json pour une même requête SPARQL ?

Cordialement.

Bonjour,

Navré pour le délai de réponse, le sujet était passé au travers de notre radar…

Pour le premier point, il s’agit de règles d’alignement différent selon le producteur : cette remontée d’incohérence va servir à améliorer la normalisation des données.

Pour le second point, d’un point de vue strictement « ontologique », la propriété hasEligiblePolicy est fonctionnelle : elle ne devrait comporter qu’une seule valeur. Ce devrait donc être un membre unique, pour reprendre votre terme.

Cependant, il semble que certains producteurs y associent plusieurs membres, ce qui créé, dans ce cas précis, un tableau. Nous allons soumettre cette incohérence à l’équipe projet, pour qu’une décision soit prise à ce sujet.

Nous ne manquerons pas de vous tenir au courant sur ce même fil.

Cordialement,