Unable to extend the FROST-Client entity model

[abourdon]

Hi,

I extended the base OGC SensorThings API entity model to fit with my business needs. However, I’m unable to express those extensions to the FROST-Client entity model.

Let’s take a concrete example: I would like to define a FooObservation that inherits of Observation (e.g. to only handle Foo Observation#result type instead of the base Any type).

To use my FooObservation with FROST-Client, the first trivial solution would be to extend the FROST-Client’s Observation entity. However, as any FROST-Client’s entities inherit of Entity<T extends Entity<T>>, then Observation inherits of Entity<Observation>, and so T is restricted to only be Observation and not an extension of Observation as our FooObservation.

The second solution would be to directly inherits of Entity<T extends Entity<T>>. But in this case, we have to call Entity’s constructors with a given EntityType. And this EntityType is a enum (so not extensible) of FROST-Client’s entities then we lost our specific FooObservation type.

Do you plan to let FROST-Client’s users to use their own OGC SensorThings API entity based model? If not, have you any advice to let me do that?

Regards,
Aurélien

[hylkevds]

We've not considered it yet, but I guess it's not a bad idea.

The question is, what kind of extensions would you need. Extensions of the existing entity types, or also completely new entity types, with new relations.

One of the problems will be explaining the json parser which implementation of Observation to use, or do you only plan on using it on the Observation-creation side, and not on the read side?

[abourdon]

Hi @hylkevds,

Extensions of the existing entities. To express some constraints against the generic OGC SensorThings entity model. For instance: https://github.com/StoreConnect/storeconnect-sensors-api#the-storeconnects-sensor-api-data-model.

You could imagine to ask clients to provide the concrete type to be used by JSON parser when serialize or deserialize entity. You could also imagine use a default implementation to be able to use the default OGC SensorThings entity model by default.

Note that PR #4 provides a way to define its own entity builder model. Even if created entity is using the currently not extensible FROST-Client' entity model, this could be a first step to let user to define its model constraints.