bSDD: dar significado consistente aos dados do IFC
Como os dicionários da buildingSMART organizam classes, propriedades, valores e identificadores para conectar modelos IFC, requisitos IDS e equipes.
Nesta página
Este subartigo aprofunda openBIM: dos requisitos à modelagem e à verificação. O IFC oferece classes e propriedades para trocar dados de uma construção. Projetos também precisam de classificações locais, nomes de materiais e propriedades próprias. Se cada equipe inventar nomes e valores isoladamente, o mesmo conceito pode receber rótulos diferentes — ou o mesmo rótulo pode representar conceitos diferentes.
O buildingSMART Data Dictionary (bSDD) reúne dicionários de dados em uma estrutura comum. Cada classe ou propriedade recebe uma definição e um identificador próprio, o URI, que permite localizar o conceito e relacioná-lo a outros. O objetivo é compartilhar o significado da informação entre pessoas e aplicações, além de trocar seus valores.
Para que serve um dicionário de dados
O manual situa o bSDD como referência para quem publica definições, produz modelos, confere entregas, recebe dados ou desenvolve software. Um projetista pode classificar uma janela e escolher propriedades com nomes e valores acordados. Um coordenador pode verificar se os códigos e as unidades entregues correspondem ao pedido. Um operador pode consultar a definição de uma propriedade antes de utilizá-la numa análise.
O benefício depende do uso coerente do dicionário escolhido. Um URI ajuda a identificar o conceito; ele não comprova que a propriedade foi preenchida corretamente nem que o objeto modelado atende a uma exigência técnica. Para isso, são necessários requisitos claros e uma verificação adequada — por exemplo, uma IDS para parte dos dados alfanuméricos.
O bSDD se apoia em princípios de normas como ISO 12006-3, ISO 23386 e ISO 23387. Ele permite reunir dicionários internacionais, nacionais e especializados, relacionando termos equivalentes, semelhantes ou apenas associados sem apagar sua origem.
Como consultar e usar o conteúdo
A busca pública do bSDD permite explorar os dicionários, suas classes, propriedades, valores e definições. Softwares integrados podem trazer essa consulta para a modelagem, classificação ou preparação de requisitos, reduzindo cópias e digitação manual. A imagem do manual mostra uma dessas interfaces como exemplo de uso, sem indicar que um produto específico seja necessário.
Para integração técnica, a buildingSMART disponibiliza documentação da API do bSDD, com acesso por REST e GraphQL. Os URIs de identificação são úteis para abrir e referenciar conceitos. A documentação atual recomenda usar os endpoints da API, e não esses URIs, para comunicação automática entre sistemas. A lista de aplicações com integração bSDD ajuda a localizar opções, mas as capacidades são declaradas pelos próprios fornecedores; confirme na versão efetivamente usada pela equipe.
A estrutura: dicionário, classe, propriedade e relação
Cada dicionário pertence a uma organização e contém classes e propriedades. Uma classe pode representar um objeto, um material ou um grupo de propriedades. As classes podem formar uma hierarquia, mas, no modelo apresentado pelo manual, uma classe filha não herda automaticamente todas as propriedades da classe mãe. A associação precisa ser especificada.
Uma propriedade define um dado, como altura, identificação ou estado, incluindo tipo, unidade e possíveis restrições. AllowedValue lista valores permitidos. ClassProperty liga uma propriedade a uma classe e pode ajustar, para aquela aplicação, a unidade, o conjunto de propriedades IFC e os valores aceitos. Assim, uma propriedade reutilizável pode aparecer em classes diferentes e em conjuntos IFC diferentes sem ser redefinida do zero.
ClassRelation e PropertyRelation conectam conceitos no mesmo dicionário ou entre dicionários. As relações podem indicar equivalência, semelhança, referência, hierarquia, composição ou material. “Semelhante” não deve ser lido como “idêntico”: duas classificações podem se aproximar e ainda exigir uma decisão de mapeamento para uso contratual ou automatizado.
O exemplo do manual relaciona a classe Window do dicionário CCI Construction à entidade IfcWindow do dicionário IFC. A classe reutiliza uma propriedade própria e outra definida no IFC, cada qual associada ao conjunto de propriedades pertinente. O diagrama mostra como as definições são relacionadas; ele não altera sozinho os objetos já existentes num arquivo IFC.
Versões e identificadores fazem parte do requisito
Um dicionário recém-publicado entra em Preview, estado no qual seu conteúdo ainda pode ser substituído ou removido. Ao passar para Active, recebe identificadores imutáveis; uma versão anterior pode depois ser marcada como Inactive, permanecendo acessível. A documentação de gestão do bSDD descreve o ciclo de vida e as condições atuais de publicação.
Para uma entrega acordada, registre dicionário, versão, código, URI e status dos conceitos utilizados. A opção latest pode apontar posteriormente para outra versão; a documentação da estrutura de dados recomenda URIs com versão explícita para referências contratuais. O texto da propriedade também precisa ser conferido: traduções facilitam a leitura, mas os códigos e definições são a referência para o intercâmbio.
Como a referência aparece no IFC e na IDS
No IFC, um sistema de classificação pode ser descrito por IfcClassification; a classe utilizada, por IfcClassificationReference; e a associação ao objeto, por IfcRelAssociatesClassification. O URI liga a referência externa à definição publicada no bSDD. A figura do manual mostra uma janela classificada como Window do CCI Construction e, abaixo, as entidades correspondentes em um arquivo STEP IFC4.
As propriedades seguem as relações e conjuntos de propriedades do próprio IFC. Isso exige atenção: a presença da classificação externa não significa que cada propriedade tenha, no arquivo, uma ligação explícita de volta ao dicionário de origem. A orientação atual da buildingSMART para referenciar bSDD em IFC e IDS detalha o mapeamento por versão IFC.
Ao preparar uma IDS, o autor pode consultar o bSDD para escolher classes, classificações, propriedades e materiais e incluir o URI correspondente no requisito. Quem recebe a IDS pode seguir o identificador para entender o termo e o contexto do dado solicitado. A interface mostrada no manual ilustra essa consulta durante a autoria da especificação.
Publicar um dicionário exige curadoria
Uma organização pode preparar seu conteúdo em JSON conforme o modelo de dados do bSDD, usar o modelo de planilha e os exemplos do repositório ou trabalhar com uma aplicação integrada. O portal de gestão permite validar e importar o arquivo; a API oferece um caminho para integração. Antes de publicar, verifique autoria, licença, definições, códigos, unidades, versões e relações com conceitos já existentes.
A publicação comum torna os dados acessíveis ao público. Conteúdo de cliente ou de projeto que não pode ser compartilhado exige uma decisão prévia: a buildingSMART oferece dicionários privados como recurso pago, sujeito a permissões. Também convém evitar publicar cópias derivadas de classificações existentes quando for possível referenciá-las ou propor uma melhoria à fonte.
Como passo prático, selecione um uso do modelo, escolha o dicionário e a versão, associe algumas classes e propriedades, exporte um IFC e confira se as referências e os valores sobreviveram à troca. Em seguida, teste a mesma definição numa IDS e verifique o arquivo recebido. Esse pequeno ciclo mostra onde a equipe ainda precisa de mapeamento, revisão humana ou ajuste de software.
Links diretos e fonte
As referências externas do manual foram convertidas em links para a busca pública, a documentação e os modelos de dados, a API, a lista de integrações e o portal de gestão. O exemplo da classe Window no CCI Construction também está ligado diretamente.
Tradução e adaptação editorial das páginas 135–144 de BIMcert Handbook: Basic Knowledge openBIM (2024), seção de Artur Tomczak, Jan Morten Loës e Simon Fischer. As seis figuras fornecidas foram preparadas para os temas claro e escuro, sem a numeração impressa. As interfaces de terceiros aparecem apenas como exemplos do manual; a seleção de software e a adequação de um dicionário dependem de testes no fluxo concreto da equipe.