I’m looking into how to address bits and pieces of data in JSON (in this context: Support access to a datasets metadata · Issue #22 · cldf/cldfviz · GitHub ).
First, I played around a bit with JSONPath, but then came across JMESPath which seems to be a much better spec (and implementation).
Any experience with or opinions on that topic in the forum?
I have tried a few times to get into this sort of thing. The idea of being able to store not just data but queries in a data format is appealing.
Jq is a similar tool I tried to get used to.
The thing is, for me, I end just going back to filters and maps and so forth in JS, because I feel like I understand those kk d of queries in a step by step way. As soon as you get into wildcards and projections and so forth with the query languages I get lost. Like, this query doesn’t make much sense to me:
Sorry, that’s not the kind of answer you were looking for, maybe someone else here is familiar — @lgessler? @aryaman?
Oh wait, that quietly does make sense, same as this:
reservations.map(reservation =>
reservation.instances.map(instance =>
instance.state)
)
For my use case some declarative way to specify such a query is necessary. But most often, this query will be trivial, such as "dc:license"
. The most complicated stuff I would expect might look like tables[?"dc:conformsTo"=='http://cldf.clld.org/v1.0/terms.rdf#ExampleTable'].url | [0]
(in JMESPath).
So what I need is
- well specified - ideally with enough documentation around the spec
- somewhat familiar/intuitive, or alternatively with hopes of becoming the de-facto standard
- Python implementation
JMESPath is used by AWS - so that’s at least giving me hope of it being maintained.
Not familiar with JSON query langs I use CLDF for some of my stuff too but I have a script that converts the database to SQL for querying.
@aryaman Yes, that’s an alternative. Do you also dump the CLDF metadata into SQL? And is your script different from the cldf createdb
command provided with pycldf?
Yes it’s different, it’s a quick script that dumps to SQL for my own purposes, doesn’t use the CLDF metadata (didn’t need it to extend to CLDFs besides my own).
Don’t know much about this space, but this article comparing zq
to jq
popped up on my feed: Introducing zq: an Easier (and Faster) Alternative to jq | Brim
Oh nice, I always found jq
1) desirable and 2) bewildering!
Thanks for sharing this.