Research project of the Cluster of Excellence "Integrative Computational Design and Construction for Architecture" (IntCDC) https://www.intcdc.uni-stuttgart.de/ **Project Name**: Knowledge Representation for Multi-Disciplinary Co-Design of Buildings. https://www.intcdc.uni-stuttgart.de/research/research-projects/rp-20/
BHoM geometries when converted to RDF, are large in size and cause a lot of problems in bhOWL knowledge graph. There should be different ways how to handle geometries.
Description:
I suggest that for the moment we serialize all geometries in Base64JsonSerialized, and keep only semantic information on the graph.
In this way we can still deserialize the geometry and work with it. Future work will consider other ways to represent geometries in a graph.
To not lose the functionality that bhom/rdf provides (specifically the TTL Graph component), we should not replace that component, but create a new component named toRDF (or so), where we encode the geometry and save it as a simple string.
alelom
commented
1 year ago
BHoM geometries when converted to RDF, are large in size and cause a lot of problems in bhOWL knowledge graph. There should be different ways how to handle geometries.
Description:
I suggest that for the moment we serialize all geometries in Base64JsonSerialized, and keep only semantic information on the graph. In this way we can still deserialize the geometry and work with it. Future work will consider other ways to represent geometries in a graph.
To not lose the functionality that bhom/rdf provides (specifically the TTL Graph component), we should not replace that component, but create a new component named toRDF (or so), where we encode the geometry and save it as a simple string.