plots - text in r

Marcado de preguntas frecuentes a la estructura de datos R

Question

Estoy leyendo la fuente de preguntas frecuentes de R en texinfo y pensando que sería más fácil de administrar y extender si se analizara como una estructura de R. Hay varios ejemplos existentes relacionados con esto:

• el paquete de fortunas

• entradas bibtex

• Archivos Rd

cada uno con algunas características deseables.

En mi opinión, las preguntas frecuentes están infrautilizadas en la comunidad R porque carecen de i) acceso fácil desde la línea de comando R (es decir, a través de un paquete R); ii) poderosas funciones de búsqueda; iii) referencias cruzadas; iv) extensiones para paquetes contribuidos. Tomando ideas de paquetes bibtex y fortunes , podríamos concebir un nuevo sistema donde:

• Las preguntas frecuentes se pueden buscar desde R. Las llamadas típicas se parecerían a la interfaz de la fortune() : faq("lattice print") , o faq() #surprise me! , faq(51) , faq(package="ggplot2") .

• Los paquetes pueden proporcionar su propia FAQ.rda , FAQ.rda formato aún no está claro (ver a continuación)

• knitr controladores Sweave / knitr se proporcionan para generar Markdown / LaTeX con un formato agradable, etc.

PREGUNTA

Sin embargo, no estoy seguro de cuál es el mejor formato de entrada . Ya sea para convertir las preguntas frecuentes existentes o para agregar nuevas entradas.

Es bastante engorroso usar la sintaxis R con un árbol de listas anidadas (o una class o structure S3 / S4 / ref ad hoc)

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

Rd documentación de Rd , aunque no sea una estructura R per se (es más un subconjunto de LaTeX con su propio analizador), quizás pueda proporcionar un ejemplo más atractivo de un formato de entrada. También tiene un conjunto de herramientas para analizar la estructura en R. Sin embargo, su propósito actual es bastante específico y diferente, está orientado a la documentación general de las funciones R, no a las entradas de preguntas frecuentes. Su sintaxis tampoco es ideal, creo que un marcado más moderno, algo así como un descuento, sería más legible.

¿Hay algo más por ahí, tal vez ejemplos de análisis de archivos de rebajas en estructuras R? ¿Un ejemplo de desviación de los archivos Rd lejos de su propósito previsto?

Resumir

Me gustaría pensar en:

1- un buen diseño para una estructura R (clase, tal vez) que extienda el paquete de la fortune a entradas más generales, tales como elementos de preguntas frecuentes

2- un formato más conveniente para ingresar nuevas preguntas frecuentes (en lugar del formato actual de texinfo)

3- un analizador sintáctico, ya sea escrito en R o en otro idioma (bison?) Para convertir las preguntas frecuentes existentes en la nueva estructura (1), y / o el nuevo formato de entrada (2) en la estructura R.

Actualización 2: en los últimos dos días del período de recompensa obtuve dos respuestas, ambas interesantes pero completamente diferentes. Debido a que la pregunta es bastante vasta (posiblemente discutible), ninguna de las respuestas proporciona una solución completa, por lo tanto, no aceptaré (por ahora de todos modos) una respuesta. En cuanto a la recompensa, la atribuiré a la respuesta más votada antes de que expire la recompensa, deseando que haya una forma de dividirla de manera más equitativa.

Answer 1

(Esto aborda el punto 3)

Puede convertir el archivo texinfo a XML

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

y luego léelo con el paquete 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)

Pero es mucho más fácil convertirlo a texto

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

y analizar el resultado manualmente.

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

No estoy un poco claro sobre tus objetivos. Parece que desea que toda la documentación relacionada con R se convierta en algún formato que R pueda manipular, presumiblemente para que pueda escribir rutinas R para extraer mejor la información de la documentación.

Parece que hay tres suposiciones aquí.

1) Que será fácil convertir estos diferentes formatos de documento (texinfo, archivos RD, etc.) a alguna forma estándar con (enfatizo) cierta estructura y semántica uniformes implícitas.
Porque si no puede asignarlos a una sola estructura, tendrá que escribir herramientas R separadas para cada tipo y tal vez para cada documento individual, y luego el trabajo de la herramienta de conversión posterior anulará el beneficio.

