-
Notifications
You must be signed in to change notification settings - Fork 2
Consume Ghent decisions #8
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
base: development
Are you sure you want to change the base?
Conversation
|
@Rahien What do you think of my suggestion of trying things out on the server? Relying only on the delta ingest I don't get the results I want and I'm not sure whether that has to do with my logic being incorrect or the fact I'm missing data from the initial sync. |
|
@brechtvdv When filtering out the Ghent decisions I'm keeping all properties that I found were available in Lokaal Beslist for Ghent decisions. Since that translates to a bunch of For each type I made an overview of the properties: |
|
Why is there a SPARQL Construct query for each property and not combined in one query using OPTIONAL or UNION? Or use a query to passes all properties through? |
LBRON-410
Decisions are consumed from Lokaal Beslist with the ones from Ghent being filtered out. All incoming decisions get ingested in
http://mu.semte.ch/graphs/decisions/landingand the ones from Ghent get singeled out inhttp://mu.semte.ch/graphs/decisions/ghent.I documented my thinking process on the selection of Ghent decisions, the choice of the harvester endpoint and the mapping here: https://app.gitbook.com/o/-MP9Yduzf5xu7wIebqPG/s/grRYjcouX0uZY2P6PYBl/data-analysis-research/dataset-city-of-ghent/consuming-from-lokaal-beslist.
I updated the README to explain how to run the initial sync first and subsequently enable delta ingest. However, the initial sync takes a very long time to finish, making it difficult to test out locally. I would suggest to review the mapping
CONSTRUCTqueries, try running it on the server and see there what went well/wrong. All data is kept in separate graphs so it won't mess with data that's already present on the server.I know there are a lot of Files changed in this PR, however the structure is pretty straightforward: for each RDF type we're mapping, there is a folder with a
CONSTRUCTquery for every property. Also, in each folder I put a README with an overview of the type's properties: