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

[David Huynh]

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