Ordered Container by Johannes Mockenhaupt.
From the post:
Mark Needham – via an interesting blogpost – made me go back to finish my pondering on how to model an ordered container. By which I basically mean an ordered list in a graph. Trimming down what he describes to the problem of containment and order, I use the example of songs that are part of an album and part of a playlist, both of which are ordered. Actually, I was modeling that anyway. So just doing the old NEXT relationships on songs to order them won’t work, since the unanswered question would be “who’s NEXT is it anyway?”. The album’s, the playlist’s? Or from another container that will be added in the future?
But why should the NEXT relationship go on the song in the first place? The song doesn’t care. Both the containment and the order are concerns of the album and playlist – the containers. So let them handle it. But how? Have HAS relationships from the container to the songs with position properties on the relationships? Awkward and not very pretty to query. Nor very graphy. So the position can’t be on the song node and it can’t be in the relationship … guess we need more nodes! Let’s extract the ordering into separate nodes:
Interesting but what puzzles me about the “next” relationship/edge is that I have to traverse all of the “next” relationships in order to reach say the fifth song on an album or playlist.
I would treat the order of the songs as a separate node, perhaps AlbumOrder, which contains an ordered list of the song as they appear on the album. Each song (represented by a separate node) can have an albumOrder relationship with the AlbumOrder node.
When at any song that appeared on the album, I can check its albumOrder (or playList1 or playList2) order relationship to discover its place in that album or list. Moreover, without unnecessary edge traversal, searching for another song, I can traverse the list and jump to any song that appeared on the album (assuming the song name and node ID have been captured by the list).
Suggestions/comments?
PS: True that my solution leaves the subject of the relationship of the songs implicit, but if all I am going to say is “next,” that hardly seems worth an edge.
> I would treat the order of the songs as a separate node, perhaps AlbumOrder, which contains an ordered list
Do you mean storing an array of node ids on the AlbumOrder node?
Well, as the Neo guys always say “ask first what you’re going to ask of your graph”. It comes down to how to you want to access the graph. In my scenario, I have albums/playlists that are all < 100 items. So performance-wise I'm fine just fetching all nodes and picking the nth out of it if I want a specific one, but usally I want the entire list. Though admittedly, the gist is short of queries. Guess I should update it to work out how I practically want to access the data.
P.S. The graph gists have a Disqus section at the bottom where the idea presented can be discussed 😉
P.P.S. The captchas on your blog are a major PITA, they're hardly decipherable.
Comment by jotomo — December 13, 2013 @ 4:00 pm
Yes, an array of node in the AlbumOrder node. Just to make navigation easier and less edge heavy.
Yes, the captchas are a pain and I avoided using them as long as I could. When I had to delete 10,000 fake registration emails I decided it was time for better security.
Sorry, they bother me as well. But you can refresh if you to find an easier one.
Comment by Patrick Durusau — December 18, 2013 @ 12:01 pm