I was using Freebase to get all movies/films there for my website, but it's getting shut down soon. so I was searching for another free database for movies and came across Wikidata. To be honest it's too complicated to understand how to query all the movies.
So I thought you guys could help me to get all the movies in Wikidata. In the future I want to include TV shows and series as well.
Programming language doesn't matter, I want to use web query with a link.
you can look for all the entities that are an instance of film, which in Wikidata is translated as:
P31 (instance of) -> Q11424 (film)
For the moment, the best way to do this query is to use the wdq.wmflabs.org API, where this query translate as: http://wdq.wmflabs.org/api?q=claim[31:11424] (avoid making this query in a browser as it will probably make it crash due to the ). At the moment I'm writting, this requests returns 157038 items in the form of numeric ids (ex: 125). To get the Wikidata ids, just add a leading Q -> Q125.
To get the labels and data from all those Wikidata ids, use the Wikidata API wbgetentities action: https://www.wikidata.org/w/api.php?action=wbgetentities&ids=Q180736&format=json&languages=en.
Beware of the 50 entities per-query limit though
[UPDATE] Wikidata now offers a SPARQL endpoints: the same query in SPARQL or even this same query but also including subclasses of films
Related
We are using the personalization module to setup page variants (page-level) using a headless approach (JS Frontend).
Reading the docs, I understood that there is either a Query nodes or Get children scenario. It looks like that page variants are only handled when not using the Query nodes case. Unfortunately, I can not order nor filter the results in that case.
Is there any chance to use filter and orderBy params but also returning page variants based on my request traits? How would such a request look like?
For performance reasons, the variants filtering on queries is not supported. Hence, short of writing your own EP, there is no solution.
As alternative/workaround, you can perhaps run query and then on the path of each result make a call to retrieve a variant of that result via individual node retrieval EP, but that's also slow and waste of bandwidth ... perhaps getting list of nodes you want via GQL EP and then getting variant for each is tiny bit better (but not much).
I have a book collection for example, each book has 'genre' field. How to query all books which genre is "fantasy" or "historical"? Like SQL SELECT * FROM book WHERE genre in ("fantasy", "historical"). Pretty usual SQL query as my opinion.
I found this feature request in GitHub, which isn't resolved yet. The Firestore documentation says: "Logical OR queries aren't supported". So, I cannot do such simple query in Firestore? What is a workaround? Should I query each genre separately and join the result?
Note, that I found similar questions like "How to get multiple documents by set of ids?", but not about custom properties. For ids, there is 'getAll()' method in the js admin sdk for example.
It is not supported in firestore as you correctly identified. You can send two separate queries and merge the results locally. This is how it needs to be done unfortunately. If yours is a simple usecase, sending two separate requests shouldn't be a problem.
However, have a look at rxfire package which is officially supported by firebase. Note that it doesn't support or queries per se but with the help of rxjs, it makes such tasks easier to manage. Here's an excerpt from the link below on what it can do:
Firebase provides realtime streams and async callbacks to do all sorts
of awesome things in your app. Getting data from one realtime stream
is easy enough, but what if you want to join it from another?
Combining multiple async streams of data can get complex. At Firebase,
we wanted to help simplify things, so we created a new JavaScript
library: RxFire.
Link to introductory blogpost: RxFire
I'm trying to follow JSON API. I need to expose CRUD access to a nested resource: product reviews.
Prior to using JSON API, I'd expect a REST interface like this:
GET /products/:product_id/reviews - list reviews for a product
POST /products/:product_id/reviews - add a review for a product
PATCH /products/:product_id/reviews/:id - update a review for a product
DELETE /products/:product_id/reviews/:id - delete a review for a product
I see some mention of a nested structure like this in the spec:
For example, the URL for a photo’s comments will be:
/photos/1/comments
But I'm not sure whether this structure is intended for all actions.
On the one hand, POST /products/:product_id/reviews for creation seems redundant if I'm going to specify the product in the POST body, under the review data's relationships.
On the other hand, if it's useful to specify a product id when deleting a review (maybe it isn't), DELETE /products/:product_id/reviews/:id seems like the only sane way to do it; people argue about whether a request body is even allowed for DELETE requests.
I could nest for some requests and not others:
GET /products/:product_id/reviews - list reviews for a product
POST /products/:product_id/reviews - add a review for a product
PATCH /reviews/:id - update a review
DELETE /reviews/:id - delete a review
But that seems weirdly inconsistent.
I could never nest:
GET /reviews - list reviews for the product specified in params
POST /reviews - add a review for the product specified in params
PATCH /reviews/:id - update a review
DELETE /reviews/:id - delete a review
But that seems awkward, and doesn't seem to match the first quote I made from the docs.
Should nested resource relationships be reflected in the URL when using JSON API?
I really like your question, since I have been having the same thoughts. I'm puzzled that no one has left an answer yet.
I have been using JSON API a little over a year on a production system and I would like to give my two cents.
At first when I started the project that was going to use JSON API, I was in doubt of nested vs non-nested resources. I then ran into issues with nested resources that would have been avoided with non-nested resources.
To take the same paths as in your example, consider the GET /products/:product_id/reviews endpoint.
When this is made it make very much sense to nest a review under a product because we are initially showing reviews in context of a product. Everything is good.
We then later want to build a page in the frontend that shows a user and all the reviews that user has authored.
Although we already have an endpoint for getting reviews, we will have to build a new one, e.g. GET /users/:id/reviews.
If we hade just put the first endpoint on GET /reviews with a filter of ?filter[product_id]=:id, we could just add a new filter to that endpoint, which makes much sense IMO.
I do use nested resources, but only for singleton resources like GET /users/:id/email_settings and a few other special cases where it makes sense.
In my experience, it makes it easier in the future if each resource is thought of as independent from other resources. There exists resources and relationships between resources. No resource "owns" another resource in the context of the API (in context of business-logic it's another story).
I have worked with this strategy and it still surprises me how well it works when adding new functionality to existing endpoints and when adding new endpoints.
If you coming from CQRS camp, you will understand why design Restful API sometimes awkward. It is awkward because naturally Query actions (GET) and Mutation actions (POST, PATCH, DELETE) should talk in two different languages.
Query actions naturally relationship-oriented and data rich; while Mutation actions not. So it feel easy to use nested URL to traversal between relationship entities.
But Mutation you should provide just enough information for tasks. Sometimes it is redundant like your Post example. Sometimes missing like your DELETE example. Sometimes you have a task involve many resources; you don't know where to put in.
You should check Facebook Graph API or Azure Graph API, they met same problems and have some good solutions. It's important that you should follow consistent design.
Some rules are:
DELETE, UPDATE always to direct resource.
POST use with nested resource if you want create both object and main relationship. Secondary relationships should put in BODY. If you have two equal relationships, consider have both nested APIs.
Use POST against fake resource to for tasks involve with many resources.
POST /transferfund
Use POST against fake relationship for tasks could not fit with any HTTP verbs. For example, you want have body for delete action, use
POST /resource/id/deleteItForMe
{ reason: "I hate it"}
As per REST framework, we can access resources using GET method, which is fine, if i know key my resource. For example, for getting transaction, if i pass transaction_id then i can get my resource for that transaction. But when i want to access all transactions between two dates, then how should i write my REST method using GET.
For getting transaciton of transaction_id : GET/transaction/id
For getting transaction between two dates ???
Also if there are other conditions, i need to put like latest 10 transactions, oldest 10 transaction, then how should i write my URL, which is main key in REST.
I tried to look on google but not able to find a way which is completely RESTful and solve my queries, so posting my question here. I have clear understanding of POST and DELETE, but if i want to do same update using PUT for some resource based on condition, then how to do it?
There are collection and item resources in REST.
If you want to get a representation of an item, you usually use an unique identifier:
/books/123
/books/isbn:32t4gf3e45e67 (not a valid isbn)
or with template
`/books/{id}
/books/isbn:{isbn}
If you want to get a representation of a collection, or a reduced collection you use the unique identifier of the collection and add some filters to it:
/books/since:{fromDate}/to:{toDate}/
/books/?since="{fromDate}"&to="{toDate}"
the filters can go into the path or into the queryString part of the url.
In the response you should add links with these URLs (aka HATEOAS), which the REST clients can follow. You should use link relations, for example IANA link relations to describe those links, and linked data, for example schema.org or to describe the data in your representation. There are other vocabs as well, for example GoodRelations, and ofc. you can write your own vocab as well for your application.
I am attempting to develop a Freebase Explorer application. one part of the application allows a user to drill down through freebase Domains, then types then type instances, then finally using the freebase Topic API i display the selected Type Instance. however many of the type instances lists do have "null" for the name and machine ids for the id.
what combination of freebase api calls can i employ to return something of value/interest (man readable) using a freebase mid?
where should i look in the freebase site/wiki to help?
A machine ID (MID) can be used anywhere any other ID is used in Freebase. There's no requirement that an object have a name. "Something of value/interest" will depend a lot on the context, but the types and property values of an object help show how it's connected to the rest of the graph.
You might also look at the existing Freebase Schema Explorer app for ideas and inspiration.
Tom's explanation regarding machine ids is spot on, here is some additional information:
Domains and types are schema objects and it's preferable that you use human readable ids for these. Items "of interest" are usually topics, and those are all objects that are typed with /common/topic.
You can use MQL to get a list of types and domains, and then as you say use the Topic API - which will also be available in the new APIs - to get all the data for a given topic.