search

urbanobservatory / standards

Standards and schema documentation for the observatories programme
2 stars 0 forks source link

Inner consistency of our linked-data #27

Open EttoreHector opened 4 years ago

EttoreHector commented 4 years ago

A couple of considerations regarding the inner consistency of our linked data:

  1. The Deployment Dep1 is DeployedOnPlatform-s Plat1 and Plat2, and conversely the Platform-s Plat1 and Plat2 are inDeployment Dep1. After a while, Dep1 expires and the two Platform-s Plat1 and Plat2 are used in a new Deployment Dep2. If someone queries for deployment Dep1, he/she will see that the property DeployedOnPlatform is an array containing Plat1 and Plat2. However, if the user follows the link to either of those two platform's uri, he/she will see that the platforms are now inDeployment Dep2, which somehow breaks the inner consistency of the linked data.

  2. Same considerations can be applied to Deployment-s that have a list of DeployedSystems (such as sensors), but those systems are subsequently used in a new Deployment (i.e. the systems' property HasDeployment will not point to the original Deployment but to the new one).

How do we address this?

SiBell commented 4 years ago

Tricky one.

I actually don't mind your example. Even after the platforms have moved to Dep2 it's still valid that Dep2 was deployed on these platforms, even if the platforms are no longer in Dep1.

Having said that I actually generate a new platform @id each time I move a platform to a new deployment. This works ok for platforms such as weather-stations, but not sure it works so well for a platform such as a lamp post.

One challenge with your example is that when the Platforms are moved to the second deployment the user might start editing some of the Platform's metadata, e.g. its location. This data may be sensitive and only users with access to Dep2 should be able to see it. So the question is, when a user of Dep1 follows the link to Plat1 should they actually be presented with a Forbidden status code. Perhaps this is an argument to keep all deployment-specific metadata in a separate table/collection. This way Dep1 users can still see very basic information about the platform when they follow the link, but nothing relating to Dep2.

You could start saving start and end dates for when a platform was each each deployment. I haven't needed to do this with platforms, but I have done it with sensors. It still doesn't really solve you problem though, it just helps give an explanation as to why access is now forbidden.

EttoreHector commented 4 years ago

Thank you, Simon.

Yes, I guess we can be OK with that kind of scenarios. After all, the Development Dev1 will still contain a historical snapshot of what that Deployment used to be, what it was about and what System-s/Sensor-s/Platform-s it consisted of.

As you also suggest, we may want to add a start-date and end-date to indicate the life-span of a Deployment. In this way, if someone is interested in the data produced by the Sensor-s that used to be part of that Deployment, he/she will query for measurements taken by those Sensor-s (now belonging to a new Deployment) during the relevant time-span.

In this case, however, we may need to expand the snn definition of Deployment so that we can add the start-date and end-date.