I am trying to get the notable_for field for this person, which appears on the web site
http://www.freebase.com/m/01z7_f
but this query returns an empty field
[{
"type": "/common/topic",
"notable_for": [],
"mid": "/m/01z7_f",
"name": null
}]
Am I using the right query here?
notable_for is a "synthetic property" which can't be queried via MQL. It is included in the Topic API though, so that's the thing to use if you need this property.
EDIT: One additional note -- the notable_for and notable_type properties are included in recent Freebase data dumps, so they can also be accessed that way:
$ zgrep ns:m.01z7_f freebase-rdf-2013-06-30-00-00.gz | grep notable
ns:m.01z7_f ns:common.topic.notable_for ns:g.1258t0lp5.
ns:m.01z7_f ns:common.topic.notable_types ns:m.01xrzmg.
Related
I am sending a request to the jsonapi node endpoint, and using the following parameter to include the "relationship" objects of those nodes for user (post author data) and user picture (avatar):
include=uid,uid.user_picture
This returns to me the json data of the nodes as well as all of the relationship objects lumped together (regardless of type) into the "included" array. The included array ends up looking like this by default:
"included": [
{
"type": "user--user",
"id": "4c717273-f903-4ffa-abe2-b5e5709ad727",
"attributes": {
"display_name": "cherylm1234",
...etc...
}
},
{
"type": "file--file",
"id": "4c717273-f903-4ffa-abe2-b5e5709ad727",
"attributes": {
"filename": "Cheryl-Fun.jpg",
...etc...
}
}
]
Context: We are trying to integrate jsonapi with an iOS app as the client/consumer.
My Problem: It's difficult to write up data models in the iOS client for these relationships (without looping and sorting every response) since they are all lumped into the same level of the "included" array. Also a problem is that each "type" will have its own set of attributes/fields so data models in iOS need to be built based on "type".
Question: Is it possible to change this structure so that all included objects are sorted by type?
I would like for the "included" array to be indexed by "type" where all objects of that type would be inside that index. Maybe something like:
included['user--user'] = [
{user-object},
{user-object},
...etc.
],
included['file--file'] = [
{file-object},
{file-object},
....etc.
],
I'm assuming this would require a custom module with some sort of hook where I could loop and sort the data before returning it to the iOS app. But, haven't been able to find any documentation on this type of json response modification.
Any help would be much appreciated.
Drupal implements the JSON:API specification. The specification specifies how a resource should be encoded. Both if it is returned as primary data or included as a relation resource.
If you want the data to be returned in another format, you would need to implement your own REST API in Drupal following another specification.
But if this is only about managing the data in a client, I would recommend to use one of the existing libraries for JSON:API specification. A list of implementations is provided at jsonapi.org/implementations/. The JSONAPI Swift package listed on that page seems to be well maintained.
I have meteor application made up of "notepads", each containing an array of "notes" which can be inserted into at any position, deleted from or have rows edited. This array is contained within an object with a variety of other information (ex. name, users, etc). Each object in my primary document will contain one of these arrays. For example:
{
"_id": "1234",
"name": "NotePad123",
"notes": [ {note: "this is my first test note"},
{note: "this is my second test note"},
{note: "this is my third test note"} ]
},{
"_id": "4321",
"name": "NotePad321",
"notes": [ {note: "noteA"},
{note: "noteB"},
{note: "noteC"} ]
}
Is there any way I can pass the "notes" as its own collection to my client so that the client can directly edit it as if it were not embedded? I am worried about a performance hit if I need to be passing the full notes array to the server every time I want to update it as there may be many updates it could become quite large.
I realize that I could create a new document and reference it, as described here, but this could become quite hectic with many "notepads" as ordering is important and I will have many rows associated with each of my primary objects.
You can make a client-side collection that you put the notes in. Then, call a method to make the changes once you want to save.
Here's how you make a client-side collection:
var notes = new Meteor.Collection(null)
I'm trying to use freebase to return a cities related country ISO code.
I have this MQL which works but it doesn't work on certain cities and there's probably a more straight forward way to do the same thing?
{
"id": "/en/amarillo",
"/location/location/containedby": [
"/location/country/iso3166_1_alpha2": null,
"type": "/location/country"
]
}
It doesn't work occasionally for smaller cities. Even better would be a way to use the Freebase suggest (which I use to gather the city) to return the ISO code in the same request?
jQuery ->
$("#city_name")
.suggest(type: "/location/citytown")
.bind "fb-select", (e, data) ->
$("#city_freebase_id").val data.id
That's basically how I'd do it, but, as you've discovered, the data isn't incredibly fully populated. One tweak that you could make to improve your odds of finding something would be to go up an additional level in case, for example, the city is contained by a state which is contained by a country. You're also missing a set of curly braces in your subquery which will probably cause your query to fail in the API (the query editor silently fixes up stuff like this).
A revised query that goes up an additional level and fixes the braces would look like this:
{
"id": "/en/avondale",
"/location/location/containedby": [{
"/location/country/iso3166_1_alpha2": null,
"type": "/location/country"
}],
"l2:/location/location/containedby": [{
"id":null,
"/location/location/containedby": [{
"/location/country/iso3166_1_alpha2": null,
"type": "/location/country"
}]
}]
}
The search API has an mql_output parameter that could be used to do what you want, but I'm not sure it's used by Freebase Suggest. It's not documented to be available. If it's not in the code either, it wouldn't be too hard to hack the widget to add this.
I'm trying to retrieve the full topic description/summary for some Freebase articles. I have been using the Freebase topic API, which returns this type of results: http://www.freebase.com/experimental/topic/standard?id=/en/jimi_hendrix
But I notice that the description is not complete and ends with "...". Is there a way to use some Freebase API to obtain the article's full description?
Does Freebase even store the complete description or does it just stores a portion of the description from Wikipedia?
Freebase just stores a portion of the Wikipedia description but there is usually more than what's given by the topic API.
To get the "full" text for a Wikipedia blurb associated with a Freebase topic you first need to query the Read API for a list of related articles like this:
{
"id": "/en/jimi_hendrix",
"/common/topic/article": [{}]
}
Try it in the Query Editor
Then choose one or more of the articles that it returns and feed its ID into the /trans/raw API like this:
http://api.freebase.com/api/trans/raw/m/043dz
You'll notice that the blurb of text that gets returned is a bit longer (1200 chars) and doesn't have the "..." but its still chopped off at the end.
When I display Freebase topic descriptions in a web page I have some code to clean it up before hand. I split it apart into paragraphs by looking for newlines and then if the last paragraph doesn't end with a period, exclamation mark or question mark I just throw away that paragraph. The way the Wikipedia blurbs are written, you usually only need the first paragraph anyways.
You can also fetch this directly from MQL with the "text" extension:
{
"id": "/en/jimi_hendrix",
"/common/topic/article": [{
"text": {
"maxlength": 16384,
"chars": null
}
}]
}
Note that you'll need to turn on MQL extensions for this to work - see here for an example of this in action.
Edit August 2012: while this works for the original freebase.com hosted APIs, the MQL extension functionality has been removed from the new googleapis.com hosted APIs, so this method shouldn't be relied on any more.
I want to write a query that gets back everything that is known about a topic (only needs to be one level deep.
When working in the Freebase MQL Editor they give the following example for "Everything we know about Jimi Hendrix":
{
"*" : null,
"name" : "Jimi Hendrix",
"type" : "/music/artist"
}
The problem is that the query is bound to a type "/music/artist" and is only getting back properties that relate to that type. If you change the query to use a different type you get an entirely different result set.
{
"*" : null,
"name" : "Jimi Hendrix",
"type" : "/people/person"
}
How can I write a query that really gets back everything that Freebase knows about Jimi Hendrix?
To do this you'll need a more advanced type of query that looks at the underlying links (/type/link) that make up the Freebase graph. Each link has a source, a target and a property assigned to it and they can be queried like this:
[
{
"master_property" : null,
"source" : {
"id" : "/en/jimi_hendrix"
},
"target" : null,
"target_value" : null,
"type" : "/type/link"
}
]
These are called the outgoing links and represent most of the values that you usually see in the Freebase UI but you can also swap the source and target to get a list of incoming links links this:
[
{
"master_property" : null,
"source" : null,
"target" : {
"id" : "/en/jimi_hendrix"
},
"type" : "/type/link"
}
]
These links include properties on other topics that refer to Jimi Hendrix as their value and these values are not all shown on the Freebase Jimi Hendrix page to keep the volume of information to a manageable level.
The Freebase Topic API might be what you're after:
http://www.freebase.com/experimental/topic/standard?id=/en/jimi_hendrix
The Topic API will grab all properties directly related to a topic in the graph. The API wraps a series of MQL queries to get all the data and outputs in JSON.
Google "Freebase Topic HTTP API" for further information.
After a while, we figured this is a typical use case, so we introduce a whole new API for doing this:
http://www.freebase.com/docs/topic_api
This will get you all the properties from the above queries, as well as mediators and other goodies.
Note that if you want all the properties from ALL the topics in Freebase, you should be using the data dumps and not the run-time query language (it will be many times faster).