Cette page a démarré sur WikiVirtualData

WikiDonnéeVirtuelle veut dire regarder un wiki comme une autre forme de gérer des données (comme une base de données) et de fournir des commandes pour les extraire et les manipuler (comme SQL).

Alors que ceci peut sembler comme un moyen extrêmement inefficace pour gérer des données (ce qui est vrai), c'est en fait une forme d'optimisation, qui accepte une perte de performance dans le temps et l'espace pour une capacité accrue de résolution de problème. Cela semble fournir la flexibilité et le potentiel pour résoudre une certaine classe de problèmes difficiles qui résiste au problème des personnes des bases de données résolvant des stratégies.

Racines

L'idée n'est pas totalement nouvelle :

• Dans LaVoieDuWiki, WardCunningham décrit un "hack" pour faire du "traitement de page" pour ses exemples correspondants
• Différents clones wiki ont des fonctionnalités spéciales qui font un traitement de page spécial pour produire des types spéciaux de page ou rendre disponibles des contextes de données
• Même les fonctions index et rétrolien d'un wiki peuvent sembler sur le même chemin de la base de données
  • Index : "donnez moi une liste de tous les enregistrements de page type".
  • Rétrolien : "donnez-moi la liste de tous les enregistrements de page type qui contiennent un lien vers la page en cours dans leur contexte en texte-clair".

Mais même si nous prenons en considération toutes les fonctionnalités, ce n'est seulement qu'une toute petite fraction de ce qui peut être fait.

Le Modèle Basique de Donnée Virtuelle

Pour mettre cela en oeuvre, nous avons besoin d'un modèle basique pour séparer les données et le texte. Le moyen le plus simple est fourni par la syntaxe wiki de liste à puce. Ainsi, une ligne équivalente à :

  * variable : ....

ou comme expression régulière :

   /^[*]+ \s* ($AllowedWordCharacters+) \s* [:=] \s* (.*) $/

peut être considérée comme des données. Nous l'appelons donnée virtuelle parce qu'il n'est pas clair à l'heure où cela est écrit qu'une telle ligne soit vraiment considérée comme une donnée ou puisse être utilisée comme une donnée. Ceci affichera simplement quelque mécanique intelligente qui peut être utilisée pour transformer cette information en quelque chose d'utile.

Réinterpretation du contenu wiki

Ainsi, qu'est ce qui se fait en fait pour réinterpréter le contenu d'un wiki. Il y a beaucoup de moyens de faire ainsi et nous pouvons le faire comme nous le pensons approprié pour un problème.

Imaginons que nous ayons des pages personnelles dans un wiki qui portent le nom des membres, et qu'elles contiennent DossierPagePersonnelle et une puce information mailto.

Nous pouvons maintenant interpréter ça comme

• une table "PagePersonnelle" contenant des enregistrements (en fait des pages)
• dont la clé primaire est le nom du membre (page nom)
• ayant une colonne tableau "mailto:"
• qui contient les adresses e-mail des membres.

Un autre exemple est une convention sur EmacsWiki. Nous disons à tous les utilisateurs d'écrire sur la HomePage "I use Emacs." ou "I use XEmacs." Puis, nous pouvons lister tous les [utilisateurs Emacs] en utilisant une recherche simple.

Variantes :

• support pour différentes opérateurs de commande, par exemple (:|=).
• support pour des commentaires de fin-de-ligne, par exemple en utilisant le séparateur "#".

Comparaison avec les bases de données classiques

Inconvénients (comparés à une base de données classique) :

• gérer des données en plein texte est moins performant dans le temps et dans l'espace (qui se soucie si nous obtenons des données plus intelligentes)
• il est plus difficile de vérifier l'entrée pour correction
• ...

Avantages (comparé à une base de données classique) :

• Les données n'ont pas besoin d'être gérées et saisies sous une forme tabulaire
• l'utilisateur est libre de concevoir et commenter sa donnée
• certains problèmes (comme la dépendance au temps des données) peuvent être gérés facilement.
• ...

Fascinant : Pour l'UniversityWiki, j'étudie des moyens de stocker différents types de méta-données de cours dans le wiki. J'utilise actuellement

 {variablename: data}

