Algún tipo de Github sin fricción para los científicos (ver http://news.ycombinator.com/item …)
En palabras del usuario …
Github para científicos: un sistema distribuido de alojamiento y control de versiones para todas las partes de la comunicación científica, incluida la escritura, el código, los datos y el audio / video / imágenes. ¡Para que puedas construir sobre el trabajo de otra persona versionándolo! ¿No es de eso de lo que se trata la ciencia?
Sin embargo, todavía no hay herramientas libres de fricción disponibles. Los wikis colaborativos funcionan bastante bien, pero aún tienen mucha fricción ( especialmente con tablas ). El problema es que todavía hay MUY pocas herramientas (si las hay) que permitan la fusión sin fricción de tablas y otros tipos de texto. Y eso es precisamente lo que más necesitamos: algo que tal vez combine las mejores partes de Wikis, Google Docs (con sus conjuntos de cambios), GitHub y Quora (en ciencia, asuntos de crédito, y solo Quora hace un buen trabajo al asignar crédito). De hecho , un sistema como ese podría incluso proporcionar una alternativa viable a las citas (con toda la información que ocultan) algún día, ya que nos permitiría identificar fácilmente cómo alguien contribuyó a un proyecto (y también cuantificar sus contribuciones)
Quizás SAGE ( http://www.sagemath.org/ ) es un paso en la dirección correcta. En SAGE, en realidad tienen cuadernos de colaboración que proporcionan una base para una fusión sin fricción de tablas, ecuaciones y documentos.
Pero también, es cierto, son las culturas separadas de cada campo el problema. La mayoría de los campos científicos están bastante separados entre sí. Y mucho de esto se debe a que muchos científicos piensan que * sus * métodos son mejores y que no tienen mucho que aprender unos de otros. Las personas que “incursionan” en diferentes campos, en particular, a menudo son rechazadas. Ver http://blogs.discovermagazine.co … y http://blogs.discovermagazine.co …. Publiqué un hilo en los foros de física sobre el tema de “reinventar la rueda”, pero finalmente terminé siendo atacado por ello ( http://www.physicsforums.com/sho …)
También discutí este problema con varios investigadores en la Escuela de Verano de Astrobiología Computacional ( http://www.ifa.hawaii.edu/UHNAI/ …), muchos de ellos también quieren reducir la duplicación del esfuerzo de RD. Pero el problema es, nuevamente, que la gente a menudo piensa que si no desarrolla las cosas desde lo más básico, entonces se está perdiendo algo (pedagógicamente hablando). Piensan que eres una persona intelectualmente descuidada que siempre intenta tomar atajos. Pero este tipo de creencias son los mismos tipos de creencias que nos obligan a tomar más y más tiempo para terminar la escuela (y como resultado, no estamos haciendo un trabajo creativo durante los años en que estamos en la cima). En algún momento, tenemos que hacer lo que funciona mejor: la pureza intelectual sea condenada. Después de todo, nos paramos sobre los hombros de gigantes. No necesitamos saber cómo funciona la tabla de lavar antes de usar la lavadora.
Y además, no hay ninguna prueba de que “aprender de los fundamentos” sea mejor que aprender cosas al revés. Personalmente, creo que obtengo una comprensión mucho más sofisticada de las cosas cuando aprendo cosas al revés (y también aprendo mucho más rápido)
Alguna información más útil en http://cameronneylon.net/blog/wh …
El primer paso es simple, hacer un registro, idealmente una dirección en la web para todo lo que creamos en el proceso de investigación. Para los datos y el software, solo los archivos mismos, en un disco duro es un buen comienzo. Empujarlos a algún tipo de almacenamiento web, ya sea un blog, github, un repositorio institucional o algún servicio de almacenamiento de datos dedicado, es aún mejor porque facilita el paso dos.
El segundo paso es crear fuentes que enumeren todos estos objetos, sus direcciones y la mayor cantidad posible de metadatos estándar, quién y cuándo sería un buen comienzo. Los abriría por elección, principalmente porque lidiar con la seguridad de los feeds es un problema, pero aún así funcionaría detrás de un firewall.
El tercer paso se vuelve un poco más difícil. Siempre que sea posible, configure sus sistemas para que las entradas siempre se puedan seleccionar desde una fuente configurable por el usuario. Siempre que sea posible, automatice el envío de resultados a los sistemas de almacenamiento elegidos para que los nuevos objetos se registren automáticamente y se creen nuevas fuentes.
Esto es extraordinariamente simple conceptualmente. Cree feeds, utilícelos como entradas para procesos. No es tan sencillo construir tal cosa en una herramienta o marco existente, pero tampoco tiene que ser demasiado difícil. Y tampoco necesita molestar al usuario. Los feeds deben crearse automáticamente y presentarse al usuario como menús desplegables.
El paso más allá de esto, crear un marco estándar para describir las relaciones entre todos estos objetos es mucho más difícil. No porque sea difícil, sino porque requiere un acuerdo sobre las normas sobre cómo describir esas relaciones. Esto es factible y estoy muy entusiasmado con el trabajo en Southampton en la Ontología Experimental OREChem, pero los problemas sociales son más difíciles. Otros prefieren el modelo de procedencia abierta o argumentan que los flujos de trabajo son la forma de administrar esta información. Es difícil llegar a un acuerdo sobre los estándares, particularmente si estamos tratando de maximizar su cobertura efectiva, pero si vamos a construir un registro computable de la ciencia, tendremos que abordar ese problema. Si podemos descifrarlo y obtener cobertura de los registros a través de un conjunto de modelos compatibles que nos dicen cómo están relacionadas las cosas, entonces creo que estaremos en condiciones de resolver el problema cultural de lograr que las personas los usen.
