Oh this one is easy!

First, all of those are just tags, no need for content json shoehorning.

No need for date, obviously, since created_at us already there (and can be back dated if need-be)

Name could be subject, per NIP-12 (iirc), though this is not important.

Coordinate should be waypoint events, not part of the first event; which gives you speed per split/recorded waypoint and other data.

No need for totals; just when you hit finish you post a new event signaling the end of the run.

The main thing is that nostr’s basic building construct are events, so you can use that framework to think of ongoing-things as separate, linked, events.

And if you don’t want that flexibility and just want to log an event after the fact, more like a journal entry, you can do as suggested at the beginning; just or those things as tags.

The main thing to think about is that, usually, hierarchy in data structures represents either different concepts (eg. product <> inventory) or things that occur non-atomically; thus the modeling thinking in β€œevent” terms shows that this should probably not be hierarchical but rather separate structures.

Thanks for coming to my TED talk. πŸ˜‚πŸ˜‚πŸ˜‚πŸ˜‚

Reply to this note

Please Login to reply.

Discussion

Cc #[5]​ some ideas to think about data modeling in nostr

Fantastic, it’s a new paradigm to me, so feels like a brain teaser πŸ˜‚

But yeah, i see the benefits already, because my next question was going to be about providing granular access to my runs or whatever activities data

Not it’s fairly straightforward, i can have the waypoints encrypted so that only trusted users would see them and the rest of data can be public πŸ‘

Thank you

Exactly; this data modeling is simpler AND more flexible

If you think in terms of events you typically get it right instinctively 😊

Could you maybe recommend some good reads on the topic?

Ooof, the ones I really liked on data modeling i read over 25 years ago and can’t remember the names; they were mostly just university course books with very generic names πŸ˜…

πŸ˜‚πŸ˜‚πŸ˜‚πŸ˜‚πŸ˜‚

My recommendation for data modeling is Domain Driven Design by Eric Evans. It's emphatically not this kind of design, but is a very good book. Other than that, Eric Normand is coming out with what sounds like a good book about bottom-up design. The culture in Clojure is what taught me most about data modeling, you could do worse than listen to Rich Hickey or read Brave Clojure.