Objetivo
Valorar si y cómo la spec debería modelar quién da la charla, algo que hoy es un hueco explícitamente reconocido y no una omisión accidental.
Por qué no está ya resuelto
README.md — "What v0.3 does not solve": "modelling speakers/agenda/sponsors" aparece listado junto a deduplicación, sincronización y la caja registradora como lo que v0.3 no resuelve.README.md — sección organizers lo dice todavía más explícito, como una de las "tres confusiones" que hay que desactivar: "organizers are not speakers. Whoever gives the talk is not modelled in v0.3 (...). Putting a speaker in organizers corrupts the data for everyone who consumes it."
Es decir: la spec ya sabe que el hueco existe y ya avisa contra la solución incorrecta (meter al ponente en organizers), pero no ofrece ninguna alternativa.
Por qué importa
Un directorio o agregador que quiera mostrar "quién habla" en una charla — el caso más simple, un meetup con un único ponente — no tiene dónde ponerlo hoy sin inventarse una extensión no prefijada por evento, lo cual no es interoperable entre productores.
Preguntas a resolver (no una propuesta cerrada)
- ¿Un solo ponente por evento, o una lista? Con el patrón ya usado en
organizers/image, nace como lista si hay un productor real que emita varios (co-charlas, mesas redondas).
- ¿Qué campos mínimos? Nombre es obligatorio casi seguro; ¿bio, foto, enlaces sociales, afiliación? El principio ya aplicado en
organizers ("nada de logo, nada de identificadores, describe quién organiza y dónde escribirle") probablemente aplica igual aquí: lo mínimo hasta que un productor real pida más.
- ¿Va en el evento, o solo tiene sentido si primero se resuelve #issue-multipart (charlas como partes de una conferencia)? Si una conferencia se modela como evento único (un devfest de un día), un
speakers a nivel de evento tiene sentido. Si se modela como partOf/multipart con una parte por charla, el campo natural sería por-parte, no por-conferencia — esto conecta directamente con la discusión de multi-part events.
- Traducción a los tres destinos: schema.org tiene
performer/Person en Event; iCalendar no tiene equivalente (fuera de ATTENDEE, que significa otra cosa); RSS/Atom, ninguno. ¿Se acepta la misma pérdida que ya se acepta para offers/cfp?
Alcance
Este issue no propone tocar spec/v0.3/. Es candidato a evaluarse en el track de auditoría de la spec (RESUME-SCHEMA-AUDIT.md) como posible P034+, o a discutirse aquí primero para acotar la forma antes de proponer un schema concreto — como se hizo en #26.
Objetivo
Valorar si y cómo la spec debería modelar quién da la charla, algo que hoy es un hueco explícitamente reconocido y no una omisión accidental.
Por qué no está ya resuelto
README.md— "What v0.3 does not solve": "modelling speakers/agenda/sponsors" aparece listado junto a deduplicación, sincronización y la caja registradora como lo que v0.3 no resuelve.README.md— secciónorganizerslo dice todavía más explícito, como una de las "tres confusiones" que hay que desactivar: "organizersare not speakers. Whoever gives the talk is not modelled in v0.3 (...). Putting a speaker inorganizerscorrupts the data for everyone who consumes it."Es decir: la spec ya sabe que el hueco existe y ya avisa contra la solución incorrecta (meter al ponente en
organizers), pero no ofrece ninguna alternativa.Por qué importa
Un directorio o agregador que quiera mostrar "quién habla" en una charla — el caso más simple, un meetup con un único ponente — no tiene dónde ponerlo hoy sin inventarse una extensión no prefijada por evento, lo cual no es interoperable entre productores.
Preguntas a resolver (no una propuesta cerrada)
organizers/image, nace como lista si hay un productor real que emita varios (co-charlas, mesas redondas).organizers("nada de logo, nada de identificadores, describe quién organiza y dónde escribirle") probablemente aplica igual aquí: lo mínimo hasta que un productor real pida más.speakersa nivel de evento tiene sentido. Si se modela comopartOf/multipartcon una parte por charla, el campo natural sería por-parte, no por-conferencia — esto conecta directamente con la discusión de multi-part events.performer/PersonenEvent; iCalendar no tiene equivalente (fuera deATTENDEE, que significa otra cosa); RSS/Atom, ninguno. ¿Se acepta la misma pérdida que ya se acepta paraoffers/cfp?Alcance
Este issue no propone tocar
spec/v0.3/. Es candidato a evaluarse en el track de auditoría de la spec (RESUME-SCHEMA-AUDIT.md) como posible P034+, o a discutirse aquí primero para acotar la forma antes de proponer un schema concreto — como se hizo en #26.