[Developers] Can a link's opposite direction name be retrieved with less queries?

[Alec Flett]

To answer the question in the subject: absolutely - in one query actually.

First of all, you might be interested in the 'explore' view - its a 
debugging tool similar to what you've created here:

http://www.freebase.com/view/explore/topic/en/the_police

Look at the XmlHttpRequests that go by using Firebug - you'll learn 
quite a bit.

(And a caveat - the code and the user interface are crude and unusual 
because this is really just for debugging..)

On to the query:
This query has the right idea - the problem is that it is saying "Give 
me all topics that have at least one master link, one reverse link, AND 
one value link" - i.e. the topic has to have all three... so you're 
going to miss topics that have only one of these.

So for a given topic, you're going to need to put an "optional": true 
inside each of these /type/reflect/any_* clauses.
>
>    "/type/reflect/any_reverse":[{
>
>       "id":null,
>
>       "link":null,
>
>       "name":null,
>
>       "type":[]
>
>     }],
>
>     "/type/reflect/any_value":[{
>
>       "link":null,
>
>       "type":null,
>
>       "value":null
>
>     }],
>
>     "id":"/topic/en/the_police",
>
>     "name":null
>
>   }]
>
> }
>
>  
>
>  
>
...
>
> That works fine (e.g. "Musical Genres" in the screenshot), except when 
> the link is an "any_reverse".  In this case, the link (and the name 
> that comes back) is from the wrong perspective (like the "Recorded By" 
> name in the screenshot).  I know that I can do an additional query to 
> get the link from the opposite perspective:
>
You don't have to do an additional query but there is a bit of a trick 
here. Some properties that come back on any_reverse don't have a 
property name/id from the other direction (called a 'reciprocal 
property'). Depending on what you want your tool to do, you might only 
want the reverse values for properties that have a reverse back the 
other way. That's actually what the history view for a topic shows you.

Here's the query clause to show all reverse links:

  "/type/reflect/any_reverse":[{

      "id":null,

      "link": {"master_property": {
                 "id": null,

                 "name": null,
*                 "reverse_property": {"id": null,
                                      "name": null,
                                      "optional": true }},*

      "name":null,

      "type":[]

    }],


Note that inside the master_property, I'm asking for the reverse - so 
you're essentially asking "On this reverse property, whats the reverse 
of that, coming the other way?"

Notice that I added "optional" here - without optional, you'll only get 
values that have a reverse property coming in the other way. with 
optional, the "reverse_property" clause in the result may be null - in 
that case there isn't a property pointing back the other way.

Also note that I added "name" so I'd get the english name of the property.
>
>
> My question is, can the number of queries to accomplish these results 
> be reduced?  By the way, when a link name (e.g. "Musical Genres" is 
> returned, I'm caching that name so that I don't have to query for it 
> again.
>
>  
>
You can always expand these things even further and add things like 
expected_type, and/or by expanding the "type" field. The expected_type 
shows you the type that the property expects, while the 'type' clause 
actually asks for the list of types

  "/type/reflect/any_reverse":[{

      "id":null,

      "link": {"master_property": {
                 "id": null,

                 "name": null,

*                 "expected_type": {"id": null, "name": null},*
                 "reverse_property": {"id": null,
                                      "name": null,
                                      "optional": true }},

      "name":null,

*      "type":[{"id": null, "name": null]*

    }],


Hope that helps.

Alec
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freebase.com/pipermail/developers/attachments/20070921/c3fc31f4/attachment-0001.htm