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

statement IDs #7

Open
quoll opened this issue Nov 1, 2022 · 2 comments
Open

statement IDs #7

quoll opened this issue Nov 1, 2022 · 2 comments

Comments

@quoll
Copy link
Owner

quoll commented Nov 1, 2022

All statements currently have IDs, however, these are not accessible through user interfaces. This issue is to introduce a query operation that can reference and bind statement IDs.

Basic graph patterns currently look like:
[subject predicate object]

where the predicate and object can be optional.

Add an optional transaction and :as values:
[subject predicate object tx-id :as id]

This ticket focuses on the statement IDs.

Implementation

There are 3 possibilities here:

  1. [s p o] This is an unbound anonymous var for the ID.
  2. [s p o :as ?id] where ?id is unbound
  3. [s p o :as ?id] where ?id is bound

In (1) we have 2 options: allocating a var that we never see, or keeping the code as-is. We may want to inspect the options here, but I think that by handling the 3-wide vs. 4-wide patterns then we could end up with a lot of extra code.

In (2) we expand BGP resolution. This may need a whole new set of patterns to match against in the protocol. Depending on (1) then we're either going to make all the pattern resolutions 4, or else we're going to double the side of the graph API.

In (3) then look up the statement index keyed by ID. If bound columns do not match, return nothing. Otherwise, return bindings on any unbound columns.

@simongray
Copy link

I have no idea about the implementation aspect, but I must say that I really like the :as id as it perfectly matches existing Clojure conventions. Smart thinking! Or maybe you got the idea from somewhere else, but still...

@quoll
Copy link
Owner Author

quoll commented Nov 7, 2022

No, it was just because it seemed obvious.

I also need to consider adding graph to each pattern, since this is also a SPARQL thing

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