Historic Available Time Interval of Entities

[Reapor-Yurnero]

As discussed last time, it seems that it would be useful to capture the information at which time period a particular entity was available in history in many use cases. For instance, the removal or movement of equipment should ideally be represented in the brick graph. Another example, certain points could be only available for a period of time -- it would be useful to capture this info in the time series representation as well.

A simple property potentially named wasAvailableDuring or wasValidDuring that can be applied to entities of the Equipment/Point class will work well for the second example. But for the first example, a location-time aggregation may work better.

[gtfierro]

Hi @Reapor-Yurnero I don't actually think it's an obvious decision to represent the removal/movement of equipment inside the Brick graph. Adding this kind of bitemporality typically make databases much harder to query because there are additional fields that must be considered when establishing the timeframe to be queried. I've solved this in other projects by time stamping the entire Brick graph and deciding which version to query based on the time period you are interested in. (You can see some basic support for this here: https://brickschema.readthedocs.io/en/latest/persistence.html)

This isn't the first time these questions have come up though. Do you have examples of the kind of use cases / queries / etc that you are trying to address? I'd be interested in working with you to make sure we have a good solution for those

[gtfierro]

@Reapor-Yurnero now that you're back, let me know if you want to follow up on the above

[epaulson]

Overall this is a hairy problem because no matter how far you go into it, there will always be use cases that are beyond what we support. But every use case we support pushes additional work onto all consumers - say we just add a 'validStartTime' and 'validEndTime' property to each entity, so you can safely "retire" a piece of equipment but still keep it in the graph, so you can do historic analytics on it - every query now needs to know to filter out anything that has validEndTime in the past.

This feels like one of those things where we should have a way to do it if you need to - maybe we can get away with saying "if you're sure your graph doesn't have anything but the current configuration you can leave all of these time qualifiers out of your query"