-
-
Notifications
You must be signed in to change notification settings - Fork 2
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
ODD: Sufficient ReflowOS integration for initial use cases #21
Comments
ODD developers thought of some data visualization ideas regarding the ODD. One of those ideas is a map, where the resource-specific supply and demand of the different locations are being displayed. Another one is to visualize processes as graphs. Do the following make sense:
|
I think you can do this by querying Economic Resources and SpatialThings separately. What I couldn't understand is that do you mean querying by ID, name, quantity, unit, etc.? Because that's a different thing.
You can query SpatialThings. But are you referring to filtering here too?
Can be done by querying Intents. But are you referring to filtering here too?
Yeah, this needs to be implemented.
You can use
Is this also a filtering question? |
From our perspective it is desirable for each visualization process to get as much information out of a single query as possible, because each request inherits an own harvesting-process. For the "demand-supply"use-case we need a table, which contains every resource with its respective ID, current location, quantity and unit. In order to achieve this we currently have to send a request to the same "economicResourcesFiltered(locationID)"-Endpoint for every locationID. This constitues a process, which is divided into as many harvesting-steps as there are locationIDs. Instead of filling our DB piece by piece we would prefer having access to a query, which outputs a list of all locations and all of their respective resources (name, unit, id, quantity). At the same time a query, which just outputs all locations (ID, name and coordinates) would come in quite handy as well. |
Hi, Jonas. GraphQL works somewhat differently than the well-known RESTful JSON APIs over HTTP: You can do multiple things in one go. You can query for multiple
and parse the result easily. I used the IDs of the locations (called You can also query locations with I hope it helps and please comment on my other questions. ^^ Cheers, |
Hi all, I suggest to start with a description of the idea and would like to ask you to provide support in the sense of how desired data can be requested. |
Do a query like this satisfy your needs:
You can also simplify it hugely by using fragments:
|
@MiMonecke I've got a thumbs up on this. Does that mean I can close the issue now? |
Hi @srfsh, Furthermore when we request all resources like suggested, it would be nice to request all available locations with their IDs, name, lat and long. |
Just to clarify my comment, I mentioned that harvesting as much data over GraphQL as possible for full ingestion raises a tension against its design priniciple of data minimisation. With respect to querying updates over time, GraphQL does offer subscriptions for updates over time are server side heavy, need to be server side implemented for each use case and not currently implemented for locations. Given that, I would suggest we review what may be needed or nice for updates over time over the queries you need once we have bedded down the queries that are suitable for your requirements for initial imports. Once we are there, I would suggest raising a separate issue to track that. |
I hope I'm not responding to the wrong part of this issue, I'm not totally clear on the question of how to get all the data you need in one call, vs how to get updates to that data pushed from the server. If I'm not properly connected to this discussion, please just ignore. Just another option. This particular reverse query probably doesn't exist, but it could. And I notice I haven't defined it on my filtering / query app guidance (in process), I'll add it. It drives from location instead of resources. I don't know how many locations will not have resources. Not tested, may not even compile, but this is the idea:
Another thought to consider. Do you want to show all resources at a specific location, irrespective of it they are already planned to be used by the primary accountable itself? Or do you want to show resources being offered by a primary responsible located at a specific location? If the latter, then you will want to use offers (Proposal, Intent, etc.) rather than just resources at a location. |
Assess and if necessary implement, debug, test & verify ReflowOS GraphQL endpoints for ODD Valueflows visualisation to support initial use cases.
The text was updated successfully, but these errors were encountered: