[Developers] mediated properties

[Dae Park]

We perform a "schema query" for each type a topic is an instance  
which includes a query for each property and their expected_type. If  
the expected_type is marked as a mediator then we go another ply out  
and ask for the property's expected_type's disambiguating properties.

{
   id: #topic_id
   type: [{
     id: null,
     properties: [{
       id: null,
       master_property: null,
       reverse_property: null,
       unique: null,
       expected_type: {
         id: null,
         "/freebase/type_hints/mediator": null,
         properties: [{
           master_property: null,
           reverse_property: null,
           id: null,
           unique: null,
           "/freebase/type_hints/disambiguator": true
         }}
       }
     }]
   }]
}

When displaying these mediator properties (sub_properties) from a  
topic's property:

if the topic_property and sub_property are reciprocal of one another:
	if sub_property is unique:
		skip
	else:
		foreach value in sub-property:
			if value == topic we're viewing:
				continue:
			display value


Two properties (prop1, prop2) are reciprocal's of one another if:

prop1.reverse_property == prop2
or
prop2.master_property == prop1



			


On Jun 28, 2007, at 1:15 PM, Steve Sak wrote:

>
> How does the freebase.com "person" web pages "know" to display the  
> name
> of the spouse/sibling or the name of the organization a person worked
> for under "employment history"? Hard-coded?
>
> Nick Thompson wrote:
>> in general, i don't think your question has a well-defined answer -
>> there's no reason for the system to believe that
>> /business/employment_tenure/company is more relevant than
>> /business/employment_tenure/title, for example.  you could be looking
>> for a list of people at a particular company, in which case the job
>> title would more interesting.
>>
>> so, you might rule out /business/employment_tenure/person from  
>> context
>> as chris described, but that doesn't determine a unique "other side".
>> that's the nature of compound value types - if a relationship only
>> had two sides, it would probably be modeled as a single link instead
>> of being mediated by a compound value object.
>>
>>     nick
>>
>> Steve Sak wrote:
>>> So, if I'm looking at /people/person/employment_history how would I
>>> determine that the relevant property is
>>> /business/employment_tenure/company?
>>>
>>>
>>> Alec Flett wrote:
>>>> I want to add that checking by is only valid if you know you're  
>>>> coming
>>>> in and out on the same property (as is the case with marriage) - if
>>>> the properties are different, you need to look at master/reverse
>>>> properties because you can imagine a director who also produced a
>>>> movie - if you were just going by ids, looking at the  
>>>> relationship of
>>>>
>>>> "Who is the /director/ of this movie /produced by/ Martin  
>>>> Scorsese?" -
>>>> you might get Martin Scorsese back, but that doesn't mean that
>>>> "director" is the reverse of "produced by".
>>>>
>>>> Alec
>>>>
>>>> Christopher R. Maden wrote:
>>>>> Steve Sak wrote:
>>>>>
>>>>>> To restate the question: given a mediator object how do I  
>>>>>> determine
>>>>>> which property is the one it's mediating?  For example, type A  
>>>>>> has a
>>>>>> mediator M that has a bunch of properties mediates between A and
>>>>>> another
>>>>>> object.  How do I determine which property of M is the one that
>>>>>> points
>>>>>> to the other object being mediated?
>>>>>>
>>>>> Mediators, or compound value types, are not especially different
>>>>> from any other type; the UI treats them a little differently, but
>>>>> that’s it.
>>>>>
>>>>> But I think you are asking about instances rather than types,
>>>>> correct? In other words, Arnold Schwarzenegger connects to a
>>>>> marriage, and that marriage connects to two people, both Arnold
>>>>> Schwarzenegger and Maria Shriver.  How can you tell which of the
>>>>> spouses is the one you started from?
>>>>>
>>>>> The only way to do that, really, is by looking at the IDs.
>>>>>
>>>>> {
>>>>>    "query": {
>>>>>      "id": null,
>>>>>      "name": "Arnold Schwarzenegger",
>>>>>      "spouse_s": [
>>>>>        {
>>>>>          "spouse": [
>>>>>            {
>>>>>              "id":null,
>>>>>              "name":null
>>>>>            }
>>>>>          ],
>>>>>          "type":"/people/marriage"
>>>>>        }
>>>>>      ],
>>>>>      "type":"/people/person"
>>>>>    }
>>>>> }
>>>>>
>>>>> {
>>>>>    "result": {
>>>>>      "spouse_s": [
>>>>>        {
>>>>>          "spouse": [
>>>>>            {
>>>>>              "id": "#9202a8c04000641f80000000001da07e",
>>>>>              "name": "Maria Shriver"
>>>>>            },
>>>>>            {
>>>>>              "id": "#9202a8c04000641f8000000000006567",
>>>>>              "name": "Arnold Schwarzenegger"
>>>>>            }
>>>>>          ],
>>>>>          "type": "/people/marriage"
>>>>>        }
>>>>>      ],
>>>>>      "type": "/people/person",
>>>>>      "id": "#9202a8c04000641f8000000000006567",
>>>>>      "name": "Arnold Schwarzenegger"
>>>>>    }
>>>>> }
>>>>>
>>>>> You can see that one of the spouses in the marriage has the  
>>>>> same ID
>>>>> as the person with whom you started, and that the other is  
>>>>> different.
>>>>>
>>>>> Unfortunately, there’s not really an automatic way to say “get all
>>>>> of the values of these properties except the ones that point back
>>>>> to the parent within the scope of this query.”
>>>>>
>>>>> HTH,
>>>>> Chris
>>>>>
>>>
>
> -- 
> Steven G Sak
> Applied Minds, Inc.
> 11718 Bowman Green Drive
> Reston, Virginia 20190
> o: (703) 483-2207
> c: (703) 626-2557
>
> _______________________________________________
> Developers mailing list
> Developers at freebase.com
> http://lists.freebase.com/mailman/listinfo/developers