2) Que R es el lenguaje correcto para escribir tales herramientas de procesamiento de documentos; sospeche que está un poco predispuesto hacia R porque trabaja en R y no quiere contemplar "abandonar" el entorno de desarrollo para obtener mejor información sobre cómo trabajar con R. No soy un experto en R, pero creo que R es principalmente un lenguaje numérico, y no ofrece ninguna ayuda especial para el manejo de cadenas, el reconocimiento de patrones, el análisis de lenguaje natural o la inferencia, y espero jugar un papel importante. en la extracción de información de los documentos convertidos que en gran parte contienen lenguaje natural. No estoy sugiriendo un lenguaje alternativo específico (Prólogo), pero podría estar mejor, si tiene éxito con la conversión a la forma normal (tarea 1) para elegir cuidadosamente el idioma de destino para el procesamiento.

3) Que realmente puede extraer información útil de esas estructuras. La ciencia bibliotecaria fue lo que el siglo XX intentó impulsar; ahora estamos todos en los métodos de "Recuperación de información" y "Fusión de datos". Pero, de hecho, razonar sobre documentos informales ha derrotado a la mayoría de los intentos de hacerlo. No hay sistemas obvios que organicen el texto en bruto y extraigan un valor profundo de él (el sistema Watson ganador de Jeopardy de IBM es la aparente excepción pero incluso allí no está claro qué Watson "sabe"; ¿le gustaría que Watson responda la pregunta? " ¿Debería el cirujano abrirlo con un cuchillo? "No importa la cantidad de texto sin procesar que le haya dado). El punto es que puede lograr convertir los datos, pero no está claro qué puede hacer con éxito.

Dicho todo esto, la mayoría de los sistemas de marcado en texto tienen estructura de marcado y texto en bruto. Uno puede "analizar" esos en estructuras similares a un árbol (o estructuras tipo gráfico si se supone que ciertas cosas son referencias cruzadas confiables, texinfo sin duda tiene estos). XML es ampliamente utilizado como soporte para tales estructuras analizadas, y al ser capaz de representar árboles arbitrarios o gráficos, está ... OK ... para capturar dichos árboles o gráficos. [Las personas luego envían RDF o OWL o algún otro sistema de codificación de conocimientos que usa XML, pero esto no está cambiando el problema; eliges un objetivo canónico independiente de R]. Entonces, lo que realmente quieres es algo que lea las diversas estructuras marcadas (texinfo, archivos RD) y escupir XML o árboles / gráficos equivalentes. Aquí creo que estás condenado a construir analizadores O (N) separados para cubrir todos los estilos de marcado N; ¿De qué otra forma una herramienta sabría cuál era el valor marcado (por lo tanto, el análisis sintáctico)? (Puede imaginar un sistema que podría leer documentos marcados cuando se le da una descripción del marcado, pero incluso esto es O (N): alguien todavía tiene que describir el marcado). Uno de estos análisis es para esta notación uniforme, luego puede usar un analizador R de fácil construcción para leer el XML (suponiendo que uno no exista), o si R no es la respuesta correcta, analice esto con la respuesta correcta. .

Hay herramientas que lo ayudan a construir analizadores y analizar árboles para idiomas arbitrarios (e incluso traductores de los árboles de análisis a otras formas). ANTLR es uno; es utilizado por un número suficiente de personas, por lo que incluso puede encontrar accidentalmente un analizador de texinfo que alguien ya haya creado. Nuestro kit de herramientas de reingeniería de software DMS es otro; DMS después del análisis exportará un documento XML directamente con el árbol de análisis sintáctico (pero no necesariamente estará en esa representación uniforme que usted idealmente desea). Estas herramientas probablemente harán que sea relativamente fácil leer el marcado y representarlo en XML.

Pero creo que tu verdadero problema será decidir qué quieres extraer / hacer, y luego encontrar la forma de hacerlo. A menos que tenga una idea clara de cómo hacer esto último, hacer todos los analizadores iniciales simplemente parece mucho trabajo con una rentabilidad poco clara. Tal vez tenga un objetivo más simple ("administrar y ampliar", pero esas palabras pueden ocultar mucho) que es más factible.