Building Device and Asset Naming Standards initiative

Status: release 1.3.0

Governance model

Background

This document provides an overview of governance and processes used in the initiative to create a standard for device and assets naming and labeling in the built environment. This initiative was started in late 2019 by a number of organisations working on or with data and/or built environment systems, with an ambition to create an open standard for Building Device Naming.

This document is intended to be a useful reference point for anyone involved in contributing to the open standard(s) being developed.

Scope

Building devices and assets in scope for this work are Mechanical, Electrical, Public Health (MEP) devices (known as Operational Technologies - OT) and Information Technology (IT).

This standard is developed to align and complement other initiatives in the industry such as Brick Schema, Haystack, Omniclass, Uniclass, IFC etc. In scope for this work are:

Governance and platforms

Development and future maintenance of the naming and labelling standard for building devices will rely on technical platforms.

The used platforms are:

  1. GitHub for hosting of the specifications and related documentation, issue tracking and resolution;
  2. a W3C Community group for mailing-lists and other collaboration tools.

The platforms provide mechanisms to raise, discuss and resolve issues. They are however agnostic on the decision process used to resolve issues, deal with disagreement, or appoint key roles. This document describes the associated governance.

Our governance principles

As a group we are committed to the OpenStand principles. These are five principles that guide our work:

  • Due process. Decisions are made with equity and fairness among participants. No one party dominates or guides standards development. Standards processes are transparent and opportunities exist to appeal decisions. Processes for periodic standards review and updating are well defined.
  • Broad consensus. Processes allow for all views to be considered and addressed, such that agreement can be found across a range of interests.
  • Transparency. Standards organizations provide advance public notice of proposed standards development activities, the scope of work to be undertaken, and conditions for participation. Easily accessible records of decisions and the materials used in reaching those decisions are provided. Public comment periods are provided before final standards approval and adoption.
  • Balance. Standards activities are not exclusively dominated by any particular person, company or interest group.
  • Openness. Standards processes are open to all interested and informed parties.

We are working to improve our process to ensure that we are living up to these principles. This document provides a reference point for our current practices.

Intellectual property

All the outputs from this standards initiative are openly licensed.

The formal specifications created within the W3C community group are published under the W3C software and document notice and license. It gives permission for you to reuse the work, including implementing the specifications for free, for any purpose.

Additional documentation and source code produced by this initiative will also be published under an open licence, e.g. the Creative Commons Attribution Licence, or the MIT licence. We encourage other organisations to similarly licence their work, so that it can be used for the benefit of the wider community.

Individual contributions to the work of the group are covered by the contributor agreement. This gives the group permission to use individual contributions (e.g. suggested text, contributions to test suites) and publish them under an open licence.

Roles and responsibilities

The Community Group

A W3C community group provides a neutral location for organisations working across different sectors to collaborate on openly licensed specifications.

The W3C provide the group with a homepage, a means to publish specifications, and some collaboration tools (e.g. our mailing list). This provides the group with a stable presence on the web, even though the membership of the group might change over time.

The active organisations participating in the Community Group are:

  • Arup
  • British Land
  • BuildingsIOT
  • FPC
  • Google
  • Lloret
  • Max Fordham LLP

Chair(s)

The community group is currently chaired by Sotiria Lavasa (Arup), having been nominated by the members of the Community Group in March 2020. In the future members from other community group organisations may take on responsibility for chairing and managing the group. The Community Group shall (at the end of each calendar year) review whether the nominated chair continues in term for another year.

It is the responsibility of the Chair to ensure that we are following our governance principles. For example, ensuring that we have developed broad consensus around planned changes, are being transparent around decision making, and are working in the open.

Editor(s)

The role of the editor(s) is to document decisions and write the specifications for the standard, in line with the decisions. It also includes sharing drafts and changes and gathering feedback from the community.

Editors appointments are suggested by the chairs, and the decision to appoint follows the group’s usual process for consensus.

Current editor(s) for the group is/are:

  • Francesco Anselmo (@pisuke) – Arup – Register and Syntax
  • Richard Reid (@richardkreid) – Google – Register and Syntax
  • Olivier Thereaux (@olivierthereaux) - ODI - Governance document

Community Group members

Anyone can join the community group. Everyone who joins the group signs a contributor agreement. The contributor agreement is part of our commitment to working in the open. It helps to ensure that the work we create can be freely used by anyone for any purpose. All of our outputs are published under an open licence.

Contributions from the group are voluntary. However we ask that all members think about how they can contribute, including:

  • where possible, attending meetings to provide feedback on current plans
  • providing feedback on working documents, and reviewing and voting on issues to help us progress our work
  • adopting our standards in your projects and platforms
  • provide implementation feedback that can help us plan and prioritise new work
  • promoting our activities to a wider community to help us create impact

To support members we provide a number of ways to engage with our work. These are outlined below.

Other roles

Other roles, such as test manager, etc. may be appointed at certain phases of the lifecycle of the standard. A number of those roles and their typical responsibilities are listed in the Open Standards for Data guidebook.

Appointment of those roles among Community Group members are suggested by the chairs, and the decision to appoint follows the group’s usual process for consensus.

How we collaborate

We aim to be respectful of people’s time and so provide multiple ways to monitor progress and engage with the work of the group.

We aim to use collaboration tools that will enable people to usefully participate in discussions and to help move our work forward.

Currently we use the following:

  • Mailing lists. The community group has a two mailing-lists: an internal mailing-list used for logistics of the group, and a publicly available and archived mailing list which anyone can subscribe to. We use this list for key announcements and co-ordinating events.
  • Regular teleconference. Active members of the community group meet frequently (currently: weekly) to discuss progress on the documents and issues. Decisions made during the meeting will be documented in Github issues or commit messages, and may also be posted on the public mailing-list. We also hold quarterly open video calls to provide updates on progress and to help discuss key issues. Dates and logistics of the next call, as well as notes or minutes of previous calls, will be posted on the public mailing-list.
  • GitHub. We use GitHub to manage our working documents and as an issue tracker. The issue tracker for each specification is clearly linked at the top of the document.
  • Google Documents. We occasionally use google documents to help to collaborate on additional best practice guidance or documentation. Documents are always made openly available for anyone to view and/or comment. Documents are shared via the mailing list.
  • Blog. For key milestones we publish short blog posts on the W3C Community Group blog.

Over time we may use additional tools and website to help publish additional tutorials and other supporting documentation.

Managing change and building consensus

Versioning of documents

The group expects to produce and maintain two types of standards:

  1. A simple syntax specification
  2. A register of building device names

The former specification goes through the following stages:

  • Editors Draft. Working versions of the specifications that are under discussion and review by the community group. These drafts are subject to change.
  • Candidate Specification. Current stable version of our specifications, incorporating the latest agreed changes. These versions are considered stable enough for production implementation. Candidate Specifications will be point releases, e.g. 1.1, 1.2, 1.3 version of a specification.
  • Final Specification. A major revision of our specifications. These are clearly linked as “Final Reports” from the community group homepage.

Candidate and Final Specifications are clearly versioned. To allow for referencing of earlier versions, we will provide links to previous versions of a specification.

Editors will be in charge of managing the evolution of the specification according to our process for building consensus.

For the register of building device names, there are:

  • A live list reflecting at any point the latest state of the list as maintained by the Editors.
  • Stable snapshots of the list with clear version names will be created on a regular basis (aiming to be at least once a year) to provide a stable basis for implementation. Snapshots will only include names for which no open issue is currently open.

In the interest of speed and flexibility, Editors will be following the simplified submission process when adding new entries to the register.

Our process for building consensus

Our process for making changes to our specifications and building consensus within the community is as follows:

  • propose and discuss new work areas in our regular calls, e.g. plans for tackling major new work areas
  • raise issues on Github to outline proposed changes in more detail:
  • encourage discussion and feedback on those issues by requesting that people leave comments on Github.
  • in addition we also review and discuss issues in our regular calls and collate these comments, updating the relevant issues
  • once we have a clear proposal with support from the community (see process, below), the specification editor will create a new Editors Draft of the relevant specification, including the proposed changes.
  • new and updated Editors Drafts will be circulated to the community group via the mailing list, with a summary of changes
  • once we feel that a broad consensus has been achieved around the proposed changes, we will publish a new Candidate Specification
  • prior to the annual point release of a specification we will issue a request for any major issues or concerns prior to the publication of the Final Specification.

Where we have proposed changes to release, we will aim to publish new Candidate Specifications every two months.

This process provides for multiple points of feedback and communication, giving everyone an opportunity to :

  • discussion during our regular calls
  • comments on proposed changes or amendment on individual github issues
  • call for feedback on new and updated Editors Drafts
  • annual call for feedback prior to a major release

We will aim to do quarterly release updates to the abbreviations register.

Proposing specification changes

Anyone can propose changes to our specifications. The process is to:

  1. File a proposal by submitting an issue to the relevant GitHub repository for the specification.
  2. Share your proposal with the community by posting to the community group mailing list
  3. Work with others, including the specification editor, to respond to any feedback, including making any necessary revisions to the proposal
  4. Work with the specification editor to make sure that proposal is incorporated in draft

To help guide decision making we suggest that editors should look for the following as signs that a proposal has the necessary support from the community:

  • the backing of both a publisher and a consumer of the data (or API), to be named in the github issue
  • at least three positive votes (on the relevant github issue or issues) from community group members

It is the responsibility of both the person submitting a proposal and the specification editor to ensure that the proposed changes fit within the design principles and scope of the specification.

Submission process for building device names

Anyone can submit a new name to the register. The process for submission is as follows:

  1. A submission can be made through one of several technical means:
    1. Additions to the register can be proposed by submitting a “pull request” to the Github repository.
    2. Alternative submission mechanisms (e.g. through a mail address) may be made available if the Github PR mechanisms are deemed too technical.
  2. A notification of the submission is made available to the Community Group
  3. If there are no objections from members of the Community Group or Editors, the editors will either integrate the submission or suggest an alternative to the submitter within two weeks.
  4. If there are objections from members of the Community Group or Editors, the issue is escalated to the attention of the Community Group and its Chair(s), and the normal consensus building process applies.

Any change to the register of names will follow the process for proposing specification changes and the consensus building rules.

Funding

The ODI’s contribution during Phase 1 (2019/2020) of the project was funded through the Arup-ODI Partnership agreement.

Arup, Buildings IoT and FPC worked in 2020 and 2021 as part of agreed Statement of Works funded by Google to undertake the following:

  • Facilitate the adoption of a Google internal list of abbreviations into BDNS.
  • Review, updating and addition of Google project related abbreviations.