Tooling Working Group Notes

2021-11-08

• versioning helper in pybrickschema
• want to know:
  • if someone gives you a building.ttl, you want to know what version of Brick they used to create that
  • if not specified, assume they created it with the current version of Brick
  • this goes into a "best practice" document
• what if you are working with multiple buildings, each created with a different version of Brick?:
  • tooling tries to use them together; detects if anything is deprecated/broken
  • only "freak out" if necessary --- what to do if that happens?
• Brick tooling should spit out the version of Brick used when doing any export

# this is in Brick.ttl
<https://brickschema.org/schema/1.2/Brick#> owl:versionInfo "1.2.1" ;
    brick:majorVersion 1 ;
    brick:minorVersion 2 ;
    brick:patchVersion 1 ;
.

@prefix : <ex:bldg1#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix brick: <https://brickschema.org/schema/Brick#> .

# gets automatically added by Brick tooling
# can enforce inclusion using built-in Brick SHACL shapes
<ex:bldg1> a owl:Ontology ;
    owl:imports <https://brickschema.org/schema/1.2/Brick#> .

:bldg1 a brick:Building .
:ahu a brick:AHU .

@prefix : <ex:bldg2#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
# important that the Brick namespace is the same across the two files
@prefix brick: <https://brickschema.org/schema/Brick#> .

# gets automatically added by Brick tooling
# can enforce inclusion using built-in Brick SHACL shapes
<ex:bldg2> a owl:Ontology ;
    owl:imports <https://brickschema.org/schema/1.3/Brick#> .
    # TODO: need way to point out "nightly" or pre-release

:bldg2 a brick:Building .
:ahu a brick:AHU .

import brickschema
g = brickschema.Graph()
g.load_file("bldg1.ttl")
# at this point, it sees that bldg1 needs v1.2 of Brick.
# Maybe it loads in the Brick definition into a compartmentalized graph?

g.load_file("bldg2.ttl")
# at this point, it sees that bldg2 needs v1.3 of Brick
# Maybe it throws away the Brick definition of 1.2 in favor of 1.3
# *assuming* that those are compatible; maybe only the parts of Brick
# that are used in the models need to be compatible?

# maybe this figures out the version of Brick required to support
# the graphs loaded in so far (v1.3). This logic could eventually
# be handled in load_file so that this call doesn't have to come last
g.load_brick()

# could also overload g.validate() to handle some of this? This would def.
# handle deprecations
``

- maybe switch to `rdflib.Dataset` as the backing store? -- would require a
  major revision of pybrickschema
- it uses `owl:Ontology` definitions to put different graphs into their own
  NamedGraphs in the Dataset
- can keep the same API otherwise
- need to support some "non-release"/pre-release/nightly version of Brick:
    - keep track of the git commit that produced the version
    - also know that it is 'nightly'
- `generate_brick.py` should add the git tag or commit to the build:
    - need new "brick meta" namespace?
    - or can we use schema.org or dcterms to include these attributes?


## 2021-06-01

- improvements on `brickschema` package:
    - improved `reasonable` correctness
    - added `simplify` flag to `expand()` (https://brickschema.readthedocs.io/)
- BACnet ontology:
    - Bacowl is an older effort
    - Joel Bender working on a newer scraping mechanism + SHACL-based representation
    - BMS modeling is something to explore for 1.3.0, but not a super high priority
- Brick model creation:
    - ask for client's help in building the Brick model
    - how to provide a good interface for them?
    - https://github.com/NREL/tasty is one approach (right now not very mature)

## 2021-04-20

- have the ontology documentation exist offline, or some kind of other turtle
  file visualizer?:
    - can self-host it, just by running the brick website
      (https://github.com/BrickSchema/brick-website)
    - you can drop your own TTL files into the correct directory and it just
      shows up in the documentation
    - want to be able to display items by namespace --- needs a new annotation
      on the ontology documentation
    - can this be something that we bake-in to the brickschema package?
      (`g.serve(docs=True)`?)
    - would be nice to have the ontology documentation it as a standalone
      component
- other ways of storing and encoding the turtle files?:
    - ttl is a barrier to use --- it is just a serialziation format
    - we should be able to distribute JSON-LD, RDF-XML, N3 *and* turtle formats
      as part of the releases
    - is there a simpler encoding, that is maybe lossy, that would be easier
      for web developers, etc to work with?
- graphQL encoding of Brick? A definite need for a simpler form that captures
  the primary features of the ontology
- what is the "next step" that people use the Brick artifacts with?
    - Do they load Brick into a graph database?
    - Do they import Brick definitions into a relational database or ORM?
    - transform into a form for GraphQL or incorporation into web services?
- add a "cleanup" flag to brickschema's expand command -- remove axiomatic
  triples, filter out non-specific classes + blank nodes
- incorporate some of the annotation function inference rules that Gabe is
  working on into brickify?
- follow up with the brickify author to get that merged into brickschema:
    - brickify is important because it is a way to develop customzied tools for
      your team and your buildings and your metadata sources
    - would want to incorporate brickify stuff into the 'shepherding' stack