Now comma is used as a value separator, which means if I use it to list parts of some address, these parts will be added separately.
Maybe it works as planned but it doesn’t see to me so, because in fact it is one place, which in my understanding means it should be added as one record.
I consider the Origins field to be completely broken.
My beef is quite different from yours. Specifically I think putting “Origins=France” on a food product like spaghetti bolognese makes no sense: what comes from France? The beef? The tomatoes? The wheat flour? So I always put “ origine ” which leaves it to downstream apps to deal with the mess. But at least when that field is finally split as it should (similar to how the packaging info was split), it will be possible to migrate the information correctly.
I’m not sure putting a full address makes much sense. I could see specifying the region in the case of AOP/IGP products but that’s about it. And that raises the issue of how to then map the region to a country or how to specify both as related items and not separate entries.
As far as I can tell none of this can be done right without changing the database schema.
I also don’t think any reason why not to do that, if it is specified.
Same thoughts. I don’t see any reason for now to invest my time for filling origin data field, when it is physically not possible to store this information correctly. Same story with stores. In fact, I believe places and stores should have separate tables (or how is it called in noSQL DBs?) and have different qualities and fields. And as you mentioned it should be possible to link these entities to each other.
Regarding the stores what I’ve been told at last year’s OFF Days is that this field is essentially superseded by the Open Price data as it not only has the store’s name, but also its exact address (backed by OpenStreetMap) and, quite importantly, a date too. I cannot guarantee that this is cannon though.
There’s a short description of the Open Price data there.
