Generating TTL Files with Python RDF + Multiple Facilities Represented on the Same RDF Graph?

[Liam Considine]

Hey Brick Crew, 

I am working to write the "seeding" step of some Brick RDF graphs using python RDF and brickschema libraries... 

First off I really think exposing any of the python scripts that created the ttl files in the example would be a great help to "new comers" like me... 

This is helpful:
https://github.com/BrickSchema/Brick/blob/master/examples/example1/generate.py

But seeing the script that generated the bigger examples like:

https://github.com/BrickSchema/Brick/blob/master/examples/rice_brick.ttl

Would be game changing... 




It's currently my intent to have multiple customers and multiple facilities per customer on the same graph... 

Is this a bad idea? If I keep my namespaces correctly can sparql queries be restricted to only certain portions of the graph? 

If I properly create a namespace: 

BLDG = Namespace(f"http://example.com/{building.project}/{building.name.replace(' ', '')}#")

self.g.bind(f"{building_prefix}", BLDG)

self.g.add((BLDG.Building, RDF.type, self.BRICK.Building))

Can I then ensure SPARQL queries only operate on a specific namespace? 
https://stackoverflow.com/questions/9597981/sparql-restricting-result-resource-to-certain-namespaces

The above solution seems less than ideal... 

[Liam Considine]

Looks like using conjunctive graphs might be the answer: 

https://rdfextras.readthedocs.io/en/latest/working_with.html#working-with-conjunctivegraphs

[Gabe Fierro]

Hi Liam:

The code for the bigger examples *is* online, but it hasn't been touched since v1.0.2: https://github.com/BuildSysUniformMetadata/GroundTruth . It may be helpful as a point of reference, but I think that having some more up-to-date and complete (and better documented!) examples of producing a Brick model from BMS labels would be more helpful to you. Maybe that can be one of the first tasks by the new working groups?

Regarding your second question, it is emerging as best practice to separate your administratively separate facilities (i.e. different customers) into different named graphs. In the py-brickschema world, this can be accomplished by having different brickschema.Graph objects for each site, but if you're working with another database like Jena or GraphDB, then you will want to put the facilities into different graphs.

Best,

Gabe

--
You received this message because you are subscribed to the Google Groups "Brick User Forum (Unified Building Metadata Schema)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to brickschema...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/brickschema/2eceb04b-c5eb-450a-8aad-fa8e19689111n%40googlegroups.com.