Community ontology: Brick Schema, a open-source standard ontology for buildings.

[Jason B. Koh (jbkoh)]

Brick Schema is an open-source industrial standard ontology for buildings. It started from 7 research institutions and is widely used across the industry, HVAC, lighting, EVs, solar panels, etc. For more information, visit https://brickschema.org/, or reach out to me (or discuss in this thread.)

[Jason B. Koh (jbkoh)]

For the icon, I'd love to use our favicon if it's allowed. Thanks

[Alvaro Videla (videlalvaro)]

Thank you for contributing Brick Schema. We completed provenance, licensing, privacy/security, catalogue, and runtime checks against the current head (c76431d255390286a97a526e0265471e599aac65).

The good news first:

• The submitted RDF graph matches the official Brick v1.4.4 Brick.ttl release semantically (53,960 triples, including the blank-node subgraphs).
• We found no credentials, malicious XML constructs, active script content, or operational building/user data.
• The two professional creator contacts in the RDF are also in the official release and appear to be intentional upstream attribution.
• Brick has clear reusable industry value. This review is not a rejection of Brick or a concern about the legitimacy of the project.

Changes needed in this contribution

1. Classify it as external third-party content

   • Move the entry from catalogue/community/BrickSchema/brick/ to catalogue/external/brick-schema/brick/.
   • The current uppercase BrickSchema directory is rejected by catalogue discovery, so the build exits successfully while omitting Brick entirely.

2. Use supported, neutral metadata

   • Use a supported category such as technology; Building Automation currently fails metadata validation.
   • Attribute the entry to Brick Consortium, Inc., rather than “Brick Community.”
   • Include version 1.4.4 and describe it explicitly as a third-party ontology so catalogue placement cannot imply Microsoft authorship or endorsement.

3. Preserve the complete BSD-3-Clause notice

   • Add the full license text from the immutable v1.4.4 release alongside the entry (copyright notice, conditions, and disclaimer).
   • The current mutable master license link inside the RDF is useful metadata but is not a substitute for retaining the notice with redistributed source.

4. Document immutable provenance and conversion

   • Record the official v1.4.4 release URL and hash.
   • The release publishes Turtle rather than RDF/XML, so please document the tool/version/command used to produce Brick.rdf. We verified graph equivalence, but the conversion should be reproducible for future updates.

5. Keep the generic brick emoji for now

   • The requested favicon is not included in this PR. Please do not add a Brick logo/favicon unless separate trademark/brand permission is documented; the BSD software license should not be treated as logo or endorsement permission.

Playground work required before the full schema can be accepted

These are project-owned prerequisites; we are not asking the contributor to implement all of them:

• #85 — import rdf:Description-typed OWL classes (PR #96 is under review)
• #101 — extract rdfs:subClassOf hierarchies (PR #102 is under review)
• #128 — lazy-load per-entry catalogue payloads
• #129 — size-aware, non-blocking large-graph rendering
• #130 — preserve original RDF and imported semantic relationship kinds
• #131 — tier-aware validation for external standards
• #132 — fail catalogue builds when intended entries are skipped

Why these block the full file today:

• Current main cannot parse it; targeted validation took about 139 seconds and then failed.
• With the local #96/#102 parser stack, Brick becomes 1,518 entities and 1,736 hierarchy edges, but required validation reports 2,883 Designer-profile errors.
• It increases catalogue.json by 140.7% raw (106.4% gzip).
• Production rendering blocked the browser main thread for 4.58 seconds on a direct link and 9.32 seconds through Gallery Load.
• Re-export converts subclass edges into generic object properties and drops imports/SHACL, while the gallery currently labels that reduced output “RDF source.”

Path forward

We would like to keep this PR open while the project-owned issues are implemented. After that, we can re-evaluate the full schema against explicit performance and fidelity gates. A curated Brick example/subset remains a viable earlier option if you would prefer a smaller contribution that fits the current Playground model.

Thanks again for bringing a strong real-world interoperability case to the project.

[Jason B. Koh (jbkoh)]

Thanks for the review. I'll update it soon. With regards, Jason Koh

…

On Fri, Sep 18, 2026 at 5:29 AM Alvaro Videla ***@***.***> wrote: ***@***.**** requested changes on this pull request. Thank you for contributing Brick Schema. We completed provenance, licensing, privacy/security, catalogue, and runtime checks against the current head (c76431d). The good news first: - The submitted RDF graph matches the official Brick *v1.4.4* Brick.ttl release semantically (53,960 triples, including the blank-node subgraphs). - We found no credentials, malicious XML constructs, active script content, or operational building/user data. - The two professional creator contacts in the RDF are also in the official release and appear to be intentional upstream attribution. - Brick has clear reusable industry value. This review is not a rejection of Brick or a concern about the legitimacy of the project. Changes needed in this contribution 1. *Classify it as external third-party content* - Move the entry from catalogue/community/BrickSchema/brick/ to catalogue/external/brick-schema/brick/. - The current uppercase BrickSchema directory is rejected by catalogue discovery, so the build exits successfully while omitting Brick entirely. 2. *Use supported, neutral metadata* - Use a supported category such as technology; Building Automation currently fails metadata validation. - Attribute the entry to *Brick Consortium, Inc.*, rather than “Brick Community.” - Include version *1.4.4* and describe it explicitly as a third-party ontology so catalogue placement cannot imply Microsoft authorship or endorsement. 3. *Preserve the complete BSD-3-Clause notice* - Add the full license text from the immutable v1.4.4 release alongside the entry (copyright notice, conditions, and disclaimer). - The current mutable master license link inside the RDF is useful metadata but is not a substitute for retaining the notice with redistributed source. 4. *Document immutable provenance and conversion* - Record the official v1.4.4 release URL and hash. - The release publishes Turtle rather than RDF/XML, so please document the tool/version/command used to produce Brick.rdf. We verified graph equivalence, but the conversion should be reproducible for future updates. 5. *Keep the generic brick emoji for now* - The requested favicon is not included in this PR. Please do not add a Brick logo/favicon unless separate trademark/brand permission is documented; the BSD software license should not be treated as logo or endorsement permission. Playground work required before the full schema can be accepted These are project-owned prerequisites; we are not asking the contributor to implement all of them: - #85 <#85> — import rdf:Description-typed OWL classes (PR #96 <#96> is under review) - #101 <#101> — extract rdfs:subClassOf hierarchies (PR #102 <#102> is under review) - #128 <#128> — lazy-load per-entry catalogue payloads - #129 <#129> — size-aware, non-blocking large-graph rendering - #130 <#130> — preserve original RDF and imported semantic relationship kinds - #131 <#131> — tier-aware validation for external standards - #132 <#132> — fail catalogue builds when intended entries are skipped Why these block the full file today: - Current main cannot parse it; targeted validation took about 139 seconds and then failed. - With the local #96 <#96>/#102 <#102> parser stack, Brick becomes 1,518 entities and 1,736 hierarchy edges, but required validation reports 2,883 Designer-profile errors. - It increases catalogue.json by 140.7% raw (106.4% gzip). - Production rendering blocked the browser main thread for 4.58 seconds on a direct link and 9.32 seconds through Gallery Load. - Re-export converts subclass edges into generic object properties and drops imports/SHACL, while the gallery currently labels that reduced output “RDF source.” Path forward We would like to keep this PR open while the project-owned issues are implemented. After that, we can re-evaluate the full schema against explicit performance and fidelity gates. A curated Brick example/subset remains a viable earlier option if you would prefer a smaller contribution that fits the current Playground model. Thanks again for bringing a strong real-world interoperability case to the project. — Reply to this email directly, view it on GitHub <#89?email_source=notifications&email_token=AAL76E26MJMDN6ZKKX32HV35PUTCBA5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTKMRUG43TMMZYGYZKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#pullrequestreview-5247763862>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAL76EYNSAIBZA4X6NVBML35PUTCBAVCNFSNUABGKJSXA33TNF2G64TZHMYTCNRQGAYDKMBQGI5US43TOVSTWNBZGMZDSOJUGA3DLILWAI> . You are receiving this because you authored the thread.Message ID: <microsoft/Ontology-Playground/pull/89/review/5247763862 ***@***.***>