Skip to content

Tooling Working Group Notes

Jump to bottom
Gabe Fierro edited this page Nov 8, 2021 · 4 revisions

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:
  • 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:

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
Clone this wiki locally