You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are two reasons for replacing graph with method. Firstly, because graph is confusing and leads to bad APIs, and secondly, because existing HexTuples implementations use graph for expressing something else: methods.
Graph often refers to the URI of the document that contains all the triples (which is a clear definition). That encourages weird API design, since the subject should resolve and give you the same data. In other words, graph SHOULD be the same as subject.
HexTuples and linked-delta are, in practice, closely related. We use HexTuples-NDJSON to communicate state changes in our stack. This also means that we use the graph field for something very different from what graph usually means. We use it as a method field, which contains a URI that points to some definitaion of a manipulation. It describes how the HexTuple should be interpreted, and how it should modify some target graph.
I feel like this method concept, from linked-delta, is extremely valuable. Combined with the other five fields of HexTuples, this allows for a highly powerful, RDF-compatible standard for Event Sourcing.
So, how do you feel about replacing graph with method?
The text was updated successfully, but these errors were encountered:
There are two reasons for replacing
graph
withmethod
. Firstly, becausegraph
is confusing and leads to bad APIs, and secondly, because existing HexTuples implementations usegraph
for expressing something else: methods.Graph often refers to the URI of the document that contains all the triples (which is a clear definition). That encourages weird API design, since the subject should resolve and give you the same data. In other words, graph SHOULD be the same as subject.
HexTuples and linked-delta are, in practice, closely related. We use HexTuples-NDJSON to communicate state changes in our stack. This also means that we use the
graph
field for something very different from whatgraph
usually means. We use it as amethod
field, which contains a URI that points to some definitaion of a manipulation. It describes how the HexTuple should be interpreted, and how it should modify some target graph.I feel like this
method
concept, from linked-delta, is extremely valuable. Combined with the other five fields of HexTuples, this allows for a highly powerful, RDF-compatible standard for Event Sourcing.So, how do you feel about replacing
graph
withmethod
?The text was updated successfully, but these errors were encountered: