Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider replacing 'graph' with 'method' #5

Open
joepio opened this issue Jun 8, 2020 · 0 comments
Open

Consider replacing 'graph' with 'method' #5

joepio opened this issue Jun 8, 2020 · 0 comments
Assignees

Comments

@joepio
Copy link
Member

joepio commented Jun 8, 2020

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants