Canonical IRI of CityDB building OBDA mapping

[ChungTingLao]

In the current OBDA mapping, IRIs of city objects in the CityDB database are constructed based on their ID. In order to have persistent IRIs for city objects (since these IDs are generated during the upload process and not explicitly stored in the original data), these IRIs are mapped to canonical IRIs which includes its class and UUID.

However, this particular mapping requires multiple SQL JOINs and its pattern is sometimes too generic, leading to over-matching of IRI patterns and therefore performance issues.

Potential solutions includes:

• modify the prefix to be more specific to CityDB, to avoid non-CityDB IRI being matched.
• add canonical IRI mappings for each specific classes of city objects, which can reduce number of SQL JOINs. This introduces more mappings and the chance of human errors (since these mappings are usually edited by hand).
• modify the canonical IRI pattern to not directly contain the class name, which remove the need of SQL JOINs. The IRIs become less informative, but the class information can still be retrieved through SPARQL query.

Further consideration:

• these changes may require changing the stack data uploader behaviour (which generates IRI and UUID of city objects if they do not already exist), interacts with Feature Info Agent behaviour (relies on IRI to gather metadata), and migration of already instantiated building data and relevant agents (if their SPARQL query is not compatible, or is reliant on specific IRI pattern).