page_0101

mi resumen. El sistema grabó cuando lo cargué. Marqué una casilla para que la tesis estuviera disponible de inmediato y luego apareció en línea. Lo puedes encontrar en la sección de la Facultad de Educación y Desarrollo Humano de la Colección de Tesis y Disertaciones de Electrónica de GMU. Donde en el pasado, imagino, un catalogador habría necesitado crear un registro para mi disertación, el sistema ahora está configurado de tal manera que el trabajo de hacer eso se transfiere al autor de la disertación. Los repositorios institucionales se utilizan para mucho más que disertaciones, muchos contienen cosas como actas de reuniones, podcasts, presentaciones de PowerPoint, conjuntos de datos de investigación, grabaciones de video, etc.

Las fortalezas de este tipo de sistema (en gran medida, cuando las llaves se han otorgado a los usuarios) son simultáneamente su mayor debilidad. Es fácil para este tipo de sistemas convertirse en un "motel con cucarachas" donde la gente carga inconsistentemente y describe inadecuadamente objetos digitales. 93 Tienden a funcionar bien para algo como disertaciones, donde es posible insistir en que alguien no pueda graduarse sin depositar su disertación. Pero más allá de eso, este tipo de sistemas tiende a representar de manera errática los registros de una institución. Es decir, la amplitud de este tipo de colección va a vivir o morir en función de lo bien que incentive la participación de sus usuarios. Del mismo modo, cuando una biblioteca contrata a alguien para que describa y catalogue sistemáticamente alguna colección, se obtienen metadatos y niveles de descripción muy consistentes. Cuando entrega esa función para que cada usuario final de un sistema en lo individual lo haga, puede terminar fácilmente con datos incoherentes e inconsistentes. El mismo conjunto de problemas surge en contextos muy diferentes.

StoryCorp.Me Historia oral de colaboración abierta y distribuida

Es probable que muchos lectores estén familiarizados con StoryCorps, fragmentos de entrevistas de historia oral que comparten cada semana en NPR. Desde 2003, StoryCorp ha recopilado más de 50,000 de esas entrevistas de historia oral de cabinas de escucha que viajan por todo el país. Esas entrevistas son descritas y almacenadas por el personal y los archiveros de StoryCorps y finalmente archivadas para su preservación en la Biblioteca del Congreso. En 2015, StoryCorps diseñó y lanzó StoryCorp.me, una aplicación móvil que permite a personas de todo el mundo realizar entrevistas de StoryCorp usando su teléfono, ingresar metadatos para ellas y subirlas para incluirlas en el archivo. Como puede imaginar, esto expande rápida y dramáticamente el tamaño de la colección. Rápidamente, StoryCorp tuvo más entrevistas desde la aplicación que luego de más de una década de recopilar entrevistas desde las cabinas. Debo enfatizar que este caso no es único. Muchas organizaciones están utilizando cosas como la plataforma de publicación de colección de código abierto Omeka para crear estas colecciones de crowdsourcing. Estas aplicaciones recopilaron entrevistas, y otros esfuerzos de recolección de colaboración colectiva, vienen con exactamente el mismo conjunto de problemas potenciales que los materiales en un repositorio institucional. Es decir, dado que los metadatos de esta colección son generados por el usuario, inevitablemente no serán tan consistentes y completos como los metadatos que los profesionales capacitados habían creado en el pasado.

El resultado de esto es que el diseño de la experiencia del usuario, con pruebas iterativas en el desarrollo de interfaces y flujos de trabajo, se vuelve crítico como práctica de este tipo de sistemas. Lo que termina siendo una especie de proyecto de investigación en ciencias sociales. De ¿Cómo motiva o incentiva a las personas a participar en estos sistemas? ¿Qué tipos de campos de metadatos deberían usar vocabularios controlados y menús desplegables? ¿Cuándo debería tener un campo de texto libre? ¿Cuántos campos de metadatos puede pedirle a alguien que complete? Establece restricciones sobre los tipos de archivos que alguien puede cargar, valida los archivos que cargan y obligarlos a

______________
93 Una de las mejores piezas sobre las amplias limitaciones y desafíos de establecer y ejecutar repositorios digitales sigue siendo el “Innkeeper at the Roach Motel.” de Salo.