pour une information courte et

 {variablename}
 paragraphs

comme conteneur pour des textes plus longs, comme les descriptions. Le dernier a la possibilité d'inclure une WikiSyntaxe (WikiMarkup) dans le texte. Cela m'ennuie que je suis actuellement d'utiliser le ---- comme un témoin pour marquer la fin de paragraphe, ce qui n'est ni intuitif ni évident. Pour fournir quelque réaction sur la vraie extension des paragraphes, je le restitue actuellement avec une bordure, pour montrer la quantité de texte qui est incluse. -- DavidSchmitt

Si je te comprends bien, tu pourrais économiser beaucoup de temps en téléchargeant l'une des trois bases de données XML libres et ne les utiliser simplement que comme ton backend. Aussi loin que puisse aller la théorie sur les bases de données en réseau, c'est tout à propos de bases de données XML. N'oublie pas de regarder XQL. -- SunirShah

Ainsi, j'ai simplement placé une [proposition] pour ajouter des noms de valeurs couplés aux articles MediaWiki. Le format serait :

 [[name=value]]

Je suis particulièrement intéressé par ça pour produire une partie-totalité des liens dans WikiTravel. Disposer du texte dans l'article WikiTravel:Greenwich_Village qui dit que Greenwich Village est un district de Manhattan qui est un quartier de New York City qui arrive à être dans l'Etat de New York qui est dans la région "Mid-Atlantic" des "United States of America" en "North America" est un peu beaucoup. Ce serait plus élégant de simplement dire [[borough=Manhattan]] et de laisser une sorte de LiensHorsLigne -- peut-être une sorte de petits cailloux -- faire le reste du travail lourd. Aussi une version imprimée est plus lisible de cette façon. --EvanProdromou

Ne peux-tu pas simplement lier vers Manhattan à partir de Greenwich Village, à partir de Manhattan, lier vers New York City, New York City vers New York State, et ainsi de suite ? Si tu veux forcer l'ontologie hiérarchique alors utilise les répertoires et dossiers. Maintenant, les répertoires et dossiers sont difficiles à utiliser, aussi faire que les répertoires et dossiers soient éditables en texte, comme des SousPages multipliées-imbriquées. Bien sûr, nous haïssons les SousPages parce que l'espace-nom devient hiérarchique sans raison valable. A côté de ça, [[Greenwich Village]] devrait toujours lier vers Greenwich Village et ce dans n'importe quelle situation. Mais [[London]] pouirrait lier vers London, Ontario ou London, England.

Ainsi, peut-être que quelque chose comme FacetWiki aiderait pour savoir qui utilise le contexte actuel ou plus précisément un contexte spécifié si nécessaire. Ainsi, si tu parles des plans de Bus vers Londres sur la page Manchester, England, cela supposera automatiquement London, England. Mais si tu parles de vols vers Londres à partir de Toronto, tu devras écrire [[London, England]]. Ceci peut devenir confus parce que tu peux aussi écrire [[London, UK]], mais ensuite bien sûr England est dans le Royaume-Uni et il n'y a qu'un London dans le Royaume-Uni, par conséquent l'algorithme peut résoudre sans ambiguïté l'espace nom. Ceci est un simple algorithme de recherche d'arbre, bien connu.

La syntaxe serait simple :

 London
 Place: England

 Description goes here.

 England
 Place: United Kingdom

 Description goes here.

 UK
 Alias: United Kingdom

 United Kingdom
 Place: British Isles

 British Isles
 Place: Western Europe

Bien sûr, résoudre plusieurs parents, comme les hémisphères occidentaux et nord est la raison pour laquelle nous aimons les parents mutliples. -- SunirShah

Voir aussi : FractalitéWiki et ContextualitéWiki (La WikiDonnéeVirtuelle est exigée pour gérer les deux).

Voir aussi FonctionnalitéDatabaseWiki (une idée plus restreinte de fonctionnalité de database tabulaire)

LangueFrançaise PageTranslation WikiVirtualData DossierTechnologieWikiNoncommune