[Developers] [Data-modeling] is everyone married to themselves?

[Nick Thompson]

mql doesn't support the sparql-like "__name" and "__where" clauses you 
describe, but it's a
very interesting idea for an extension.  it seems like it could be done 
as part of a client
library just as easily - the current service doesn't have any way of 
optimizing the date overlap
condition, so would end up as a post-query filter anyway.

automatically inferring the date overlap condition from examples seems 
very hard.  in this case,
divorced presidents are rare, and there really isn't enough information 
to decide that the date
overlap is what distinguishes jane wyman from other presidential 
spouses.  "all presidential
spouses except for jane wyman" is a more parsimonious explanation of 
"first lady" based
on the examples alone.

i would probably model"first lady" (or is "presidential consort" more 
interesting?) using an
explicit property rather than running timespan queries to get the list.
a checkable description of "first lady" in terms of overlapping 
timespans for marriages
and presidencies should be present somewhere too, but it seems easier to 
synchronize it
against the explicit "first lady" property off-line using a bot.  i'm 
really looking forward to
seeing reasoning bots that incorporate more complicated ontologies, but 
also cooperate
with human-asserted exceptions for all those ambiguous cases out there.

    nick

David Huynh wrote:
> I think such concepts should be modeled after the fact. That is, during 
> exploration, you should be able to formulate the query (through UI 
> interactions) to describe such a concept, but it is only after you have 
> used that ad hoc formulation and found it to be useful that you would 
> then give that concept a name so that it can be reused in the future by 
> you or someone else.
>
> So how would this query look like? My apologies for not being so 
> familiar with MQL, but let me give it a shot (I'm using ! to reverse the 
> properties):
>
> [ {
>     "id": null,
>     "type": "school",
>     "!studied_at": {
>         "spouse_of": {
>             "start": { "__name": "?start-of-marriage" },
>             "end": { "__name": "?end-of-marriage" },
>             "spouse": {
>                 "position": {
>                     "position": "/government/us_president",
>                     "start": { "__name": "?start-of-position" },
>                     "end": { "__name": "?end-of-position" }
>                 }
>             },
>             "__where":
>                 "overlap(date-range(?start-of-marriage, 
> ?end-of-marriage), date-range(?start-of-position, ?end-of-position))"
>         }
>     }
> } ]
>
> Something like that?
>
> The UI for this will be very interesting. One possible solution is to 
> support "post hoc elimination" of results. So, you start with 42 
> presidents and browse over the "spouse-of" relationship to get the 
> people whom you think are the first ladies. You end up with a lot more 
> than 42. This puzzles you, and then it dawns on you that some were not 
> married to the presidents while the presidents were in office. You then 
> need a means to quickly eliminate those from the result set. Maybe there 
> is a way for you to quickly compose a table of two columns, one showing 
> the durations of presidencies and one showing the durations of 
> marriages, with each row corresponding to a potential first lady. You 
> then click on a row of a false first lady (where the durations don't 
> overlap), and specify "remove this result and similar ones". The UI 
> confirms, "you mean remove those results where the durations don't overlap?"
>
> David
>
> Jason Douglas wrote:
>   
>> That makes me wonder if the real issue here is the need to model  
>> concepts like First Lady-hood explicitly rather than implicitly,  
>> then.  There might be just too much cultural fuzziness in the concept  
>> to be only expressed as a query.  What if someday someone occupies the  
>> "position" of First Lady who's a man... or isn't even legally married  
>> (gasp!).
>>
>> -jason
>>
>>
>> On Dec 17, 2007, at 9:07 PM, David Huynh wrote:
>>
>>   
>>     
>>> Good point, Jeff! I hadn't thought of that. Something that's  
>>> relatively
>>> simple to say in natural language is pretty hard to say in most if not
>>> all query languages, and hard to support in a query/browse UI.
>>>
>>> David
>>>
>>> Jeff Fry wrote:
>>>     
>>>       
>>>> As an aside, Jason mentioned wanting a query of schools that first
>>>> ladies attended, but what Jason and John have described (apart from  
>>>> the
>>>> problem of spousal symmetry) is a query of schools attended by people
>>>> who were married to US presidents. This is more inclusive than what
>>>> Jason described - it also gathers the educations of people who were
>>>> married to a president before or after their term in office. E.g.  
>>>> Ronald
>>>> Reagan was married to Jane Wyman from 1940-48, but Wyman was never a
>>>> first lady.
>>>>
>>>> This may well be an acceptable level of imprecision, but it's  
>>>> probably
>>>> worth noting.
>>>>
>>>> Cheers,
>>>> Jeff
>>>>
>>>> John Giannandrea wrote:
>>>>
>>>>       
>>>>         
>>>>> David Huynh wrote:
>>>>>
>>>>>
>>>>>         
>>>>>           
>>>>>> Might this be too limiting for building generic UIs for browsing
>>>>>> arbitrary social networks? Many social relationships are symmetric
>>>>>> (sibling, neighbor, friend, coworker, enemy, competitor, roommate,
>>>>>> officemate, wingman, companion, ...).
>>>>>>
>>>>>>
>>>>>>           
>>>>>>             
>>>>> I think some people would debate if all relationships are as  
>>>>> symmetric
>>>>> as they appear.
>>>>>
>>>>> But I agree that better support in MQL for eliminating self from  
>>>>> sub-
>>>>> clauses would be desirable.  Its on the list of things being
>>>>> considered for future versions.
>>>>>
>>>>> For now the workaround is to remove self from the result set.   
>>>>> This is
>>>>> what the freebase UI does.
>>>>>
>>>>> -jg
>>>>>           
>
> _______________________________________________
> Developers mailing list
> Developers at freebase.com
> http://lists.freebase.com/mailman/listinfo/developers
>