[Developers] mediated properties
Alec Flett
alecf at metaweb.com
Thu Jul 19 22:18:10 UTC 2007
It's probably useful to describe the two use cases behind compound value
types, because that's not always obvious, and the two cases aren't
technically modeled any different from each other right now.
*Use case 1: two-valued CVT*
This case is generally when there is a relationship between two
topics, but there is metadata to be associated with the relationship
itself. A good example of this is "film performance" - really this is a
relationship between an Actor, and a Film, and the "role" is really just
extra metadata. What you'd really want in MQL is to be able to do
something like:
{"name": "The Departed",
"type": "/film/film",
"starring": [] }
and get this result:
{"name": "The Departed",
"type": "/film/film/",
"starring": ["Martin Sheen", "Leonardo DiCaprio", ...]}
And if you expanded this out further, you might learn more:
{"name": "The Departed",
"type": "/film/film",
"starring": [{"*": null}] }
would give you:
{"name": "The Departed",
"type": "/film/film/",
"starring": [
{"actor": "Martin Sheen", "role": "Captain Queenan"},
{"actor": "Leonardo DiCaprio", "role": "Billy Costigan"},...]}
The key here is that there are two obvious endpoints in the simpler
query. When visiting the mediator object and "coming in from the film"
you want the actor, and when you're "coming in from the actor" you want
the film.
*Use case 2: Multi-valued CVT*
A good example of this is education - a compound value which might
connect a person to a school and a degree.
{"name": "Alec Flett"
"type": "/people/person",
"education": []}
{"name": "Alec Flett"
"type": "/people/person",
"education": [null, null, ...]}
Because in this case it isn't really obvious what you meant - did you
want the school or the degree? Would you expect ["Carnegie Mellon
University", ...] or ["Bachelor of Science", ...] ?
If I expand it out, you still get the right info
{"name": "Alec Flett"
"type": "/people/person",
"education": [{"*": null}]}
This is kinda what we'd want:
{"name": "Alec Flett"
"type": "/people/person",
"education": [{"school": "Carnegie Mellon University", "degree":
"Bachelors of Science", "}]}
At the moment the freebase.com user interface looks at all the
properties which are "disambiguating" and uses them. Here are the
disambiguating properties of /education/education:
{
"id":"/education/education",
"properties":[{
"/freebase/property_hints/disambiguator":true,
"key":"degree"
},{
"/freebase/property_hints/disambiguator":true,
"key":"institution"
},{
"/freebase/property_hints/disambiguator":true,
"key":"start_date"
},{
"/freebase/property_hints/disambiguator":true,
"key":"end_date"
},{
"/freebase/property_hints/disambiguator":true,
"key":"student"
},{
"/freebase/property_hints/disambiguator":true,
"key":"major_field_of_study"
},{
"/freebase/property_hints/disambiguator":true,
"key":"dissertation_title"
}]
}
So at the moment what you've pointed out is that we currently model ALL
compound values as "case 2" - there's no obvious left or right.
Ultimately what we'd like is for MQL to understand case 1, and that
would make compound values much easier to use.
Alec
Augusto Callejas wrote:
> hi-
>
> i ran that query but all properties have value "true"
> for the "disambiguator" property hint.
>
> from the type documentation:
>
> Musical Group Membership is a compound value type which defines the
> relationship between a Musical Artist (a band or collaboration) and its
> Musical Group Members (musicians).
>
> is there a difference when you say it mediates for all of the properties
> versus when the documentation says it defines relationships between
> musical artist and group member? i'm looking for how that relationship
> is captured in the type information. since the disambigurator property
> hint is the same for all properties, it doesn't define the relationship
> i'm looking for.
>
> thanks,
> augusto.
>
>
> On 7/19/07 10:52 AM, "Darin Wilson" <darin at metaweb.com> wrote:
>
>
>> 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
>>>
>> _______________________________________________
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freebase.com/pipermail/developers/attachments/20070719/fec23c26/attachment-0001.htm
More information about the Developers
mailing list