el IFC es el mal

20240128

BIM, IFC y ontologías, Opinión y Crítica

Según dicen, el esperanto fue un intento de generar una lengua neutra universal para mejorar la comunicación entre las personas. Un poco idealista ¿no?

Ilustración generada por IA. Ontologías Abiertas

Contenido:

«ontologías abiertas» CC-by-sa Miguel Villegas Ballesta ¹

¿Os suena algo parecido en la industria AECOM? Se llama IFC (y añadidos) y podemos hacer la analogía a que el Dr. Zamenhof, inventor del esperanto, es la actual building Smart, una asociación de profesionales que dedican su tiempo y energía a la magna empresa de generar una lengua franca que mejore los procesos de comunicación en el seno de la industria.

¿Por qué el IFC (etc.) me parece una empresa absurda?

Me vais a permitir que la lista refleje los aspectos que me parecen subjetiva y personalmente un incordio, son todos reflejo de mi opinión personal y, como siempre, pueden ser objeto de discusión:

El IFC es internacional, pero está en inglés. Eso genera problemas de comprensión a muchísima gente, (y no me vayáis a fardar de bilingües que saco el C2 y se acaba el tema…). Hay muchísima gente que dice que entiende las definiciones de la buildingSmart, pero después de ver cómo traducen-usan el IFC mucho me temo que no es verdad.

Es anisótropo. Algunas disciplinas están hiperespecificadas y otras están así ya y tal. Ifc*Flow frente a IfcWall p.e. No sé… me resulta raro… ¿será porque las ingenierías se lo están tomando más en serio?

Implica interpretación. En un proceso BIM ortodoxo, tenemos los requerimientos de información del cliente y tenemos nuestra información. El IFC está ahí para servir como contenedor para poder trasladar nuestra información desde nuestros programas de creación de contenido a los programas de lectura de contenido de los clientes. Como objetivo esta muy bien, salvo por que el IFC como estructura contenedora tiene una capa semántica que es necesario (si nos adscribimos a su uso) mantener.

Esto implica que tenemos realizar un proceso de traducción múltiple (^2 si consideramos el factor del inglés):

Tenemos que enteder la información que el cliente nos está pidiendo.
Tenemos que casar esa información que el cliente nos pide con la información que nosotros tenemos/somos capaces de proveer.
Tenemos que buscar en la ontología IFC cuales son las entidades y las propiedades correspondientes en las que esa información que tenemos nosotros encaja.
Tenemos que acordar con el cliente y el resto de agentes del proceso BIM esos contenedores como aptos para el intercambio de información…

Ya lo vimos en el grandísimo Bill Murray… muchas cosas se pueden quedar Lost in Translation.

¿Cuál sería mi alternativa ideal? Las ontologías abiertas.

En una industria en la que, incluso en proyectos de gran tamaño, con clientes de talla regional nos enfrentamos a trabajar con estándares muy, muy específicos ¿qué sentido tiene trabajar con ese esperanto que es el IFC?

¿No es más fácil trabajar proponiendo una ontología, una estructura operativa preparada para cada proyecto? Aquí me vais a permitir que me moje. En la tesis, construí una aplicación práctica de lo que propongo.

Es posible y operativo trabajar con una estructura de información ad-hoc, e.d. generada expresamente para un caso concreto; susceptible de ser trabajada con herramientas digitales mediante procesos de interpretación muy directos. Es decir un catálogo por proyectos. Definiciones claras y concisas acordadas por todas las partes y asignadas en forma de diccionarios clave-valor asignados a geometrías elementales que todos los agentes puedan leer e interpretar.

¿Por qué cuestionar lo que funciona?

Pues realmente, quizás lo que deberíamos hacer es preguntarnos si realmente funciona… y me vais a permitir una opinión muy personal y que quizás moleste a mucha gente que se está partiendo la espalda para hacer desarrollos muy buenos sobre la ontología IFC. Creo que el problema es que el IFC es lo que hay… y todos piensan ¿para qué reinventar la rueda?

Pues fundamentalmente porque esa rueda es un polígono de n-lados que rueda regular y que no sirve para todos nuestros vehículos…

No soy el primero en cuestionarme este tema² ³ ; pero quizás la propuesta más interesante, en tanto que creo que concuerda con mi propuesta es la que Pixar ha hecho con su USD o Universal Scene Description .

Aquí, a pesar de haberme peleado mucho y a fondo con el IFC, la definición de ontologías y el mapeado de información; me falla el conocimiento profundo que los hacedores tienen, pero sigo permitiéndome opinar.

Si la industria de la animación y videojuegos, que maneja tanta o más información que nosotros en los proyectos; considera que esta estructura de Prims (primitivas abiertas definidas por proyecto) funciona ¿por qué no es aplicable en arquitectura?

Es posible y altamente productivo

Lo demostré en su momento en la tesis ⁴. Construí una estructura informacional y la máquina que la transformaba en un modelo BIM coherente. Evité cualquier tipo de vinculación con la ontología IFC porque me interesaba trabajar con información fenomenológica, con la abstracción de las etapas iniciales de diseño; pero lo que conseguí demostrar es que este tipo de información, y en general cualquier tipo de información es manipulable siempre que esté mínimamente estructurada.

Lo que defiendo entonces es que no necesitamos esa estructura externa impuesta por terceros que es el IFC…

Mientras tanto…

como es lo que hay y no hay perspectivas de que nadie se arremangue y se ponga a hacer prims específicos para arquitectura, me vais a permitir que me ponga a investigar a fondo con OpenBIM en Blender, que de momento parece ser la iniciativa más sólida y fuerte de investigación y desarrollo sobre este estándar dichoso.

«ontologías abiertas» CC-by-sa Miguel Villegas Ballesta.
Imagen generada mediante IA con el prompt «isolated white background:: a white column like this one https://s.mj.run/NqCqsZpfX6U the column top part transforms into a neural network like object like this one https://s.mj.run/Cd7q2u7HWzM –ar 1:1 – Upscaled (2x) by <@586635106412789772> (fast)» ↩︎
Manu Venugopal, Charles M. Eastman, y Jochen Teizer, «An ontology-based analysis of the industry foundation class schema for building information model exchanges», Advanced Engineering Informatics, Collective Intelligence Modeling, Analysis, and Synthesis for Innovative Engineering Decision Making, 29, n.o 4 (1 de octubre de 2015): 940-57, https://doi.org/10.1016/j.aei.2015.09.006. ↩︎
Mads Holten Rasmussen et al., «Proposing a Central AEC Ontology That Allows for Domain Specific Extensions», en Proceedings of the Joint Conference on Computing in Construction (JC3), vol. 1, 2017, 237-44, https://doi.org/10.24928/JC3-. ↩︎
Villegas Ballesta, Miguel. «Informational Architecture: A Postgraphical Knowledge Model for Architectural Design», 21 de julio de 2022. https://idus.us.es/handle/11441/138108. ↩︎

Miguel Villegas Ballesta, doctor arquitecto.

20240128

6 respuestas a «el IFC es el mal»

Carlos Villagrasa

febrero 10, 2024 at 9:43 pm

