Shape Acquisition and Processing Ontology

Ontology Introduction

This short tutorial gives an overview of the Ontology for Shape Acquisition and Processing developed within the AIM@SHAPE network of excellence.
In the ontology for Shape Acquisition and Processing, shape models and tools are treated as resources that can be uploaded and downloaded together with their metadata in the AIM@SHAPE DSW. The metadata related to the shapes have been modeled in the Common Shape Ontology (SCO), those related to the tools in the Common Tool Ontology (TCO).

The domain of the ontology has been defined as the development, usage and sharing of hardware tools, software tools and shape data by researchers and experts in the field of acquisition and processing of shapes.

The fundamental goal of the ontology is to formalize the knowledge related to the Acquisition and Processing of a Shape. For the creation of this ontology, we have considered that a digital shape can be created either from a real object or it can be created synthetically. We basically aim at maintaining useful information at different levels (geometric, structural, semantic) when passing from the Real World to the Digital World (Figure 1 - Acquisition) or when performing actions in the Digital World (Figure 1- Processing)

Fig. 1: From the Real World to the Digital one.

Two critical phases are related to the lifecycle of a digital shape.

1. Acquisition Phase: The first critical phase is the Acquisition, in which the contextual knowledge includes different conditions and properties related to the object to be scanned, to the surrounding environment or even to the knowledge of the scanning experts. Most of this information must be preserved and passed to the other steps of often complex modelling pipelines, in order to improve the quality of the results and to open to new research approaches.
2. Processing Phase: The second critical phase is the Processing, in which different tasks with different objectives can be performed. A digital shape can be structured, identifying critical features and/or significant portions of the model, or it can be enhanced, removing for example undesired holes or remeshing it. There are a multitude of different operations that can be applied to a digital shape, all of them depending from different application contexts.

Competency Questions about past, present and future of a digital shape

In case of a real object acquisition, the associated knowledge characterizes the lifecycle of the shape itself. The acquisition has to be planned (e.g. the devices have to be chosen taking into account their availability and the characteristics of the object to be acquired) and the data coming from the acquisition systems have to be processed in the reconstruction phase to produce a shape.
Further processing has to be done to fulfil the users' needs, and documentation has to be produced in order to enrich the semantic impact of the shape.
The SAP Ontology is intended to produce knowledge support for the researchers who have to face the aforementioned steps. Due to the intrinsic complexity of shapes, ontology-driven metadata are necessary in order to reach a sufficient level of expressiveness. Metadata should provide a thorough characterization of shapes by storing:

• the information related to its history, such as the acquisition devices and techniques for creating it or the tools for transforming it (its past, e.g. for documentation),
• the information intrinsically held by the shape itself (its present) and
• the information related to its capabilities and potential uses, such as the possible steps that can be performed or the tools that can be used (its future, e.g., for acquisition/process planning).

Some Competency Questions

1. Which are the Real Objects owned by InstituteXYZ?
2. What are the Acquisition Systems able to scan a Real Object which is light absorbent?
3. What tricks have been performed in order to scan the Real Object XYZ?
4. Under which LightingConditions the real object XYZ has been scanned?
5. Is there a Converter tool able to convert an OFF file into a PLY file?
6. Which are the tools that are able to compute the distance between two shapes?
7. Which is the compilation platform for the tool ABC
8. Which format type does the tool ABC support?
9. What is the History related to the SurfaceMesh XYZ.wrl?
10. Who are the owners of the RealObjects source of the SurfaceMesh XYZ.ply?
11. What are the possible steps to do starting with a points cloud?
12. Through what steps is it possible to reach a surface mesh?
13. Through what sequence of steps is it possible to reach a surface mesh starting from a points cloud?

Ontology Structure

The ontology lives around two main concepts that we describe here.

Processing Session

The concept of a general Processing Session(class ProcessingSession) which formalizes either the acquisition phase (AcquisitionSession) or the application of a processing procedure (ToolSession)

The concept of a Processing Session and the directly related concepts in the SAP ontology. A processing Session has a Processing System which can be either an Acquisition System or a Software Tool

Step

