page_0101

OverviewVersionsHelp

Here you can see all page revisions and compare the changes have been made in each revision. Left column shows the page title and transcription in the selected revision, right column shows what have been changed. Unchanged text is highlighted in white, deleted text is highlighted in red, and inserted text is highlighted in green color.

17 revisions
ac at Dec 29, 2020 08:37 PM

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.


Translation

en 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. Puede encontrarlo en la sección de la Facultad de Educación y Desarrollo Humano de la Colección Electrónica de Tesis y Disertaciones 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, que las llaves han sido entregadas a los usuarios) son simultáneamente 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 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 tenderá a representar de manera desigual 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. Cuando una biblioteca contrata a alguien para describir y catalogar sistemáticamente alguna colección, terminas con metadatos y niveles de descripción altamente consistentes. Cuando entrega esa función para que cada usuario final individual de un sistema lo haga, puede terminar fácilmente con datos irregulares e irregulares. El mismo conjunto de problemas surge en contextos muy diferentes.

StoryCorp.Me Crowdsourcing Oral Story

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 durante más de una década de recopilar entrevistas desde los stands. 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 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 de esto es que el diseño de la experiencia del usuario, haciendo pruebas iterativas en el 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 motiva o incentiva a las personas a participar en estos sistemas? ¿Qué tipos de campos de metadatos se deben usar? ¿Debería 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, o valida los archivos que cargan y los obliga a

93 One of the best pieces on the extensive limitations and challenges of establishing and running digital repositories remains Salo´s “Innkeeper at the Roach Motel.”

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.


Translation

en 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. Puede encontrarlo en la sección de la Facultad de Educación y Desarrollo Humano de la Colección Electrónica de Tesis y Disertaciones 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, que las llaves han sido entregadas a los usuarios) son simultáneamente 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 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 tenderá a representar de manera desigual 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. Cuando una biblioteca contrata a alguien para describir y catalogar sistemáticamente alguna colección, terminas con metadatos y niveles de descripción altamente consistentes. Cuando entrega esa función para que cada usuario final individual de un sistema lo haga, puede terminar fácilmente con datos irregulares e irregulares. El mismo conjunto de problemas surge en contextos muy diferentes.

StoryCorp.Me Crowdsourcing Oral Story

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 durante más de una década de recopilar entrevistas desde los stands. 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 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 de esto es que el diseño de la experiencia del usuario, haciendo pruebas iterativas en el 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 motiva o incentiva a las personas a participar en estos sistemas? ¿Qué tipos de campos de metadatos se deben usar? ¿Debería 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, o valida los archivos que cargan y los obliga a

93 One of the best pieces on the extensive limitations and challenges of establishing and running digital repositories remains Salo´s “Innkeeper at the Roach Motel.”