Hola, antes de nada, creo que el titular choca un poco y sentencias tan contundentes deberían ir acompañadas de argumentaciones a la altura. Al hilo de lo hablado en Twitter (https://twitter.com/arquitextonica/status/1754240391400845748), trato de explicar por qué creo justamente en lo contrario: que darle más peso a IFC en nuestro trabajo diario es una gran oportunidad para reducir muchos de los dolores de cabeza que tenemos en el sector.

Creo que podremos estar de acuerdo en que en general, en el ámbito AEC, andamos un poco atrasados en lo que a digitalización se refiere. En cierto grado, nos influyen las políticas de Autodesk, que podríamos resumir en exprimir Revit al límite para dar beneficios a corto plazo, dando por perdida la tarea de refactorizar una base de código con 30 años de antigüedad. Obviamente, esa estrategia tiene fecha de caducidad, y es algo preocupante teniendo en cuenta que son líderes del mercado. Está por ver cómo evolucionan ACC, Forma o lo que sea que estén planeando como sucesor, pero de momento, tenemos a casi todo el sector a nivel mundial utilizando un programa lento, que no es todo lo fiable que debería y que ya no va a mejorar mucho más (reconocido públicamente por Anagnost el año pasado), sin alternativa clara a la vista.

Al mismo tiempo, tenemos varias «Open Letters» a Autodesk y una frustración generalizada con lo mal que funciona la famosa interoperabilidad en la mayoría de los flujos de trabajo. Y en ese contexto, va y cala que el problema es precisamente IFC, y aparecen artículos como este, sin profundizar en exactamente qué problemas específicos se le achacan a IFC y por qué alguna otra alternativa (ontologías abiertas incluidas) es la solución definitiva.

Y sí, soy consciente de que IFC lo creó ni más ni menos que Autodesk, e incluso de que a día de hoy son los que más influencia tienen en bSI, pero eso no quita que al ser un estándar libre, en la industria no nos podamos beneficiar de lo que ya está ahí y utilizarlo como referencia. En el caso de que tenga sentido, claro está. Si es una causa perdida, pues obviamente será mejor ignorarlo y centrarse en otra cosa. Pero para discernir un caso del otro, no queda más remedio que entrar en materia y poner argumentos a un lado u otro de la balanza.

En mi opinión, una de las personas que mejor ha sabido leer la situación que comento (que IFC es libre, ya está ahí y aprovechar lo positivo que nos pueda aportar nunca puede restar) es Dion Moult, el desarrollador principal de BlenderBIM. Estudió IFC a nivel maestro Jedi, con especial mérito por hacerlo en un momento en el que era aún mucho menos popular de lo que es hoy, y se dio cuenta de que no solo no es equivalente a un PDF, ni algo mal planteado de base, si no que en realidad es tremendamente completo. Otra cosa diferente es que el software establecido importe y exporte auténticos desastres que no lo aprovechen ni al 50%, o que se hayan hecho los inventos de los MVDs + certificaciones que no sirven de mucho.

Pero ese último punto habla más de las limitaciones (intencionadas o no) de Revit y el resto de software BIM, y de la estrategia de Autodesk + bSI, que de las capacidades de IFC propiamente. Como curiosidad relacionada, nunca está de más compartir este «cariñoso» artículo de Dion al respecto de Revit. Sirva como ejemplo de que se puede elegir un titular contundente y ser al mismo tiempo igual de contundente en su desarrollo.
https://thinkmoult.com/why-revit-is-shit.html

Volviendo al esquema, en IFC podemos crear un plan de obra con diagramas de Gantt, mediciones, presupuestos, definir jerarquías espaciales… la geometría es opcional! Y no solo hay cabida para un contexto 3D, podemos tener representaciones de los elementos en contextos 2D, o planos al completo como en BlenderBIM. Además, las representaciones en 3D no solo pueden ser BReps o mallas triangulares, si no también extrusiones, CSGs, BSplines… y por si fuera poco, también podemos tener redes de instalaciones (IfcPorts), modelos estructurales con sus cargas y esfuerzos, modelos de simulación energética, de simulación lumínica, materiales con estilos de visualización y texturas, etc. Además, soporta otros sistemas de clasificación como Omniclass, Uniclass, y la extensión mediante conjuntos de propiedades a gusto del consumidor. Vaya, que no estamos ante cuatro clases inconexas colocadas ahí a la ligera.

Entonces, paremos un momento… tenemos un panorama actual en el que los flujos de trabajo son altamente ineficientes. La prueba y error o la pérdida de información al moverse entre diferente software se han asentado en el día a día de muchos. Cartas abiertas pidiendo soluciones, Autodesk diciendo que no habrá ningún «faster horse»… y mientras tanto, IFC, con toda sus funcionalidad, está ahí todo el tiempo. Y qué hace el sector? enseñar en los másters BIM que IFC = lo que exporta Revit = PDF, y que donde esté un archivo nativo, que se quite lo demás. Y mientras tanto, Autodesk dificultando el pagar sus licencias de forma correcta y poniendo multas.

No puede ser que un arquitecto con la suficiente motivación implemente él solo (Dion dirá humildemente que con ayuda de algunos más) la edición nativa de IFC en Blender, y nos tengamos que creer que Revit y compañía no son capaces de manejar extrusiones en lugar de Breps, utilizar tipos, geolocalizar correctamente o generar descomposiciones espaciales con algo de sentido, y que ello sea porque el esquema IFC no da más de sí.

Estoy diciendo entonces que IFC es la perfección hecha esquema? Ni mucho menos. Tiene sus cosas, como forzar grafos en forma de árbol, que por ejemplo impiden que un mismo hueco vacíe más de un elemento, o no dar entidad de raíz (IfcRoot) a todos los elementos, lo cual dificulta un poco el control de versiones. Pero todas tienen una solución u otra, y además, al ser de código abierto, cualquiera puede abrir un tiquet y colaborar con propuestas de mejora para las siguientes versiones (IFC4x4 e IFC5). Te invito a exponer por allí aquellos puntos donde en tu experiencia el esquema se haya quedado corto:
https://github.com/buildingSMART/IFC4.4.x-development/issues
https://github.com/buildingSMART/NextGen-IFC/issues

El mero hecho de que estos mecanismos existan, y que lleven en marcha años, ayuda a mejorar la calidad del esquema. Está todo muy probado, va a haber pocas sorpresas. De una ontología abierta, difícilmente se podrá decir lo mismo. Además, el asentar estándares potencia que crezca un ecosistema de productividad alrededor, como va pasando con planes BIM, ISO 19650, IDS y compañía. En mi opinión, un esquema como IFC no es una amalgama de idiomas como el Esperanto, es simplemente un idioma, una referencia. Para poder ser bilingües y hablar de qué idioma es mejor, o incluso para inventar un idioma nuevo cada vez, primero tenemos que saber comunicarnos dentro de un marco común. Hoy por hoy, en el sector AEC lo estamos haciendo con señales de humo. Y no hace falta que cada modelador BIM aprenda IFC a nivel avanzado, con que incentivemos a los desarrolladores de software a que apuesten en esa dirección, nos beneficiaremos todos. Con ese hito conseguido, con una referencia a la cual medirse, ya tendrá más sentido entrar en discusiones técnicas sobre alternativas mejores.

Por cierto, USD es otra cosa, no es otro esquema mejor en tanto que más abierto. Que me corrija alguien que sepa más si me equivoco, pero toda la externalización de datos que promueve es compatible con IFC, de hecho me suena que nVidia lo estaba explorando para su Omniverse. De todas formas, no creo que a cortísimo plazo tengamos que estar pendientes de cómo serializamos los modelos en la nube si aún tenemos dudas sobre las ontologías en las que organizamos nuestros datos, incluso en nuestro disco duro local. En cualquier caso, me parece que para IFC5 están trabajando con USD en mente.

Es todo, perdón por el ladrillo clasificable como IfcSlab ;). Pero realmente es un tema que genera división y por todo lo expuesto, creo que haríamos bien como gremio en darle a IFC el poco impulso que aún le falta, y en exigir a nuestros proveedores de software que lo importen y exporten como se debe.

Responder
1. Miguel Villegas Ballesta, doctor arquitecto.
  
  febrero 11, 2024 at 6:39 pm
  
  Carlos, lo primero agradecerte el ladrillo. Empezamos la discusión un poco acaloradamente, pero nuestros buenos modales y lo interesante de tus argumentos nos permitión reconducirla productivamente. Intento contestarte párrafo a párrafo para mentener la coherencia.
  
  Se ve raro que tus textos sean los sangrados cuando son los originales, pero es por preservar la estructura semántica
  
  Al turrón…
  
  Hola, antes de nada, creo que el titular choca un poco y sentencias tan contundentes deberían ir acompañadas de argumentaciones a la altura. Al hilo de lo hablado en Twitter ([https://twitter.com/arquitextonica/status/1754240391400845748](https://twitter.com/arquitextonica/status/1754240391400845748)), trato de explicar por qué creo justamente en lo contrario: que darle más peso a IFC en nuestro trabajo diario es una gran oportunidad para reducir muchos de los dolores de cabeza que tenemos en el sector.
  
  Creo que podremos estar de acuerdo en que en general, en el ámbito AEC, andamos un poco atrasados en lo que a digitalización se refiere. En cierto grado, nos influyen las políticas de Autodesk, que podríamos resumir en exprimir Revit al límite para dar beneficios a corto plazo, dando por perdida la tarea de refactorizar una base de código con 30 años de antigüedad. Obviamente, esa estrategia tiene fecha de caducidad, y es algo preocupante teniendo en cuenta que son líderes del mercado. Está por ver cómo evolucionan ACC, Forma o lo que sea que estén planeando como sucesor, pero de momento, tenemos a casi todo el sector a nivel mundial utilizando un programa lento, que no es todo lo fiable que debería y que ya no va a mejorar mucho más (reconocido públicamente por Anagnost el año pasado), sin alternativa clara a la vista.
  
  Si te ha chocado el titular… perdón era puro clickbait y como decía después, los argumentos son muy, muy personales, aunque me alegro que te hayan invitado a discutir.
  
  Totalmente de acuerdo. Autodesk es el origen de todos los males. No en vano son unos de los fundadores de la alianza para desarrollar IFC… Ya nos enganchaban en los 90 con versiones facilmente pirateables de Autocad y ahora siguen con Revit con una deuda tecnológica terrible que nos encadena y arrastra. El cambio de objetivo con el que ya solo hacen caso a promotoras y constructoras, que a fin de cuentas son los que fuerzan el uso de las plataformas es otra condena más… no le veo fácil solución… o si.
  
  Al mismo tiempo, tenemos varias «Open Letters» a Autodesk y una frustración generalizada con lo mal que funciona la famosa interoperabilidad en la mayoría de los flujos de trabajo. Y en ese contexto, va y cala que el problema es precisamente IFC, y aparecen artículos como este, sin profundizar en exactamente qué problemas específicos se le achacan a IFC y por qué alguna otra alternativa (ontologías abiertas incluidas) es la solución definitiva.
  
  ¿Problemas específicos?… bueno, lo detallé en 500 y pico de páginas en la tesis, pero un artículo de un blog de divulgación da para lo que da… además. Creo que quedaba claro que para mi los problemas de IFC no son específicos ni se van a solucionar con IFC5… para mi el IFC es un problema de base, de filosofía, de objetivos… ¿una ontología universal? lo siento, pero eso YA es suficiente problema. Entrar en detalle es meterse en poner parches que no solucionan el origen de todo.
  
  Y sí, soy consciente de que IFC lo creó ni más ni menos que Autodesk, e incluso de que a día de hoy son los que más influencia tienen en bSI, pero eso no quita que al ser un estándar libre, en la industria no nos podamos beneficiar de lo que ya está ahí y utilizarlo como referencia. En el caso de que tenga sentido, claro está. Si es una causa perdida, pues obviamente será mejor ignorarlo y centrarse en otra cosa. Pero para discernir un caso del otro, no queda más remedio que entrar en materia y poner argumentos a un lado u otro de la balanza.
  
  En mi opinión, una de las personas que mejor ha sabido leer la situación que comento (que IFC es libre, ya está ahí y aprovechar lo positivo que nos pueda aportar nunca puede restar) es Dion Moult, el desarrollador principal de BlenderBIM. Estudió IFC a nivel maestro Jedi, con especial mérito por hacerlo en un momento en el que era aún mucho menos popular de lo que es hoy, y se dio cuenta de que no solo no es equivalente a un PDF, ni algo mal planteado de base, si no que en realidad es tremendamente completo. Otra cosa diferente es que el software establecido importe y exporte auténticos desastres que no lo aprovechen ni al 50%, o que se hayan hecho los inventos de los MVDs + certificaciones que no sirven de mucho.
  
  No voy a poner en cuestión la valía del trabajo de Moult, más cuando de cada tres consultas que hago sobre IFC, cuatro las resuelvo con contenido que ha publicado en internet desinteresadamente. Es sin duda uno de los (si no el mayor) paladines de IFC… pero eso no lo valida. No es suficiente. Que él sepa usarlo a la perfección no lo hace válido para todos. Me remito a mi argumento del esperanto… Y abundando. Entiendo que el artículo de Moult es lo que esperabas de este, pero obvia cuál es el origen del mal en Revit (deuda tecnológica y filosofía de empresa…)
  
  Pero ese último punto habla más de las limitaciones (intencionadas o no) de Revit y el resto de software BIM, y de la estrategia de Autodesk + bSI, que de las capacidades de IFC propiamente. Como curiosidad relacionada, nunca está de más compartir este «cariñoso» artículo de Dion al respecto de Revit. Sirva como ejemplo de que se puede elegir un titular contundente y ser al mismo tiempo igual de contundente en su desarrollo.
  https://thinkmoult.com/why-revit-is-shit.html
  
  Volviendo al esquema, en IFC podemos crear un plan de obra con diagramas de Gantt, mediciones, presupuestos, definir jerarquías espaciales… la geometría es opcional! Y no solo hay cabida para un contexto 3D, podemos tener representaciones de los elementos en contextos 2D, o planos al completo como en BlenderBIM. Además, las representaciones en 3D no solo pueden ser BReps o mallas triangulares, si no también extrusiones, CSGs, BSplines… y por si fuera poco, también podemos tener redes de instalaciones (IfcPorts), modelos estructurales con sus cargas y esfuerzos, modelos de simulación energética, de simulación lumínica, materiales con estilos de visualización y texturas, etc. Además, soporta otros sistemas de clasificación como Omniclass, Uniclass, y la extensión mediante conjuntos de propiedades a gusto del consumidor. Vaya, que no estamos ante cuatro clases inconexas colocadas ahí a la ligera.
  
  En mis argumentos no pongo falta ninguna a todo lo que YA se puede hacer con IFC que es mucho y bueno… y tampoco digo (válgame) que Revit sea la solución… ni mucho menos.
  
  Entonces, paremos un momento… tenemos un panorama actual en el que los flujos de trabajo son altamente ineficientes. La prueba y error o la pérdida de información al moverse entre diferente software se han asentado en el día a día de muchos. Cartas abiertas pidiendo soluciones, Autodesk diciendo que no habrá ningún «faster horse»… y mientras tanto, IFC, con toda sus funcionalidad, está ahí todo el tiempo. Y qué hace el sector? enseñar en los másters BIM que IFC = lo que exporta Revit = PDF, y que donde esté un archivo nativo, que se quite lo demás. Y mientras tanto, Autodesk dificultando el pagar sus licencias de forma correcta y poniendo multas.
  
  No puede ser que un arquitecto con la suficiente motivación implemente él solo (Dion dirá humildemente que con ayuda de algunos más) la edición nativa de IFC en Blender, y nos tengamos que creer que Revit y compañía no son capaces de manejar extrusiones en lugar de Breps, utilizar tipos, geolocalizar correctamente o generar descomposiciones espaciales con algo de sentido, y que ello sea porque el esquema IFC no da más de sí.
  
  Creo que no estoy haciendo precisamente lo que está haciendo el sector… llevo muchos años remando a contra corriente y aunque los ejemplos de arquitectos en empresas gigantescas de mucho éxito son notables (David Rutten con Grasshopper, Dion Moult con BlendeBIM, Javier González Viegas con IFC.js) la cantidad de yonquis tecnológicos que tiene Autodesk enganchados a sus productos es ingente… Seguro que sabes lo que implica un salto de versión de Revit en un estudio ¿verdad? Nos tienen atrapados
  
  Estoy diciendo entonces que IFC es la perfección hecha esquema? Ni mucho menos. Tiene sus cosas, como forzar grafos en forma de árbol, que por ejemplo impiden que un mismo hueco vacíe más de un elemento, o no dar entidad de raíz (IfcRoot) a todos los elementos, lo cual dificulta un poco el control de versiones. Pero todas tienen una solución u otra, y además, al ser de código abierto, cualquiera puede abrir un tiquet y colaborar con propuestas de mejora para las siguientes versiones (IFC4x4 e IFC5). Te invito a exponer por allí aquellos puntos donde en tu experiencia el esquema se haya quedado corto:
  https://github.com/buildingSMART/IFC4.4.x-development/issues
  https://github.com/buildingSMART/NextGen-IFC/issues
  
  ¡Ojalá tuviera la capacidad, el conocimiento y el tiempo de proponer y demostrar haciendo como han hecho tantos otros compañeros! Pero mis limitaciones son esas y profundas… Esto no resta para que tenga una opinión crítica y formada en muchos años de estudio, experiencia y uso. Que también son… todavía me acuerdo cuando el mismo David Rutten me contestó en el foro de grasshopper a una sugerencia y sirvió para que el componente de subdivisión de superficies funcionara un poquito mejor.
  
  No se si lo has podido ver, pero en youtube tengo una serie de video-demos de la propuesta que construí para la tesis. Un cacharro que usa ontologías abiertas sobre bocetos 2D y permite al usuario generar un modelo BIM coherente… el que lo hiciera en Grasshopper y RhinoInside en Revit es sólo fruto de mi incompetencia… un proyecto que tengo a largo plazo es hacerlo en Blender, con GeometryNodes y TopologicPy, para generar un IFC bueno como salida final… pero ¡falta tiempo!
  
  El mero hecho de que estos mecanismos existan, y que lleven en marcha años, ayuda a mejorar la calidad del esquema. Está todo muy probado, va a haber pocas sorpresas. De una ontología abierta, difícilmente se podrá decir lo mismo. Además, el asentar estándares potencia que crezca un ecosistema de productividad alrededor, como va pasando con planes BIM, ISO 19650, IDS y compañía. En mi opinión, un esquema como IFC no es una amalgama de idiomas como el Esperanto, es simplemente un idioma, una referencia. Para poder ser bilingües y hablar de qué idioma es mejor, o incluso para inventar un idioma nuevo cada vez, primero tenemos que saber comunicarnos dentro de un marco común. Hoy por hoy, en el sector AEC lo estamos haciendo con señales de humo. Y no hace falta que cada modelador BIM aprenda IFC a nivel avanzado, con que incentivemos a los desarrolladores de software a que apuesten en esa dirección, nos beneficiaremos todos. Con ese hito conseguido, con una referencia a la cual medirse, ya tendrá más sentido entrar en discusiones técnicas sobre alternativas mejores.
  
  En cuanto a la oportunidad de un esquema común… lo siento pero disiento. He visto agentes de proyecto que trabajan con plataformas compatibles y se ven forzados a comunicarse en IFC porque es el estándar… Los proyectos de arquitectura grandes, incluso los muy grandes, tienen un número de agentes relativamente reducidos y ese grupo de agentes no suele repetirse demasiado. Quizás en obras públicas sea distinto, pero IMHO en arquitectura no se justifica…
  
  Si para el IFC5 están mirando al USD… a lo mejor no estoy tan equivocado ¿no?
  
  Y de perdonarte, nada de nada ¡gracias! un gustazo poder discutir de nuevo en un espacio que abrimos hace casi 20 años y que estoy intentando reflotar.
  
  Cuando quieras, aquí tienes tu casa para seguir discutiendo.
  
  Responder
Libny Pacheco

febrero 15, 2024 at 2:08 pm

¡Qué bueno ver esta conversación en español! Gracias por traer el tema a colación, Miguel.

Voy al grano.

Un resultado de las cartas abiertas contra Autodesk es la «Future AEC Software Speficication». Varios estudios están poniendo recursos para redactarla y además apoyar proyectos que están tratando de implementar dicha especificación. Por ejemplo, uno de los aspectos mencionados en la susodicha especificación son los «data frameworks» (el tema de este blog-post!). En este renglón, ellos mencionan el trabajo que Greg Schleusner de HOK está desarrollando. Schleusner está involucrado en al menos tres proyectos relacionados a data frameworks: IFC5 (él es parte del capítulo norteamericano), StrangeMatter (su proyecto personal apoyado por estudios privados) y el Future AEC Software Specification como tal.

Secundo totalmente a Carlos respecto a unirnos a estos desarrollos que se están por venir.

Por cierto, Greg (IFC5) no sólo habla de USD como analogía, sino también del uso de Entity Component System (ECS) como reemplazo de Object Oriented Programming (OOP) en el que la mayoría de nuestro software está basado.

Aquí un par de enlaces:
https://future-aec-software-specification.com/data-framework/
https://www.youtube.com/watch?v=GgN1he00dpc
https://www.youtube.com/watch?v=SaGvo9g5ySM

Responder
Miguel Villegas Ballesta, doctor arquitecto.

febrero 29, 2024 at 8:54 pm

Tremendo, Libny. Siento haber tardado tanto en contestarte, pero quería tener tiempo para ver el video de Schleusner.
La reflexión que hace sobre USD me parece lo más interesante, y hay mucho camino por recorrer, pero sigo pensando que hacen falta más arquitectos abstractos pensando en qué son las cosas y cómo se llaman… Cuando Schleusner dice «un espacio no es una cosa, es una colección de cosas virtuales»… uf! Me duele todo al escucharlo!

Responder
Bittor

marzo 5, 2024 at 12:48 pm

Me encantaría saber más sobre tu crítica al IFC.
Si lo entiendo bien dices que el que esté en inglés dificulta la comprensión y que la especificidad de ciertas disciplinas es confusa o poco práctica. Hay algo más que lo haga el mal?
No conocía el concepto de ontologías abiertas , así que me encantaría saber ejemplos algo más específicos y que pudieran ayudarnos en AECO.

Responder
1. Miguel Villegas Ballesta, doctor arquitecto.
  
  marzo 5, 2024 at 8:41 pm
  
  Hola, Bittor.
  Seguiré criticando en próximos artículos.
  Sobre lo que comentas en concreto… pues si. En mi experiencia (personal, poca y limitada) mucha gente me ha «protestado» por tener que aprenderse términos en inglés. Lleva a muchos a adoptar Property-Sets propios en su idioma simplemente para mejorar la «comodidad». Y como decía arriba, también he visto usar mal las entidades y sus propiedades porque estaban entendiendo mal los términos y sus definiciones, que son muy claras en el esquema… pero si lo entiendes mal, pues la estás liando.
  La especificidad… pues son temas muy concretos… ¿por qué el PSet_WindowCommon tiene «GlazingAreaFraction» y el PSet_DoorCommon no lo tiene? Pues me resulta arbitrario, y como me resulta arbitrario, mi mente ansiosa de libertad me pide una ontología «ad hoc» REALMENTE abierta, y no sólo «abrible» (ya se que es un palabro, pero es licencia poética).
  Respecto a las ontologías abiertas, lo mencionado sobre el USD por Libny en el otro comentario, Labelled Property Graphs frente a RDF (que es como funciona el IFC) o mi tesis 😉
  Muchas gracias por tu interés y por participar por aquí!
  
  Responder