mi resumen. El sistema grabó la fecha de que lo subí. Marqué una casilla para que la tesis estuviera disponible de inmediato y así estuvo disponible en línea. Se puede encontrar en la sección de la Facultad de Educación y Desarrollo Humano de la Colección Electrónica de Tesis y Disertaciones de la GMU. Me imagino que en el pasado un catalogador habría necesitado crear un registro para mi disertación, pero ahora el sistema está configurado para que ese trabajo es transferido al autor de la disertación. Los repositorios institucionales se utilizan para mucho más que disertaciones, contienen cosas como actas de reuniones, podcasts, presentaciones de PowerPoint, conjuntos de datos de investigación, grabaciones de video, etc.

Las fortalezas de este tipo de sistema (en gran medida, que las llaves hayan sido entregadas a los usuarios) son a la vez su mayor debilidad. Es fácil para este tipo de sistemas convertirse en un "motel para cucarachas" donde las personas suben de manera inconsistente y describen inadecuadamente los objetos digitales 93 ya que tienden a funcionar bien para algo como disertaciones, donde es posible insistir en que alguien no pueda graduarse sin depositar su disertación. Pero más allá, este tipo de sistemas tiende a representar de manera desigual los registros de una institución. Es decir, la extensión de este tipo de colecciones vivirá o morirá en función de lo bien que incentive la participación de sus usuarios. Cuando una biblioteca contrata a alguien para describir y catalogar sistemáticamente alguna colección, se termina con metadatos y niveles de descripción altamente consistentes. Cuando se entrega esa función para que cada usuario final de un sistema lo haga, se puede terminar fácilmente con datos irregulares y a la moda. El mismo conjunto de problemas surge en contextos muy diferentes.

StoryCorp.Me Colaboración abierta o "crowdsourcing" de historia oral

Es probable que muchos lectores estén familiarizados con StoryCorps, los fragmentos de entrevistas de historia oral que se comparten cada semana en NPR. Desde 2003, StoryCorp ha recopilado más de 50,000 de esas entrevistas de historia oral recolectadas en cabinas de audio que viajan por todo el país. Esas entrevistas son descritas y almacenadas por el personal y los archiveros de StoryCorps y finalmente archivadas para su preservación en la Biblioteca del Congreso. En 2015 StoryCorps diseñó y lanzó StoryCorp.me, una aplicación móvil que permite a personas de todo el mundo realizar entrevistas de StoryCorp usando su teléfono, ingresar metadatos para ellas y subirlas para incluirlas en el archivo. Como se puede imaginar, esto expandió rápida y dramáticamente el tamaño de la colección. En poco tiempo StoryCorp tuvo más entrevistas desde la aplicación que durante más de una década de recopilar entrevistas desde las cabinas de audio. Debo enfatizar que este caso no es único. Muchas organizaciones utilizan cosas como la plataforma para la publicación de colecciones de código abierto Omeka para crear estas colecciones a partir del crowdsourcing. Estas aplicaciones que recopilaron entrevistas y otros esfuerzos de colaboración colectiva vienen con exactamente el mismo conjunto de problemas potenciales que los materiales en un repositorio institucional. Es decir, como los metadatos de esta colección son generados por el usuario, inevitablemente no serán tan consistentes y completos como los metadatos que los profesionales capacitados han creado en el pasado.

El resultado es que el diseño de la experiencia del usuario, a través de pruebas iterativas del desarrollo de interfaces y flujos de trabajo, se vuelve crítico para la capacidad de este tipo de sistemas. Esto termina siendo una especie de proyecto de investigación en ciencias sociales. ¿Cómo se motiva o incentiva a las personas a participar en estos sistemas? ¿Qué tipos de campos de metadatos se deben usar? ¿Se debería usar vocabularios controlados y menús desplegables? ¿Cuándo se debería tener un campo de texto libre? ¿Cuántos campos de metadatos se le pueden pedir a alguien que complete? ¿Se deben establecer restricciones sobre los tipos de archivos que se pueden subir, o se validan los archivos que se suben y si hace falta información, obligar a los

93 Uno de los mejores textos sobre la extensión de los límites y retos de establecer un repositorio digital funcional sigue siendo el “Innkeeper at the Roach Motel” de Salo.

