Clojurians Log v2

This is really good advice Al. I've never needed to put part of my model into the edge properties, so I've often wondered about the cases where that was needed. I hadn't really considered it before, but your advice here matches my intuition: don't build you model with edge properties. The main use I've had for edge properties has been around metadata, like: • who asserted the edge • date the edge was asserted • who has permission to view or modify the edge (not typically handled at this level, but it can be) • weight or probability of the edge • Context where the edge may be viewable (though this is often calculated from other metadata, like permissions, dates, author, etc.)

if you can ask any of those questions, you just pull it out into the model proper, and you wind up with things like W3C-PROV, which can be daunting, but you can use just pieces of it for tracking events and changes and such that most people want edge properties for

Personally, I've never wanted these things. I'm always responding to people who ask for them. Neo4j makes a big deal of edge properties, but I've worked with several groups who use Neo4j, and none of them have used this feature.

The issue with pulling provenance out into the model is that it can increase the complexity of the model, when the user mostly wants to interact with just the simple, clean model. But when they ask, "Who added this edge here, and when?" then it makes sense (to me) that it's a question asked at a different level. And SPARQL* is nicer than reification-style approaches

Anyway, I appreciate the clarity you provide in your original response above. Thank you

Yeah - I spent a while playing with SPARQL* and RDF* and came to similar conclusions @quoll. I was looking at it to model bi-temporality / versioning in graphs. I guess the main problem is that where there used to be essentially just one way to model something (reifying edges as nodes); now there are two. (Actually I guess there are three ways as you can reify metadata on graphs too). So from a purity perspective it complicates a simpler model; for a largely syntactic convenience. That said I think this could be more useful if databases would standardise on adding this metadata consistently in their management of graph data; for example if there were a bi-temporal RDF management standard that consistently added this metadata to all changes. I think part of the problem is that it’s not consistently modelled or applied; such that you can rely on it, and that baking some of this in at the bottom (ideally also in an extensible way) might alleviate that.