-
Notifications
You must be signed in to change notification settings - Fork 4
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
Graphs #19
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The internal APIs already support querying with graphs, but this isn't exposed to the end-user. A lot of work around graphs has been done already and it's a useful feature when considering data from many different sources.
There are two separate but connected concepts to be distinguished; data fetching and data querying. Currently all fetched data ends up in the default graph,
Manipulation
The use-case of graph manipulation probably arises from the possibility to query multiple graphs
Querying
What are the options?
Expansion of current API
The current querying API is essentially default implicit.
lrs.getResourceProperty
lrs.default.getResourceProperty
lrs.all.getResourceProperty
lrs.named[graph].getResourceProperty
Adding a querying context
The problem can be abstracted into a query context in which the user can tweak the behaviour of the query resolve mechanism, so that the expansion described above doesn't target a specific graph, but rather a set of behaviour including but not limited to the graph. This would make a unified answer to the current question of how to override certain selection behaviour.
From high to low confidence:
Fetching
Should request/responses be separate from the graphs? This would allow for instantaneous answering of data requests for a certain graph, but implicates an additional complexity in managing the cache
The text was updated successfully, but these errors were encountered: