Hi,
We’re playing around with showing geographical data in OpenAleph (a.k.a. having maps on the screen) and it made me think about how FTM describes places in the real world.
There’s the Address entity, which is a bit of a hybrid. It tries to be a parsed address string regardless of what this address points to, which is great (works well with PO boxes as well as street addresses, etc). But it also comes with for example an Open Streetmap ID property, which in the logic of OSM as far as I understand is used to describe actual structures (So the OSM ID would describe the border of a piece of land or an actual wall somewhere, rather than the abstract address).
And then there is RealEstate, which comes with useful properties to, well, describe real estate. It’s also very close to Address in a way, because it does include properties like lat/long coordinates, so clearly it seems to be intented to not only describe the nature of the real estate asset, but also it’s place in the real world.
I wonder if there is a way forward, in which we combine these two into something that can be used for both: Describing the where and the what of a non-movable object in the real world. Or, alternatively, make sure we have one for each, clearly distinct?
Just putting this out here as a discussion starter. I don’t have an answer and of course backwards compatibility is super important with these two popular schema types. But I think for us, developing OpenAleph into a direction that will be able to do more with geodata, it would be super helpful to get some input on this debate.