additional metadata for a geometry description

[mathib]

We should consider methods for adding additional metadata to geometry descriptions in a uniform way. This includes:

• up-axis: three fixed options are possible, i.e. X, Y or Z axis. Introduce omg:hasUpAxis property and three individuals omg:x-axis, omg:y-axis and omg:z-axis.
• transformations: GEOM vocabulary for the matrix can probably be reused here (3x4 matrices are possible: scaling, rotation, translation => enough for a 4x4 affine matrix in 3D). We cannot reuse the geom:Transformation pattern, because we would create a different pattern [1] from regular OMG/FOG [2]. This means a new OMG property has to be introduced: omg:locallyTransformedBy
• units: reuse QUDT or OM or schema.org (CDT cannot be used as it doesn't concern "simple" RDF literals (e.g. RDF-based geometry, OBJ embedded in an RDF literal, an external file referenced via a URL). We can leave the choice to the users, but this goes against a uniform approach for defining the units.
• georeferencing of the geometry description: each building object can have multiple geometry descriptions in different local Coordinate Reference Systems (CRS) or one absolute CRS:
  • absolute CRS: property needed to add an absolute CRS (e.g. omg:hasGlobalCoordinateSystem). Fixed individuals can be reused from http://www.opengis.net/def/crs (e.g. WGS84: http://www.opengis.net/def/crs/EPSG/0/4979)
  • local CRS vs absolute: link to transformation matrix should differ from local transformation (omg:globallyTransformedBy). A CRS should also be linked (again omg:hasGlobalCoordinateSystem). An example of a combination of a local transformation in combo with a global transformation (georeferencing) in [3]
• file size
• (in the case of tessellated geometry) number of faces and number of vertices
• author: reuse dct:creator?
• software used (origin): the ontology can provide individuals (software name + version). Having this list of software application individuals shared, will result in similar management issues as FOG (constant updates, community support). Additionally, export settings can be included
• date of creation of the geometry (not date when introduced in the RDF graph): dct:issued?
• geometric accuracy: (a) the accuracy of a survey geometry (e.g. a point cloud vs real world object ~measured accuracy (LOA)) and (b) the accuracy of a geometry derived from another geometry (e.g. a simple BREP derived from a point cloud ~represented accuracy (LOA)). Would seem logical to be able to link the two geometries to an accuracy analysis node (direct relation between the two geometries (omg:isDerivedFromGeometry or omg:isDerivedFromGeometryState) can be inferred via a prop chain axiom)
• assumptions: used assumptions while reconstructing geometry of an invisible (part of an) existing building object (e.g. geometry of connections inside a wall, internal geometry of a window, etc.)
• 2D or 3D: is the geometry 2D or 3D? This could be done via a classification of the geometry node in L2 and L3 (e.g. ´ex:2D_Geometry´ and ´ex:3D_Geometry´). There can be subclasses for specific 2D drawings: floorplan, ceilingplan, section, elevation, isometric (2D projection of 3D)
• type of geometry representation: mesh, point cloud, BREP, CSG, NURBS
• ...

Pattern [1]

inst:door1 omg:hasGeometry inst:geometry1 .
inst:geometry1 a omg:Geometry ;
   omg:locallyTransformedBy inst:matrix1 ;
   fog:asObj_v3.0-obj "myOriginalObjFile.obj" .
inst:matrix1 ...

Pattern [2]

inst:door1 omg:hasGeometry inst:geometry1 .
inst:geometry1 a omg:Geometry ;
   ex:locallyTransformedObj inst:transformedDoorGeometry .
inst:transformedDoorGeometry a geom:Transformation ;
   geom:matrix inst:matrix1 ;
   geom:object inst:doorGeometry .
inst:doorGeometry fog:asObj_v3.0-obj "myOriginalObjFile.obj" .
inst:matrix1 ...

Pattern [3]

inst:door1 omg:hasGeometry inst:geometry1 .
inst:geometry1 a omg:Geometry ;
   omg:locallyTransformedBy inst:matrix1 ;
   fog:asObj_v3.0-obj "myOriginalObjFileInLocalCoordates" ;
   omg:globallyTransformedBy inst:matrix2 ;
   omg:hasGlobalCoordinateSystem "http://www.opengis.net/def/crs/EPSG/0/4979" .

[mathib]

Note regarding georeferencing geometry descriptions: suggestion to objectify the local coordinate system, to lower the amount of triples (rdf:type triples are not incl as they can be inferred):

• from 3*GS + matrix triples triples to 2*GS + 3 + matrix triples (individual geometry file per GS)
• from 2*GS + 3 + matrix triples to 2*GS + 4 + matrix (1 shared geometry file over multiple GS)
  (GS = omg:GeometryState in case of L3 or omg:Geometry in case of L2)

Such a pattern [4-a] would look like (individual geometry file per GS):

inst:door1 omg:hasGeometry inst:geometry1 .
inst:geometry1 a omg:Geometry ;
   fog:asObj_v3.0-obj "geometry of door in OBJ" ;
   omg:hasCoordinateSystem inst:coordSys1 .
inst:coordSys1 a omg:CoordinateSystem ;
   omg:hasGeoreference inst:georef1 .
inst:georef1 a omg:Georeference ;
   omg:globallyTransformedBy inst:matrix2 ;
   omg:hasGlobalCoordinateSystem "http://www.opengis.net/def/crs/EPSG/0/4979"^^xsd:anyURI .

or [4-b] (shared geometry file over multiple GS):

inst:door1 omg:hasGeometry inst:geometry1 .
inst:geometry1 a omg:Geometry ;
   omg:locallyTransformedBy inst:matrix1 ;
   omg:hasGeometry inst:myOriginalGeometryFile .
inst:myOriginalGeometryFile a omg:Geometry ;
   fog:asObj_v3.0-obj "myOriginalObjFileInLocalCoordates" ;
   omg:hasCoordinateSystem inst:coordSys1 .
inst:coordSys1 a omg:CoordinateSystem ;
   omg:hasGeoreference inst:georef1 .
inst:georef1 a omg:Georeference ;
   omg:globallyTransformedBy inst:matrix2 ;
   omg:hasGlobalCoordinateSystem "http://www.opengis.net/def/crs/EPSG/0/4979"^^xsd:anyURI .

~ similar approach as the second suggestion in issue 2: #2 (comment)_

[mathib]

general question is also if this metadata terminology should end up in the OMG module, or a separate metadata module.. In this light, a separate module has already been developed for some other research project I'm involved with, i.e. V4Design: https://gitlab.com/v4designEU/V4D-Linked_Data_Ontology/tree/master/KULeuven/TBox

[AnnaWagner]

3 different appraoches:

1. extension of OMG (transformation based on omg:transformsGeometry)
2. suggestions for re-using existing ontologies (QUDT/OM, PROV, DCT,...) - "alignment maps"
3. metadata ontology for geometry files --> 3DMO

[AnnaWagner]

Suggestions could be realised using class axioms with cardinality restricitons (max 1)

[AnnaWagner]

bpo:ClassifiedObject rdf:type owl:Class ; rdfs:subClassOf [ rdf:type owl:Restriction ; owl:minCardinality "1"^^xsd:nonNegativeInteger ; owl:onProperty schema:additionalType ; ] ; .

[mathib]

The omg:transformsGeometry relation can start from static geometry (the geometry description is already calculated) or dynamic geometry (the geometry description is calculated based on the transformation matrix and the original geometry description, similar as pattern [1]):

inst:door1 omg:hasGeometry inst:geometry1 , inst:geometry2 .
inst:geometry1 a omg:Geometry ;  ##dynamic
   omg:locallyTransformedBy inst:matrix1 ;
   omg:transformsGeometry inst:originalGeometryA .
inst:geometry2 a a omg:Geometry ; ##static
   fog:asObj_v3.0-obj "myTransformedObjFile.obj" .
   omg:transformsGeometry inst:originalGeometryA .
inst:originalGeometryA fog:asObj_v3.0-obj "myOriginalObjFile.obj" .
inst:matrix1 ...