mi resumen. El sistema grabó cuando lo cargué. Marqué una casilla para que la tesis estuviera disponible de inmediato y luego apareció en línea. Lo puedes encontrar en la sección de la Facultad de Educación y Desarrollo Humano de la Colección de Tesis y Disertaciones de Electrónica de GMU. Donde en el pasado, imagino, un catalogador habría necesitado crear un registro para mi disertación, el sistema ahora está configurado de tal manera que el trabajo de hacer eso se transfiere al autor de la disertación. Los repositorios institucionales se utilizan para mucho más que disertaciones, muchos contienen cosas como actas de reuniones, podcasts, presentaciones de PowerPoint, conjuntos de datos de investigación, grabaciones de video, etc.

Las fortalezas de este tipo de sistema (en gran medida, cuando las llaves se han otorgado a los usuarios) son simultáneamente su mayor debilidad. Es fácil para este tipo de sistemas convertirse en un "motel con cucarachas" donde la gente carga inconsistentemente y describe inadecuadamente objetos digitales. 93 Tienden a funcionar bien para algo como disertaciones, donde es posible insistir en que alguien no pueda graduarse sin depositar su disertación. Pero más allá de eso, este tipo de sistemas tiende a representar de manera errática los registros de una institución. Es decir, la amplitud de este tipo de colección va a vivir o morir en función de lo bien que incentive la participación de sus usuarios. Del mismo modo, cuando una biblioteca contrata a alguien para que describa y catalogue sistemáticamente alguna colección, se obtienen metadatos y niveles de descripción muy consistentes. Cuando entrega esa función para que cada usuario final de un sistema en lo individual lo haga, puede terminar fácilmente con datos incoherentes e inconsistentes. El mismo conjunto de problemas surge en contextos muy diferentes.

StoryCorp.Me Historia oral de colaboración abierta y distribuida

Es probable que muchos lectores estén familiarizados con StoryCorps, fragmentos de entrevistas de historia oral que comparten cada semana en NPR. Desde 2003, StoryCorp ha recopilado más de 50,000 de esas entrevistas de historia oral de cabinas de escucha que viajan por todo el país. Esas entrevistas son descritas y almacenadas por el personal y los archiveros de StoryCorps y finalmente archivadas para su preservación en la Biblioteca del Congreso. En 2015, StoryCorps diseñó y lanzó StoryCorp.me, una aplicación móvil que permite a personas de todo el mundo realizar entrevistas de StoryCorp usando su teléfono, ingresar metadatos para ellas y subirlas para incluirlas en el archivo. Como puede imaginar, esto expande rápida y dramáticamente el tamaño de la colección. Rápidamente, StoryCorp tuvo más entrevistas desde la aplicación que luego de más de una década de recopilar entrevistas desde las cabinas. Debo enfatizar que este caso no es único. Muchas organizaciones están utilizando cosas como la plataforma de publicación de colección de código abierto Omeka para crear estas colecciones de crowdsourcing. Estas aplicaciones recopilaron entrevistas, y otros esfuerzos de recolección de colaboración colectiva, vienen con exactamente el mismo conjunto de problemas potenciales que los materiales en un repositorio institucional. Es decir, dado que los metadatos de esta colección son generados por el usuario, inevitablemente no serán tan consistentes y completos como los metadatos que los profesionales capacitados habían creado en el pasado.

El resultado de esto es que el diseño de la experiencia del usuario, con pruebas iterativas en el desarrollo de interfaces y flujos de trabajo, se vuelve crítico como práctica de este tipo de sistemas. Lo que termina siendo una especie de proyecto de investigación en ciencias sociales. De ¿Cómo motiva o incentiva a las personas a participar en estos sistemas? ¿Qué tipos de campos de metadatos deberían usar vocabularios controlados y menús desplegables? ¿Cuándo debería tener un campo de texto libre? ¿Cuántos campos de metadatos puede pedirle a alguien que complete? Establece restricciones sobre los tipos de archivos que alguien puede cargar, valida los archivos que cargan y obligarlos a

______________
93 Una de las mejores piezas sobre las amplias limitaciones y desafíos de establecer y ejecutar repositorios digitales sigue siendo el “Innkeeper at the Roach Motel.” de Salo.

mi resumen. El sistema grabó la fecha de que lo subí. Marqué una casilla para que la tesis estuviera disponible de inmediato y así estuvo disponible en línea. Se puede encontrar en la sección de la Facultad de Educación y Desarrollo Humano de la Colección Electrónica de Tesis y Disertaciones de la GMU. Me imagino que en el pasado un catalogador habría necesitado crear un registro para mi disertación, pero ahora el sistema está configurado para que ese trabajo es transferido al autor de la disertación. Los repositorios institucionales se utilizan para mucho más que disertaciones, contienen cosas como actas de reuniones, podcasts, presentaciones de PowerPoint, conjuntos de datos de investigación, grabaciones de video, etc.

Las fortalezas de este tipo de sistema (en gran medida, que las llaves hayan sido entregadas a los usuarios) son a la vez su mayor debilidad. Es fácil para este tipo de sistemas convertirse en un "motel para cucarachas" donde las personas suben de manera inconsistente y describen inadecuadamente los objetos digitales 93 ya que tienden a funcionar bien para algo como disertaciones, donde es posible insistir en que alguien no pueda graduarse sin depositar su disertación. Pero más allá, este tipo de sistemas tiende a representar de manera desigual los registros de una institución. Es decir, la extensión de este tipo de colecciones vivirá o morirá en función de lo bien que incentive la participación de sus usuarios. Cuando una biblioteca contrata a alguien para describir y catalogar sistemáticamente alguna colección, se termina con metadatos y niveles de descripción altamente consistentes. Cuando se entrega esa función para que cada usuario final de un sistema lo haga, se puede terminar fácilmente con datos irregulares y a la moda. El mismo conjunto de problemas surge en contextos muy diferentes.

StoryCorp.Me Colaboración abierta o "crowdsourcing" de historia oral

Es probable que muchos lectores estén familiarizados con StoryCorps, los fragmentos de entrevistas de historia oral que se comparten cada semana en NPR. Desde 2003, StoryCorp ha recopilado más de 50,000 de esas entrevistas de historia oral recolectadas en cabinas de audio que viajan por todo el país. Esas entrevistas son descritas y almacenadas por el personal y los archiveros de StoryCorps y finalmente archivadas para su preservación en la Biblioteca del Congreso. En 2015 StoryCorps diseñó y lanzó StoryCorp.me, una aplicación móvil que permite a personas de todo el mundo realizar entrevistas de StoryCorp usando su teléfono, ingresar metadatos para ellas y subirlas para incluirlas en el archivo. Como se puede imaginar, esto expandió rápida y dramáticamente el tamaño de la colección. En poco tiempo StoryCorp tuvo más entrevistas desde la aplicación que durante más de una década de recopilar entrevistas desde las cabinas de audio. Debo enfatizar que este caso no es único. Muchas organizaciones utilizan cosas como la plataforma para la publicación de colecciones de código abierto Omeka para crear estas colecciones a partir del crowdsourcing. Estas aplicaciones que recopilaron entrevistas y otros esfuerzos de colaboración colectiva vienen con exactamente el mismo conjunto de problemas potenciales que los materiales en un repositorio institucional. Es decir, como los metadatos de esta colección son generados por el usuario, inevitablemente no serán tan consistentes y completos como los metadatos que los profesionales capacitados han creado en el pasado.

El resultado es que el diseño de la experiencia del usuario, a través de pruebas iterativas del desarrollo de interfaces y flujos de trabajo, se vuelve crítico para la capacidad de este tipo de sistemas. Esto termina siendo una especie de proyecto de investigación en ciencias sociales. ¿Cómo se motiva o incentiva a las personas a participar en estos sistemas? ¿Qué tipos de campos de metadatos se deben usar? ¿Se debería usar vocabularios controlados y menús desplegables? ¿Cuándo se debería tener un campo de texto libre? ¿Cuántos campos de metadatos se le pueden pedir a alguien que complete? ¿Se deben establecer restricciones sobre los tipos de archivos que se pueden subir, o se validan los archivos que se suben y si hace falta información, obligar a los

93 Uno de los mejores textos sobre la extensión de los límites y retos de establecer un repositorio digital funcional sigue siendo el “Innkeeper at the Roach Motel” de Salo.