As a user, I want to optimize the entity retrieval so that when an entity has an eagerly loaded attribute, its value would be fetched as part of the root entity, thus reducing the number of repository calls.
Implementation notes:
The underlying APIs that we use (Jena, OWLAPI, RDF4J) are based on the notion of statements where filtering can be done by specifying the subject, predicate, object. In case of JOPA, this means that when an entity is being loaded, we filter the statements by the subject (representing the entity identifier). This approach thus cannot be used for this ticket, as we would need to be able to specify multiple subjects at once.
Instead, we will (probably) have to generate a SPARQL query that will fetch also the referenced entities with their attributes and then map the whole result list to an object graph. This also brings the usual issues with inferred statements (inability to control getting of asserted/inferred statements per property).
As a user, I want to optimize the entity retrieval so that when an entity has an eagerly loaded attribute, its value would be fetched as part of the root entity, thus reducing the number of repository calls.
Implementation notes:
The underlying APIs that we use (Jena, OWLAPI, RDF4J) are based on the notion of statements where filtering can be done by specifying the subject, predicate, object. In case of JOPA, this means that when an entity is being loaded, we filter the statements by the subject (representing the entity identifier). This approach thus cannot be used for this ticket, as we would need to be able to specify multiple subjects at once.
Instead, we will (probably) have to generate a SPARQL query that will fetch also the referenced entities with their attributes and then map the whole result list to an object graph. This also brings the usual issues with inferred statements (inability to control getting of asserted/inferred statements per property).