Du balisage de la FAQ à la structure de données R

Question

Je suis en train de lire le R Source FAQ dans texinfo, et je me suis dit qu'il serait plus facile à gérer et à étendre s'il était analysé comme une structure R. Il y a plusieurs exemples existants liés à cela :

• le paquet chance

• entrées bibtex

• Fichiers Rd

chacune avec des caractéristiques souhaitables.

À mon avis, les FAQ sont sous-utilisées dans la communauté R parce qu'elles manquent i) d'un accès facile à partir de la ligne de commande R (c'est-à-dire via un paquet R) ; ii) de fonctions de recherche puissantes ; iii) de références croisées ; iv) d'extensions pour les paquets contribués. Tirer des idées des paquets bibtex y fortunes nous pourrions concevoir un nouveau système dans lequel.. :

• Les FAQ peuvent être recherchées à partir de R. Des appels typiques ressembleraient à l'exemple suivant fortune() interface : faq("lattice print") ou faq() #surprise me! , faq(51) , faq(package="ggplot2") .

• Les paquets peuvent fournir leurs propres FAQ.rda dont le format n'est pas encore clair (voir ci-dessous).

• Sweave / knitr Des pilotes sont fournis pour produire des fichiers Markdown/LaTeX joliment formatés, etc.

QUESTION

Je ne suis pas sûr de ce qui est le mieux entrée cependant. Soit pour convertir la FAQ existante, soit pour ajouter de nouvelles entrées.

Il est plutôt fastidieux d'utiliser la syntaxe R avec un arbre de listes imbriquées (ou un S3/S4/ref ad hoc). class o structure ,

\list(title = "Something to be \\escaped", entry = "long text with quotes, links and broken characters", category = c("windows", "mac", "test"))

Rd même si elle n'est pas une structure R à proprement parler (il s'agit plutôt d'un sous-ensemble de LaTeX avec son propre analyseur syntaxique), peut peut-être fournir un exemple plus attrayant de format d'entrée. Il dispose également d'un ensemble de outils pour analyser la structure en R. Cependant, son objectif actuel est plutôt spécifique et différent, étant orienté vers la documentation générale des fonctions R, et non vers les entrées de la FAQ. Sa syntaxe n'est pas idéale non plus, je pense qu'un balisage plus moderne, quelque chose comme markdown, serait plus lisible.

Existe-t-il quelque chose d'autre, peut-être des exemples d'analyse syntaxique de fichiers markdown en structures R ? Un exemple de déviation des fichiers Rd par rapport à leur objectif ?

En résumé

J'aimerais trouver une solution :

1- une bonne conception pour une structure R (classe, peut-être) qui étendrait le fortune paquet vers des entrées plus générales telles que les articles de la FAQ

2- un format plus pratique pour saisir les nouvelles FAQ (plutôt que le format actuel texinfo)

3- un analyseur syntaxique, écrit en R ou dans un autre langage (bison ?) pour convertir la FAQ existante en la nouvelle structure (1), et/ou le nouveau format d'entrée (2) en la structure R.

Mise à jour 2 : au cours des deux derniers jours de la période de prime, j'ai reçu deux réponses, toutes deux intéressantes mais complètement différentes. Parce que la question est assez vaste (sans doute mal posée), aucune des réponses ne fournit une solution complète, donc je ne vais pas (pour l'instant en tout cas) accepter une réponse. Quant à la prime, je l'attribuerai à la réponse la plus votée avant l'expiration de la prime, en souhaitant qu'il y ait un moyen de la diviser plus équitablement.

Answer 1

(Ceci répond au point 3.)

Vous pouvez convertir le fichier texinfo en XML

wget http://cran.r-project.org/doc/FAQ/R-FAQ.texi
makeinfo --xml R-FAQ.texi 

et ensuite le lire avec le paquet XML.

library(XML)
doc <- xmlParse("R-FAQ.xml")
r <- xpathSApply( doc, "//node", function(u) {
  list(list(
    title    = xpathSApply(u, "nodename", xmlValue),
    contents = as(u, "character")
  ))
} )
free(doc)

Mais il est beaucoup plus facile de le convertir en texte

makeinfo --plaintext R-FAQ.texi > R-FAQ.txt

et analyser le résultat manuellement.

doc <- readLines("R-FAQ.txt")

# Split the document into questions
# i.e., around lines like ****** or ======.
i <- grep("[*=]{5}", doc) - 1
i <- c(1,i)
j <- rep(seq_along(i)[-length(i)], diff(i))
stopifnot(length(j) == length(doc))
faq <- split(doc, j)

# Clean the result: since the questions 
# are in the subsections, we can discard the sections.
faq <- faq[ sapply(faq, function(u) length(grep("[*]", u[2])) == 0) ]

# Use the result
cat(faq[[ sample(seq_along(faq),1) ]], sep="\n")

Answer 2

