-
Notifications
You must be signed in to change notification settings - Fork 0
Usefulness of DiplomaticRelations? #26
Comments
Is the idea here more to expand the |
The idea is: Remove all And after that, optional optimization step: Recalculate (i.e. derive, i.e. not inputted by users) |
Right, I guess a better way to phrase my question would be what data specifically would an |
This needs to be defined: the main difference is that Event will only have one In the end we store of course the same data, but it's just presented differently to the user: the user inputs events, instead of relationships. They very difficult part is to define cascade relationships between events. E.g. if an Event of type |
Difficult indeed. I like this idea and will think over what the best way to implement this behavior may be. |
Please pardon my nomenclature and let me know what terms are appropriate as I try to orient myself with the current architecture. tl;dr: Keep it simple and modular. Just have one base class that people can input data for and handle the complex options and meta information with separate and independent modules. I see two interfaces here. It makes sense to me that the back end exists primarily to connect these two. For simplicity, I will consider a request for the "political" world map of the year 1700, which should show whichever abstraction layer is defined by international sovereignty.
As an arbitrary middle ground in all of this, I propose the following modules (in increasing abstraction) so that any option works and it is easy to change when we change or minds:
In short, interface (A) usually makes Entities and interface (B) reads Layers. The back end uses Events/etc. to populate and parse a table of Entities, a hash map of cached Layers, and a directory of Polygon files. Finally, let us consider the aforementioned example as a sanity check.
Overall, I think the most important part of all this is to keep in mind the minutia but not get bogged down by trying to be overly general. I think we just want something that is easy to extend and change more so than something that is perfect in the first or second or tenth architecture. I honestly do not really care about 99% of the features we could have until we have a strong foundation that can cover the single one that matters most to me: having a 4D map that is what all precious attempts out there could not be. |
Wow, thanks for this message @wtokumaru! First things first, let's agree on terminology:
So I think there was a slight confusion between models and rows in your message. You also talk about modules, I assume they are Models? I disagree with:
So my version of your 20-point user story. This is a version without DiplomaticRelation, because the whole point of this thread is to remove it.
Overall, we are not rigid yet on db architecture, so improvement are welcome. However I don't see how exactly your architecture would work. If you think it's simpler/more universal/more performant, can you create a google sheet with tables/rows/columns, a bit like this, so that we have a clearer idea? Of course, we are not the only one thinking about this, cf CIDOC. Since that methodology is a standard, I'm trying as much as possible to converge towards their model, if possible. |
Ah, your terminology makes sense. I often used "models" to refers to rows but what I should have said was "instances of models" so yeah.
When I was last working on the project, all polygons were qgis shapefiles so it appears we have moved to geojson now. Will take your word for it on I/O speed. The geojson-territory relation makes sense being 1-to-1 but:
By "attached" I mean uploading a link, text file, pdf, video, etc. while filling out the form. I agree with your point though.
When I refer to "layers" AKA "maps" they can be stored in any format. Caching them as geojson makes sense to me so long as the stitching is already done before the front end needs to render. We should not have to perform any logic to decide which geojsons to display as we should have just a single complex one readily available.
What I am kind of imagining is that geojsons are non-temporal and events just point to them as needed. I agree that we should probably derive DiplomaticRelations. I am not set on deriving Territories from Events+Polygons, but I am biased in favor of atomic modularity. Territories feel "molecular" to me.
After reading more, I agree that Events should be children of Entities.
Once we remove all the topics better covered by other issue discussions, that leaves me with 3 thoughts:
Finally, here is a link to a simplified database architecture: https://docs.google.com/spreadsheets/d/11_ceUZohBJ35ddNHaUTBAM_DVzDBiw0Ld3CQM06LwbQ/edit#gid=0 Note that we could still have an interface that takes in "Territories" the same way we currently do and then just save the geojson separately from the rest in the same way we create Events separately. |
1 is addressed in #53. |
Layers are maps which stitch together polygons in different ways. I picked the term "Layer" while thinking about vaguely similar stuff like this: http://desktop.arcgis.com/en/arcmap/10.3/map/working-with-layers/a-quick-tour-of-map-layers.htm The default layer, which I assume to be |
@wtokumaru Answered in the Slack thread, but I want to put it here too: Your |
Probably not for v1, but still putting it here.
Assuming we have one abstract Entity class, and PoliticalEntity, Event and Person are subclasses. Does DiplomaticRelation only represent the
PoliticalEntity<->PoliticalEntity
relationship? How aboutPoliticalEntity<->Person
,Person<->Event
orPerson<->Person
relationships? Each will have a new model? Or should we have a generic Relation model to translate allEntity<->Entity
relations?One elegant solution, proposed by Ville, is to only use Events. So:
From these two events we can know that Belarus was a puppet state of the USSR between 1922 and 1991. Probably there should be a DiplomaticRelation derivative table in the db, for optimization purposes. But users don't input DiplomaticRelations, only Events.
The text was updated successfully, but these errors were encountered: