graphaware/neo4j-timetree

[Feature Request] add a way to get the timestamp for a given node in a timetree

swelham opened this issue · 8 comments

I have a use case where I have a node that is linked to a timetree day, month or year node and I need to be able to get back the timestamp from that link.

For example MATCH (p:Person)-[:DATE_OF_BIRTH]->(day:Day) RETURN p, day will return the day, however I then need to match on the month and year to get the full date. This becomes more difficult when the person node might be connected to a day, month or year node which requires three different match statements making the query more complex.

I feel a good solution to this issue is to store a long timestamp that represent the date/time on the respective node.

For example the three nodes representing the date 2018-02-28 would have the following timestamps.

(:Day {timestamp: 1519776000000})
(:Month {timestamp: 1517443200000})
(:Year {timestamp: 1514764800000})

This would allow the example query above to be much simpler MATCH (p:Person)-[:DATE_OF_BIRTH]->(date) RETURN p, date.timestamp and the query no longer needs to be aware of which node it's matching on.

Quick question, why not store the actual information on the Person node itself? Then you're query would look like this: MATCH (p:Person)-[:DATE_OF_BIRTH]->(date) RETURN p.birthDate. The reason this may be better is that you might want to represent that with a different resolution than in the TimeTree (e.g. record date of birth with minute precision but only link to TimeTree with day precision). WDYT?

That's a very good point about storing a different precision compared to what the node is being linked to. I was actually going to ask the question of storing data on the node vs getting it from links on the neo4j slack. In my case (as far as I can predict), I'm always going to display the dates as a day, month or year so I felt that I was potentially causing a future data consistency issue by having that data represented in two separate places. However I'm pretty new to graph databases, is this a common design practice?

The best way to address this (imho) would be the following design: Store the DOB as a long timestamp on the Person node, let TimeTree automatically attach this to the tree (never inconsistent, since it's happening in the same tx), find people using TimeTree, display DOB using the property on the person node, formatted as you wish. That should achieve all you need.

I also think that it would be helpful if we could YIELD the time along with the node, especially when using the ga.timetree.range procedure. I'm not sure I would want to maintain the date in every event node. The whole reason I want to attach to the timetree is so I can maintain the dates through the graph.

Sorry for a late reply on this, been rather busy lately to work on my side projects!

In addition to the above requirements I am also now looking into storing dates where there is a lack of historical accuracy. For example sometimes we only know roughly when an event occurred, such as the birth of Caesar is known to be either July 12 or 13 100 BC and so I would need to store two dates for this person. I would see this as just being two separate relationships to the time graph, however it gets more complex when we have time ranges such as 400 BC to 380 BC or cases where we believe something to have happened within a range or a specific date depending on which research is being accounted for, such as 400 BC to 380 BC or circa 350 BC.

I feel like I can correctly model this within the graph in a way that would allow me to craft the types of queries I would need. However I'm unsure on how I could achieve this by storing the date on the event and letting timetree link it all together for me.

@swelham You may get some benefit from having two interdependent time graphs; one focused on 'watch time' and one focused on what I would call 'human time' (see the definition of kairos in this article: https://daily.jstor.org/what-time-wrinkle-in-time/ )

@IianNeill, author of The Codex, has some really well-thought-out perspectives on tracking historical events in Neo4j. Highly suggest the conversation with him.

Thanks for the pointer to Iian and The Codex, it's very similar to my side project. I will definitely reach out to him and see if he has time for a chat at some point.