referencing a part of a geometry file

mathib commented 5 years ago

During the geometry modelling phase, it can be beneficent to have only one geometry file for a project that exists of geometrical descriptions of multiple individual building elements. To make this possible, additional terminology is needed to add the ID/group name of the individual geometry description (e.g. omg:hasGeometrySchemaId). Because some schemes have multiple IDs/groups, I think it's best to extend this property in FOG per schema:

inst:door1 omg:hasGeometry inst:geometry1 .
inst:geometry1 a omg:Geometry ;
   fog:asObj_v3.0-obj "myLargeObjFile.obj"^^xsd:anyURI ;
   fog:hasObjId-group "group_name1" .

and

fog:hasObjId-group rdfs:subPropertyOf omg:hasGeometrySchemaId .
fog:hasObjId-object rdfs:subPropertyOf omg:hasGeometrySchemaId .
...

mathib commented 5 years ago

Alternatively, the large geometry description can also be described with a separate node:

inst:door1 omg:hasGeometry inst:geometry1 .
inst:geometry1 a omg:Geometry ;
   omg:hasGeometry inst:largeGeometry2 ;
   fog:hasObjId-group "group_name1" .
inst:largeGeometry2 a omg:Geometry ;
    fog:asObj_v3.0-obj "myLargeObjFile.obj"^^xsd:anyURI .

The second omg:hasGeometry could also be replaced by a new property in omg (e.g. omg:partOfGeometry with domain and range equal to omg:Geometry)

mathib commented 5 years ago

I favor option 2, as it will decrease the number of triples when the geometry is georeferenced, as the "large OBJ file" as a whole can be georeferenced, instead of every individual part of the OBJ.

However, OMG in its current state has omg:hasGeometry as an inverse functional property and in the above case, the geometry node of a large geometry description is typically shared by different geometry nodes of individual building element nodes. As a result, I think we need two a new property omg:partOfGeometry (level 2 - range is omg:Geometry, domain undefined?) and omg:partOfGeometryState (level 3 - range is omg:GeometryState, domain undefined?)

mathib commented 5 years ago

In the case where the larger geometry file does not contain IDs that can be used to reference a part of it (e.g. in the case of a single large point cloud of a building), we can allow to switch the IDs with a bounding box node:

inst:door1 omg:hasGeometry inst:geometry1 .
inst:geometry1 a omg:Geometry ;
   omg:partOfGeometry inst:largeGeometry2 ;
   arp:hasBoundingBox inst:boundingBox1 .
inst:largeGeometry2 a omg:Geometry ;
    fog:asE57_v1.0 "myLargePointCloudFile.e57"^^xsd:anyURI .
inst:boundingBox1 a arp:BoundingBox ;
    arp:hasXMax 6.52180814743042 ;
    arp:hasXMin 9.2151564 ;
    arp:hasYMax -23.2442359924316 ;
    arp:hasYMin -19.454564 ;
    arp:hasZMax -11.9359664916992 ;
    arp:hasZMin -5.454654654 .

arp => arpenteur ontology (http://www.arpenteur.org/ontology/Arpenteur.owl#) focused on photogrammetry.

If we also would like to have bounding boxes that are not parallel to the XYZ axes, we'll need to define three 3D points instead of two (not all in the same plane). The terminology for this is not in Arpenteur, so this has to be added: omg:hasX1, omg:hasY1, omg:hasZ1, omg:hasX2, etc.

AnnaWagner commented 5 years ago

Add omg:partOfGeometry to OMG.

Unclear how to handle the ID and bounding box notation. Either as subproperties of omg:hasXXXGeometryDescription, rdfs:label, arp:BoundingBox, or maybe as new OMG properties: omg:hasGeometryPartId and omg:hasGeometryPartRestriction

mathib commented 5 years ago

part of geometry: general

This property can be used to link two omg:Geometry nodes, e.g. <geometryA> omg:partOfGeometry <geometryB>, where geometryA is either (1) a bounding volume over geometryB or (2) a subgeometry of geometryB (identifiable with an ID or group name).

Maybe we should also define a similar property for OMG L3 between two omg:GeometryState instances, e.g. omg:partOfGeometryState?

part of geometry via ID/group name

I would go for ~~omg:hasGeometryPartId~~ omg:hasGeometryPart here, which can be extended in FOG per relevant schema (some schemas have multiple IDs or grouping mechanisms). I would set a schema:domainIncludes to omg:Geometry (OMG L2) and omg:GeometryState (OMG L3).

When using omg:hasXXXGeometryDescription, it might make querying for all geometry more hard. I would expect subprops of these to point to geometry descriptions and not IDs of geometry descriptions (these IDs have no meaning on there own). In addition, it requires to extend the FOG geometry schema taxonomy even further and making it more complex then needed (e.g. fog:asObj_v3.0-obj-IdGroup and fog:asObj_v3.0-obj-IdObject as suprops of fog:asObj_v3.0-obj).

I'm also not in favour of subprops of rdfs:label as most people will expect to find a human readable label describing the subject (e.g. "this geometry represents the chair object in ...") instead of an ID (or group name).

part of geometry via bounding volume

(I prefer this term over "bounding box" is it can have any shape and is thus more flexible).

For the bounding volume, which is a geometry description on its own, I would suggest to use the existing FOG subprops of omg:hasXXXGeometryDescription. Alternatively, people can use other methods to define a bounding volume, e.g. using the Arpenteur method for a bounding box, etc.

One negative point of this approach is that when querying for all geometry, the receiving application needs to check if the geometry node is connected to another geometry node (= more complex SPARQL query), to know that this is a bounding volume and thus should be rendered in a different way (e.g. only edges visible).

tudaIIB / omg