Ce n’est pas aux utilisateurs de structurer les données qu’ils produisent. Et je ne pense pas non plus qu’une structuration automatique soit un argument marketing pour utiliser tel ou tel service. Structurer pour structurer, à quoi bon ?

Le fait est qu’il est aujourd’hui possible de créer de la valeur et proposer de vrais bénéfices à ses clients / utilisateurs en ayant sous le capot des technologies du web sémantique. Mais encore une fois, cela ne doit pas être l’argument marketing premier (cf. Twine).

Pour ce qui est des moteurs de recherche, c’est un autre sujet ;)

malheuresement cela nest possible que pour une partie des datas.
en effet, aujourd’hui de plus en plus d’informations sont créés par des gens qui n’ont ni le souci ni la possibilité de renseigner et/ou structurer leurs informations.

c’est la tendance lourde des CMS (Gestion de contenus) et c’est souvent dans ces datas que reside les réelles plus values en terme d’informations.

Il existe un gouffre entre les possibilités d’exploitation d’une documentation de l’industrie aéraunotique et celles offertes par exemple par les enquêtes journalistiques,tests d’utilisateurs, ou autres.

Les moteurs de recherche à la google ont encore de beaux jours devant eux !

Pour ce qui est de ton exemple de traduction de textes japonais ou arabes, la traduction produit déjà en elle même une perte de sens (où en tout cas une légère transformation). Après la nature d’une visualisation c’est justement d’apporter son propre sens, sa propre subjectivité. Mais là c’est un point de vu très personnel.

l’association datas => vues => visualisations me semble répondre au problème des page comportant une présentation complexe des informations.

reste l’autre question concernant le texte enrichi; dit autrement sous quel format faut-il stocker les informations de type texte ?
- texte brut avec comme avantage une réutilisation facile mais en ayant perdu les informations contenus dans l’enrichissement
- texte enrichi : se pose alors le problème du format (xhtml autres)

je pense par exemple au problème des capitales qui n’existent pas dans toutes les langues ou sera prefere une mise en gras ou une taille de police plus importante.
Et ici je ne parle pas du probleme de la traduction;

prenons lexemple d’un texte en japonais ou arabe dans lequel un certain nombre de mots ont été mis en gras; ces mots participent à la compréhension du sens au même titre que les saut de ligne et les elements de ponctuation. si le texte est stocké sous sa forme brute, sa réutilisation dans une autre visualisation perdra une partie de son sens.

En effet c’est un problème qui peut se poser pour les sources de données très complexes. Où il faut passer plusieurs heures (jours?) pour comprendre toute la richesse du dataset et isoler les données à visualiser.
Dans les bases de données relationnels on trouve souvant des « vues » qui permettent d’isoler une partie des données. Faciliter la création de vues dans le web des données peut être une approche intéressante. D’autant plus que qu’il serait possible d’utiliser des données provenant de plusieurs datasets en même temps (je pense au language de requête SPARQL).

Donc plus que la « création » d’un nouveau dataset, il est possible d’avoir une vision réduite et dynamique (puisque sans copie), d’une partie des données.

Dans ce dernier cas, il ne s’agirait plus de multiplier les visualisations de la même source de données (template), mais bien de faciliter la création d’une nouvelle source de données en mettant à disposition du créateur des outils de réutilisation de données existantes (recherche, copier/coller, conversion de formats)