Je suis un peu confus sur vos objectifs. Vous semblez vouloir que toute la documentation relative à R soit convertie dans un format que R peut manipuler, probablement pour que l'on puisse écrire des routines R pour mieux extraire les informations de la documentation.

Il semble y avoir trois hypothèses ici.

1) Il sera facile de convertir ces différents formats de documents (texinfo, fichiers RD, etc.) en une forme standard avec (j'insiste) une structure et une sémantique uniformes implicites.
En effet, si vous ne pouvez pas les faire correspondre à une structure unique, vous devrez écrire des outils R distincts pour chaque type de document, voire pour chaque document individuel, et le travail de post-conversion l'emportera sur les avantages.

2) que R est le bon langage pour écrire de tels outils de traitement de documents ; je soupçonne que vous avez un petit préjugé en faveur de R parce que vous travaillez avec R et que vous ne voulez pas envisager de "quitter" l'environnement de développement pour obtenir des informations sur la façon de mieux travailler avec R. Je ne suis pas un expert de R, mais je pense que R est principalement un langage numérique et qu'il n'offre pas d'aide particulière pour la manipulation des chaînes de caractères, la reconnaissance des formes, l'analyse syntaxique du langage naturel ou l'inférence, autant d'éléments qui devraient jouer un rôle important dans l'extraction d'informations à partir de documents convertis qui contiennent en grande partie du langage naturel. Je ne suggère pas un langage alternatif spécifique (Prolog ??), mais il serait peut-être préférable, si vous réussissez la conversion en forme normale (tâche 1), de choisir soigneusement le langage cible pour le traitement.

3) Que vous pouvez réellement extraire des informations utiles de ces structures. La bibliothéconomie était ce que le 20ème siècle a essayé de promouvoir ; maintenant nous sommes tous dans les méthodes de "recherche d'information" et de "fusion de données". Mais en fait, le raisonnement sur les documents informels a fait échouer la plupart des tentatives en ce sens. Il n'existe pas de systèmes évidents qui organisent le texte brut et en extraient une valeur profonde (le système Watson d'IBM, qui a remporté le jeu Jeopardy, est l'exception apparente, mais même là, on ne sait pas exactement ce que Watson "sait" ; voudriez-vous que Watson réponde à la question "Le chirurgien doit-il vous ouvrir avec un couteau ?", quelle que soit la quantité de texte brut que vous lui donnez).

Tout cela dit, la plupart des systèmes de balisage sur le texte ont une structure de balisage et du texte brut. On peut les "analyser" en structures arborescentes (ou en structures graphiques si l'on suppose que certaines choses sont des références croisées fiables ; texinfo en a certainement). Le XML est largement utilisé comme support pour de telles structures analysées, et étant capable de représenter des arbres ou des graphes arbitraires, il est ... OK ... pour capturer de tels arbres ou graphes. [Les gens poussent ensuite RDF ou OWL ou un autre système d'encodage de la connaissance qui utilise XML, mais cela ne change pas le problème ; vous choisissez une cible canonique indépendante de R]. Donc, ce que vous voulez vraiment, c'est quelque chose qui lise les diverses structures balisées (texinfo, fichiers RD) et produise du XML ou des arbres/graphes équivalents. Ici, je pense que vous êtes condamné à construire des analyseurs séparés O(N) pour couvrir tous les N styles de balisage ; comment autrement un outil pourrait-il savoir quelle est la valeur du balisage (donc de l'analyse) ? (On peut imaginer un système capable de lire des documents balisés lorsqu'on lui donne une description du balisage, mais même cela est O(N) : quelqu'un doit encore décrire le balisage). Une fois que l'analyse syntaxique est conforme à cette notation uniforme, vous pouvez alors utiliser un analyseur syntaxique R facile à construire pour lire le XML (en supposant qu'il n'en existe pas déjà un), ou si R n'est pas la bonne réponse, l'analyser avec la bonne réponse.

Il existe des outils qui vous aident à construire des analyseurs et des arbres d'analyse pour des langues arbitraires (et même des traducteurs des arbres d'analyse vers d'autres formes). ANTLR en est un ; il est utilisé par suffisamment de personnes pour que vous puissiez même trouver accidentellement un analyseur texinfo déjà construit par quelqu'un. Notre Boîte à outils de réingénierie du logiciel DMS en est un autre ; DMS, après l'analyse syntaxique, exportera un document XML avec l'arbre d'analyse directement (mais il ne sera pas nécessairement dans la représentation uniforme que vous souhaitez idéalement). Grâce à ces outils, il sera probablement relativement facile de lire le balisage et de le représenter en XML.

Mais je pense que votre véritable problème sera de décider ce que vous voulez extraire/faire, puis de trouver un moyen de le faire. À moins que vous n'ayez une idée claire de la façon de le faire, faire tous les parsers en amont semble juste être beaucoup de travail avec un gain peu clair. Peut-être avez-vous un objectif plus simple ("gérer et étendre", mais ces mots peuvent cacher beaucoup de choses) qui est plus facile à atteindre.