The concept of a general Step (class Step) which indicates an high-level step that can be performed on a specific shape type. In the general pipeline, digital shapes (that can be referred to the Shape repository) are used/created by different tools (that can be found in the Tool repository) and we have formalized the necessary knowledge to identify different digital shape workflows. The basic idea is that the ontology should maintain and provide all the possible template set of actions (template workflows) we can activate considering a given input and/or output type

The concept of a step is related to other steps and to concepts defined in the Common Shape Ontology

Shape Acquisition

Usage Scenario: "Webby and the scanning session"

Description: "Webby" works for UU at the Scanning Group. He would like to compare the quality of two different Acquisition Systems owned by AIM@SHAPE partners. So, he would like to find all the objects owned by UU that could be scanned also elsewhere [CQ #1]. He finds three different real objects, among which he chooses FROG, because it is movable and its weight is reasonably low. Webby puts the FROG in his knapsack but he still does not know where to go. He first would like to find documentation on the already performed Acquisition Session on the FROG and in particular [CQ #4 and CQ #3]. Because no trick has been ever used to acquire FROG, and because FROG is a light absorbent real object, he poses the question [CQ #2]. He browses all the found Acquisition Devices and he discovers that one is owned by "MPII". So he plans his trip to Germany.
These are the CQs related to this usage scenario, as for example:

• CQ #1. Which are the Real Objects owned by "UU"?
• CQ #2. What are the Acquisition Systems able to scan a Real Object which is light absorbent?
• CQ #3. What tricks have been performed in order to scan the Real Object "FROG"?
• CQ #4. Under which LightingConditions the real object "FROG" has been scanned?

The Acquisition Process

The acquisition process basically deals with an acquisition session which takes place considering a particular real object and producing a digital shape on the basis of certain conditions. In the SAP ontology, the AcquisitionSession has been modeled as an entity and an overview of this entity is given in Fig. below.
The AcquisitionSession is related to an AcquisitionSystem (which is made up by one or more AcquisitionDevices - e.g. scanners) and to the AcquisitionConditions in which the acquisition is performed. These AcquisitionConditions can be LogisticConditions (they include the presence of lights, if there exist any obstacle between the real object and the scanning device and so on) or EnviromentConditions (which include the information on is the type of environment - indoor, outdoor or underwater, the level of humidity or even the weather).
Moreover, some attributes are directly related to the AcquisitionSession (e.g. the price for renting the technological devices), while others are related to the different entities in the framework (e.g. the person/institute responsible for a scanning system).

ShapeData entity and its relation with the AcquisitionSession entity.

An AcquisitionSession basically documents the acquisition of a RealObject and the production of a ShapeData (a digital shape), using a particular AcquisitionSystem. A RealObject has also been modeled as an entity, and the knowledge related to it and to its context is thus preserved: in the ontology are recorded the location of the object, the possibility to move it, whether or not it is transparent or light-absorbent, and so on.
Note that the mentioned characteristics (e.g. transparency and being or not light-absorbing) have immediate impact on the Acquisition Planning. For instance, a Trick can be used when there is a problem of compatibility between the AcquisitionSystem and the RealObject to be scanned: a light absorbent object and a laser scanner might be incompatible, but if we need to perform the scanning, it is possible to avoid the problem by spreading powder over the object before scanning. Otherwise, it can also be possible to plan the acquisition with another (compatible) AcquisitionSystem.

ShapeData (which identifies a digital shape) has been modeled as an entity with some specific properties, such as format, URL, description, source (i.e. the AcquisitionSession that has produced it) and owner (an Institution or a Person). A ShapeData can be based on another (or more than one) ShapeData, or a ShapeData can be used to generate a new one. The relation isDerivedFrom formalizes the knowledge related to the history of a given shape. The ontology introduced so far, even if here only partially described, is already sufficient to describe the macro-step of the acquisition of a real object. Such a simple description provides the basics to embed in the digital shapes information that usually gets lost after acquisition. This information might result important for comparing shapes coming from different providers, for improving the assessment about their quality and for better understanding the results arising from further processing.

Shape Processing

In the digital world, a ShapeData can be obtained by modifying another ShapeData (also more than one) or a ShapeData can be used to generate a new one. The SAP ontology formalizes the knowledge related to the processing of a digital shape via the concept ToolSession (succoncept of ProcessinSession) which identifies a session in which a shape (in the AIM@SHAPE DSW) is processed via a tool (in the AIM@SHAPE DSW) in order to produce another shape.

ToolSession entity and its related entities.

Usage Scenario: "Webby and the shape processing"

Description: Webby has acquired at MPII (using the Acquisition System of MPII) the FROG real object owned by UU University. He has produced a surface mesh called "MPIIFrog.off". Webby wants now to evaluate the quality of this last mesh with respect to the one obtained at UU, but he does not have any tool to compute the distance between two shapes. He searches for an appropriate tool [CQ #2]. Browsing the obtained results he chooses the "Metro" tool since it can run on Linux (the OS he usually uses) [CQ #3]. "Metro" is able to load only "PLY" files [CQ #4]. But the MPIIFrog mesh is in OFF format. For this reason, Webby searches for a converter from OFF to PLY [CQ #1]. He browses the results and chooses the "Off2Ply" tool, since it also works on Linux.
We list here some CQs strictly related to the usage scenario above:

• CQ #1. Is there a Converter tool able to convert an OFF file into a PLY file?
• CQ #2. Which are the tools that are able to compute the Euclidean distance between two shapes?
• CQ #3. Which is the compilation platform for this tool?
• CQ #4. Which format type does this tool support?

• CQ #5. Which are the tools with functionality "xyz"?
• CQ #6. Which tool has been used for producing in output the shape "abc.ply"?
• CQ #7. Which are the tools supporting the "ply" format?
• CQ #8. Which type of shape does this tool support?

History of a Shape

The history of a shape X is basically the set of operations (with all the details) that have been performed in order to obtain X. These operations can be related to the acquisition of a real object or the processing of different shapes.

The concept ProcessingSession has a property called hasPreviousSession which links a ProcessingSession to the previous one. The transitive closure of the property hasPreviousSession, called hasHistory, is exactly the relation which produces the history of a given shape.
In this way the history of a shape is the set of ProcessingSessions that contributed to its creation (if the shape is derived from real object the first ProcessingSession will be an AcquisitionSession)

Example of a usage scenario for the history of a Shape.

Usage Scenario:"Webby and the history of a shape"

Description: Webby wants to learn more on the acquisition process and surface meshes in general. He searches for all the surface meshes with a given characteristic (for example "manifold".). He browses the obtained results and chooses the shape "dragon.ply". He asks for the history of this shape, discovering all the operations made in order to obtain the chosen digital shape.
Here we list some CQs related to the third usage scenario:

• CQ #1. Which are the ManifoldSurfaceMesh?
• CQ #2. What is the History related to the SurfaceMesh "dragon.plu"?
• CQ #3. Who are the owners of the RealObjects source of the ManifoldSurfaceMesh "dragon.ply"?

Steps and Workflows

The Shape Acquisition and Processing ontology aims at formalizing the knowledge related to sequences of possible tasks applicable to a specific type of digital shape. The ontology maintains the knowledge related to the specific input and output type of a Step and the tools (eventually) that can be used in orde to effectively perform the step (tools that if available can be find in the tool repository).

Usage Scenario: "Webby and the workflows"

Description: Webby is a young PhD student who just started his PhD in Shape Modeling and Reasoning. He does not know anything about the possible steps in surface reconstruction so he interrogates the ontology for learning all the possible shape processing steps applicable starting from a PointSet (the usual input in a shape reconstruction procedure - concept in the Common SHape Ontology), so that he can understand what can be done for creating new shapes starting from a cloud of points in space.
The involved competency questions, are not more relative to a given shape in the DSW but in the general concept of ShapeType (defined in the common tool ontology). We list here some of them:

• CQ #1. What are the possible steps to do starting with a pointset?
• CQ #2. Through what steps is it possible to reach a ManifoldSurfaceMesh?

Figure 1: an example of competency question answered by the ontology.