There are some examples of design trees developed using our GEOM ontology (the list of its classes). These examples are serialized as BASE64 version of their BIN/X format. The same content can also be serialized as a Turtle file.
Cite @peterrdf
"Any part of the design tree can be serialized as a string (BASE64 version of BIN/X), this allows to embed large amounts of geometrical data in a single string. Although it in many ways looks like the WKT format as used in GeoSPARQL it has two main differences:
our string is an alternative representation from an ontology, within the triple store somebody can switch between string and design tree (of course this is in principle also possible with WKT)
our ontology exists of 150 classes where WKT has ~ 5 'classes'. For comparison different IFC and AP242 schemas have 200 - 300 entities (read classes) purely related to geometry. The reason our class count is smaller is due to some missing expression power in our ontology, some redundency in the IFC / AP242 schemas and the fact that geometry and mathematics is not cleanly seperated. In contrast to what many people think is that in design related (open)
standards the geometry is semantically very rich; this in contrast to measured and visualizatioin standards like CityGML, Collada, OBJ, glTF etc. If the attached files would be stored in one of these standards the semantics would disappear resulting often in larger files, but more importantly in loss of semantics, presicion and design intent.
Alternative 1 (GEOM ontology, RDF.BG):
There are some examples of design trees developed using our GEOM ontology (the list of its classes). These examples are serialized as BASE64 version of their BIN/X format. The same content can also be serialized as a Turtle file.
Cite @peterrdf "Any part of the design tree can be serialized as a string (BASE64 version of BIN/X), this allows to embed large amounts of geometrical data in a single string. Although it in many ways looks like the WKT format as used in GeoSPARQL it has two main differences: