[Developers] mediated properties

Darin Wilson darin at metaweb.com
Thu Jul 19 17:52:22 UTC 2007 

Hi Augusto-

A mediating type, or complex value type (CVT), actually mediates for  
all of the properties that the type contains; however, the type  
designer can choose which of those properties should be displayed  
when an instance of the type linked from another topic. If you look  
at the type definition of /music/group_membership, you'll see that  
each of the properties has the "Display as disambiguator" box  
checked. This means that the property will be displayed, if the data  
is available.

If you look at the instance list for /music/group_membership, you'll  
see that some of the instances have years and other don't. That's  
because the "Period (start)" and/or "Period (end)" properties haven't  
been filled out yet. If the data were available, it would be displayed.

http://www.freebase.com/view/filter?id=%2Fmusic%2Fgroup_membership

To see this programmatically, you can use the following query. The / 
freebase/type_hints/mediator property on the type will tell you if  
it's a CVT or not. The /freebase/property_hints/disambiguator on the  
properties will tell you if the value of the property should be  
displayed.

{
   "query":[{
     "id":"/music/group_membership",
     "type":"/type/type",
     "/freebase/type_hints/mediator":null,
     "properties":[{
       "id":null,
       "/freebase/property_hints/disambiguator":null
     }]
   }]
}

HTH,
Darin


On Jul 19, 2007, at 10:05 AM, Augusto Callejas wrote:

> hi-
>
> regarding mediating types, how do i determine what two other types
> it is mediating for?  for instance, there is the complex type:
>
>   http://freebase.com/view/filter?id=/music/group_membership
>
> reading the type description reveals that it relates these two types:
>
>   /music/group_member (via property /music/group_membership/member)
>   /music/musical_group (via property /music/group_membership/group)
>
> how do i determine this programmatically?  at first, i was going to
> use that fact that these two properties have "unique":true, but
> so is the case for two other properties:
>
>   /music/group_membership/start
>   /music/group_membership/end
>
> how can i make the distinction?
>
> thanks,
> augusto.
>
>
> On 6/28/07 3:46 PM, "Dae Park" <daepark at metaweb.com> wrote:
>
>> 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
>>
>> _______________________________________________
>> Developers mailing list
>> Developers at freebase.com
>> http://lists.freebase.com/mailman/listinfo/developers
>
>
> _______________________________________________
> Developers mailing list
> Developers at freebase.com
> http://lists.freebase.com/mailman/listinfo/developers

More information about the Developers mailing list