[Home]WikiDonnéeVirtuelle

MeatballWiki | RecentChanges | Random Page | Indices | Categories
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 :

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

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 :

Comparaison avec les bases de données classiques

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

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

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

Discussion

MeatballWiki | RecentChanges | Random Page | Indices | Categories
Edit text of this page | View other revisions
Search: