Hub de Alianzas de Contenido/Metabase/Configuración de una Wikibase desde cero
Content Partnerships Hub
Improving the Wikimedia movement’s work with content partners
Configurar una Wikibase desde cero
En este estudio de caso, describimos los primeros pasos que dimos con Metabase luego de definir su visión y objetivos, desde el lanzamiento de la instancia de Wikibase Cloud hasta el establecimiento de una ontología básica y los desafíos que conlleva.
Configuración inicial
En el momento en que comenzamos nuestra iniciativa (octubre de 2022), Wikibase Cloud estaba en su fase beta cerrada, lo que nos obligó a solicitar acceso anticipado. Este paso ya no es necesario, ya que la plataforma está abierta para todos.
La configuración inicial fue sencilla. Hicimos algunas observaciones que pueden ser útiles para aquellos que se embarquen en un proyecto similar:
- El nombre de la wiki y del primer usuario deben indicarse en el primer paso y no se pueden cambiar fácilmente más adelante.
- En el primer paso, podemos elegir si la wiki debe estar abierta para que todos puedan crear una cuenta de usuario. Decidimos mantenerla abierta para que los miembros interesados de la comunidad puedan unirse a nosotros desde el principio.
- Se puede habilitar el soporte para Lexemes.
- Podemos elegir si queremos asignar propiedades y elementos a Wikidata. Decidimos no hacerlo, ya que en ese momento no estábamos seguros todavía de hasta qué punto lo necesitaríamos. Este paso también se puede realizar más adelante, lo cual terminamos probando con un par de propiedades y elementos, pero no está claro qué tipo de beneficios proporciona.
Consideraciones legales
Existen algunas consideraciones legales que surgen del hecho de que Wikibase Cloud está alojada en un servidor en Alemania. Como todos los sitios web alojados allí, una instancia de Wikibase Cloud está legalmente obligada a tener un sello que indique quién es el propietario y quién la administra, por lo que creamos una en Metabase.
Qué y cómo
Una vez que Wikibase estuvo en funcionamiento, comenzamos a llenarla con datos. El hecho de que la base de conocimientos estuviera completamente vacía nos dio total flexibilidad para decidir cómo queríamos comenzar. Por otro lado, también implicaba que teníamos que diseñar toda la ontología desde cero: tuvimos que decidir cuáles serían los elementos raíz y las primeras propiedades, algo en lo que normalmente no pensamos cuando usamos Wikidata.
Nuestro objetivo era crear un modelo de datos que fuera flexible y fácil de entender para todos, pero también lo más compatible posible con Wikidata. En la sección de información general, profundizamos en la relación entre Metabase y Wikidata: si bien, obviamente, nuestra plataforma tiene algunas necesidades específicas, no queremos que sea "completamente" diferente de Wikidata, teniendo en cuenta la compatibilidad de datos y la facilidad de uso (consultas SPARQL federadas, posible exportación/importación de datos).
Ya que el objetivo de Metabase es contener sólo una pequeña fracción del conocimiento mundial, nuestra ontología no tenía por qué ser tan detallada como la de Wikidata. Gracias a la magia de la federación, al escribir SPARQL, siempre podemos recurrir a Wikidata para utilizar todo el conocimiento recopilado. Nuestros principios rectores fueron los siguientes:
- Diferenciamos entre "elementos de contenido" y "elementos de soporte".
- Los elementos de contenido son las entidades reales en las que se centra Metabase, como documentos, presentaciones de diapositivas, reuniones, etc.
- Los elementos de soporte son todo lo demás que se necesita para modelarlos y que existe en Wikidata, como ubicaciones geográficas, temas, tipos de eventos y documentos, etc.
- Los elementos de contenido, existan o no en Wikidata, son ciudadanos de primera clase de Metabase.
- Los elementos de soporte deben incluir la menor cantidad información posible, idealmente solo un enlace a Wikidata. No necesitamos ni queremos las coordenadas geográficas de Estocolmo ni enlaces a todas las enciclopedias que describen el concepto de "conferencia".
Propiedades
Las primeras propiedades creadas fueron:
Estas propiedades básicas satisfacen una necesidad estructural y crean un marco básico para la creación de contenido.
Una propiedad que tiene un equivalente en Wikidata tiene una notificación sameAs en Wikidata.
Una propiedad sin un equivalente en Wikidata es instancia de propiedad interna de Metabase.
Propiedades internas de Metabase
Las siguientes propiedades (propiedades internas de Metabase) son específicas de Metabase en el sentido de que no tienen equivalentes (uno a uno) en Wikidata. Fueron creadas después de una cuidadosa consideración, ya que evaluamos que eran necesarias para satisfacer nuestras necesidades:
- Descrito en la página de Wikimedia: proporciona una forma de vincular páginas en las plataformas de Wikimedia, ya que Wikibase Cloud no soporta enlaces de sitios web. Por ejemplo, :es:Wikipedia:Encuentros/IV Jornadas de Wikimedia España redirigirá a una página de Wikipedia en español. En concreto, esto nos permite vincular a páginas en las wikis de Wikimedia más allá de lo que se admite a través de enlaces de sitios en Wikidata, como las wikis afiliadas: :wmse:Projekt:Wikipedia_för_hela_Sverige va al WMSE wiki.
- Plataforma(s) Wikimedia afectada(s): permite decir, por ejemplo, que una editatón (maratón de edición) se centró en la edición de Wikipedia en español.
- WMSE project ID : identificador interno único de proyectos realizados por Wikimedia Sverige.
- Clasificado bajo área programática: utilizado internamente por Wikimedia Suecia; cada proyecto que realizamos pertenece a una de las cuatro áreas programáticas/temáticas. Véase también Metabase para datos de capítulos.
Elemento
En la parte superior de la ontología de Metabase se encuentra el elemento raíz de MetaBase, que tiene el subelemento inmediato: elemento raíz de MetaBase que requiere equivalente en Wikidata. La siguiente consulta SPARQL muestra los elementos raíz que creamos. Decidimos que los tipos de elementos más importantes eran cruciales para poder modelar los datos que imaginamos:
Todo lo que hace el Movimiento y que queremos incluir en Metabase es o bien una "actividad" de algún tipo (maratón de edición, conferencia, presentación, proyecto, etc.) o un "documento" publicado (tutorial, informe, publicación de blog, video, presentación de diapositivas, etc.). Todo lo demás está ahí para poder describir esas entidades: quién las organizó o las escribió, dónde tuvieron lugar o de qué se trataba.
Algunas consideraciones específicas sobre el modelado
Desarrollo iterativo desde la base
Antes de empezar a trabajar en la ontología, tuvimos que decidir sobre un flujo de trabajo adecuado. ¿Deberíamos:
- Crear todas las propiedades que creíamos que eran necesarias y luego empezar a crear el contenido, o
- Empezar a crear el contenido y al mismo tiempo crear las propiedades y el modelo de datos?
Nos conformamos con la segunda alternativa: un flujo de trabajo de modelado basado en el contenido. Al principio tuvimos algunas discusiones teóricas sobre casos muy simples: probablemente necesitaremos un modelo para personas, organizaciones, temas, etc. Pero enseguida nos dimos cuenta de que esas discusiones, si bien eran agradables para nuestro cerebro, eran puramente académicas. No sabríamos "exactamente" lo que necesitábamos hasta que realmente lo necesitáramos. Es por eso que decidimos centrarnos en las preguntas con las que necesitábamos ayuda de Metabase y, a partir de ahí, pensar cómo estructurar los datos. Llenar Metabase con contenido provocó debates sobre qué estructuras de datos se necesitaban, y no al revés. Al fin y al cabo, Metabase no cumplirá su propósito hasta que otros miembros del Movimiento la empiecen a utilizar, y la mejor manera de que aprendan es mirar los ejemplos que hemos creado.
Humanos
El enfoque de Metabase no está en los individuos, sino en lo que producen. Por este motivo, decidimos limitar la información sobre las personas a lo necesario para vincularlas con su trabajo y sus productos. Para hacerlo, no necesitamos saber su sexo, fecha de nacimiento o formación académica. La privacidad de los datos también ha sido un punto a considerar; no todos los miembros activos del movimiento Wikimedia tienen elementos Wikidata u otra información pública sobre su vida y trabajo. Ser respetuoso con su información personal es una cuestión no sólo de decencia humana, sino también del Reglamento General de Protección de Datos, que Wikimedia Sverige, como organización con sede en un país de la UE, está legalmente obligada a seguir.
Sólo creamos elementos sobre humanos cuando se necesitan para describir autoría/orador/evento o responsabilidad del proyecto. Y sólo lo hacemos cuando esta información ya está disponible públicamente; cualquier afiliación también tendría que ser comunicada públicamente. Dado que es posible que la afiliación principal no siempre se aplique, puede ser reemplazada por un calificador elemento por elemento.
Algunos Wikimedistas participan en las actividades del Movimiento y son ampliamente conocidos únicamente por sus nombres de usuario. Hemos dejado claro en la documentación que esto debe respetarse y que los contribuyentes no deben publicar su nombre real en caso de saberlo. También hemos observado que algunos mantienen cuentas de usuario separadas cuando participan como personal afiliado y como voluntarios. Puede ocurrir, por ejemplo, que una persona tenga dos presentaciones en una conferencia, una como personal afiliado y otra como voluntario. Si el material de origen deja en claro la distinción: por ejemplo en el programa de la conferencia dice que una presentación está a cargo de Sven Svensson (WMSE) y la otra de Sven123456, entonces pensamos que se deben crear elementos para dos personas incluso si algunas personas saben a quién pertenece la cuenta del voluntario.
Esperamos que al limitar de esto modo la información sobre los humanos, podamos respetar la privacidad de los sujetos y, al mismo tiempo, almacenar los datos sobre autoría o liderazgo de eventos que deseamos.
Términos de índice
Queremos que los usuarios de Metabase puedan encontrar cosas que sean "sobre" otras cosas, por ejemplo, presentaciones sobre la brecha de género o el trabajo con museos de arte. Para ello, Metabase necesita contener los elementos "brecha de género" y "museo de arte", que obviamente existen en Wikidata. Sin embargo, duplicar todo el contenido en museo de arte es totalmente innecesario para Metabase.
Por eso se nos ocurrió el concepto simplificado término de índice.
Un término de índice es una palabra clave que utilizamos para describir, por ejemplo, el tema de un documento o el área de enfoque de un proyecto (usando la propiedad tema principal).
Dentro del alcance de Metabase, la etiqueta es suficiente; no nos preocupamos, por ejemplo, de expresar las relaciones entre los términos del índice. Estos se encuentran en Wikidata y, si es necesario, se pueden consultar mediante consultas federadas.
Es por eso que los únicos datos que proporcionamos para los términos de índice son:
- instancia de → término de índice
- sameAs en Wikidata → Wikidata Q ID
A veces es necesario utilizar como término de índice un elemento que también es otra cosa. En este caso, el elemento puede tener varias declaraciones de instancia de. Por ejemplo:
- La ciudad de Gotemburgo es a la vez un lugar (donde tuvo lugar una conferencia) y un término de índice (porque fue el tema de un maratón de edición).
- Wikipedia sueca es a la vez un proyecto de contenido de Wikimedia (para que podemos describir una maratón de edición en el que se editó, utilizando plataforma(s) de Wikimedia afectada(s)) y un término de índice (porque fue el tema de una presentación o tutorial).
Las plataformas de Wikimedia
Uno de nuestros objetivos es utilizar Metabase para almacenar información sobre actividades en las plataformas de Wikimedia, como editatones y cargas de datos. Las plataformas tienen una estructura jerárquica: las Wikipedias en diferentes idiomas son proyectos hermanos, provenientes de una "Wikipedia" conceptual (aunque no exista). Queremos replicar esta relación jerárquica desde el punto de vista de los usuarios; a veces puede que te interese encontrar todos los editatones con enfoque en Wikipedia, otra veces solo limitados a la versión en un idioma en particular. Además de Wikipedia, hay otros proyectos relevantes para nuestros datos, como Wikidata y Wikimedia Commons.
La estructura de las plataformas de Wikimedia en Metabase es la siguiente:
- familia de proyectos Wikimedia es un elemento raíz.
- proyecto de contenido Wikimedia es un elemento raíz.
- Wikipedia es una familia de proyectos Wikimedia, ya que abarca muchas ediciones de idiomas.
- sueco, inglés, alemán, etc. Las Wikipedias son proyectos de contenido de Wikimedia, así como "partes de" Wikipedia.
- Wikimedia Commons y otros proyectos hermanos de Wikipedia son proyectos de contenido de Wikimedia.
Experiencias que vienen de Wikidata
Como editores experimentados de Wikidata, contribuir a una instancia de Wikibase Cloud debería ser extremadamente fácil. O eso creíamos. En el camino, descubrimos varias diferencias técnicas entre una instancia de Wikibase Cloud y Wikidata, que iban de importantes a levemente molestas. Si bien no nos impidieron progresar, sí nos frenaron al principio.
- Falta de soporte para gadgets y scripts de usuario. Muchos editores experimentados de Wikidata se enorgullecen de su entorno de trabajo personalizado, posiblemente sin siquiera saber cómo se ve una interfaz desnuda de Wikibase. Los escritores estaban anhelando especialmente Merge, LabelLister, DuplicateReferences y MoveClaim. Tampoco es posible implementar archivos JavaScript o CSS propios para personalizar la interfaz.
- Número limitado de extensiones. En comparación con Wikidata, Wikibase Cloud no viene con varias de las extensiones familiares para los wikimedistas. En el espacio para nombres de Elementos, la falta de la funcionalidad Sugerencias de Propiedades es lo que más se hace notar: ni siquiera nos habíamos dado cuenta de cuánto tiempo y esfuerzo mental ahorra su uso en Wikidata. Fuera del espacio para nombres de Elementos, Translate (traducir) y VisualEditor (editor visual) son particularmente necesarios. No poder utilizarlos afectó nuestra eficiencia en la edición de las páginas de documentación, como las pautas de modelado. Después de todo, cuando se trata de crear tablas en VisualEditor, estamos completamente mal acostumbrados. Y sin la extensión Translate, nuestros futuros usuarios no podrán crear fácilmente versiones en sus idiomas preferidos, lo que tendrá un enorme impacto negativo en nuestra capacidad para introducir y abogar por Metabase en la comunidad global.
- No se muestran imágenes de Wikimedia Commons. Esto supuso un obstáculo menor pero doloroso a la hora de describir nuestro modelado: a veces una imagen dice más que mil palabras (y es la verdadera razón por la que no estás leyendo este artículo en Metabase).
- La herramienta Cradle no funciona correctamente, sino que busca elementos en Wikidata. El problema ha sido señalado en Phabricator, ya que hay otros usuarios de Wikibase Cloud a quienes les gustaría poder usar Cradle.
- Falta de restricciones de propiedad, es decir reglas sobre propiedades que especifican cómo deben usarse. Como editores de Wikidata, es muy conveniente recibir una notificación inmediata cuando se establece un valor posiblemente erróneo en una propiedad, ya sea porque no estamos familiarizados con las convenciones o simplemente por accidente. En Metabase, hemos intentado evitar esto escribiendo un conjunto de consultas SPARQL para detectar errores y discrepancias comunes, pero no es tan efectivo ni tan fácil de usar como las advertencias de restricciones automáticas.
- Falta de soporte interwiki para los proyectos Wikimedia. Lo cual motivó la creación de la propiedad descrita en la página de Wikimedia.
- Al escribir consultas SPARQL, se requieren declaraciones de prefijo, por ejemplo:
PREFIX wb: <https://metabase.wikibase.cloud/entity/> PREFIX wbt: <https://metabase.wikibase.cloud/prop/direct/>
Conclusiones
En resumen, configurar una instancia de Wikibase Cloud es simple desde el punto de vista técnico. Cabe señalar que no habíamos intentado trabajar con instancias autoalojadas de Wikibase, por lo que no podemos hacer una comparación razonable en este sentido. Las verdaderas dificultades comienzan en el nivel conceptual, al diseñar e implementar nuestra ontología básica. Por supuesto, estas dificultades serán las mismas independientemente de si uno trabaja en la nube o en su propio servidor: cualquiera puede configurar el software, pero diseñar una ontología requiere un alto nivel de pensamiento abstracto, en el que no somos expertos.
¿Estás pensando en crear tu propia instancia de Wikibase Cloud? Estas son algunas cosas que aprendimos al configurar y preparar Metabase para la entrada de datos:
- Decide qué quieres lograr, en lugar de cómo. ¿Qué consultas deseas ejecutar? A partir de ahí, comienza a diseñar la ontología.
- Prepárate para el hecho de que diseñar una ontología desde cero es más difícil de lo que parece. Estar acostumbrado a Wikidata puede ayudar, pero también puede ser un obstáculo. Al cerebro humano le gusta aquello con lo que está familiarizado, pero nosotros explícitamente "no queríamos ni necesitábamos" ser tan detallados como Wikidata.
- Decide con anticipación qué nivel de compatibilidad con Wikidata se desea alcanzar.
- Piensa en tu grupo objetivo: tanto usuarios de datos como contribuyentes. ¿Estarán todos ellos íntimamente familiarizados con el tema, o tienes previsto involucrar activamente a usuarios externos? Esto influirá en la forma de concebir la ontología y su complejidad.