[Developers] type checking?

[brendan neutra]

Better/easier cleanup seems like a win-win.

Prompting the user (or other obstacles in the UI pattern) involves trade-offs: 
if simultaneously linking and typing a target object (e.g. linking to Terry 
Gross *and* making her a radio host in one shot) is an action that improves the 
quality of the data the vast majority of the time, maybe it's best not to make 
the users go through an extra hoop with a confirmation prompt.  If it is an 
action that has the potential of degrading the quality of the data (which this 
action does, currently) and the cost of the degradation outweighs the benefits 
of the easy input, re-design.

This kind of tradeoff is likely to remain interesting, dare I say, forever (one 
can hope?). What I mean is, we will always have domains of knowledge that are 
new and incomplete. I suppose a good design can side-step what often appears as 
a dilemma. Just a thought, from a non-designer...

Brendan



Robert Cook wrote:
> This is my philosophy as well: Default to very open input in the  
> spirit of Wikipedia rather than that of a strict database.
> 
> Regarding the particular problem that was frustrating Arthur, I think  
> there might be a simple solution we could incorporate into the  
> Freebase application.  If a user removes a property value and he had  
> created that property himself and the referenced topic (the topic on  
> the other side of the link) was typed at the same time, then detype  
> that referenced topic.
> 
> This way the natural thing happens.  If you make a mistake, it's  
> cleaned up.
> 
> We probably need some similar logic for deleting CVTs, which often  
> leave behind cruft when they are deleted from one side.
> 
> R
> 
> On Dec 2, 2007, at 12:56 PM, John Giannandrea wrote:
> 
>> Arthur van Hoff wrote:
>>> Just for kicks I added the postal code 94025 as founder of the NPR
>>> radio
>>> station. I don't understand why a postal code is allowed to also be a
>>> company founder and a person. Maybe you need to explain more clearly
>>> why
>>> this is a good thing...
>> Ill let the client designers respond to the suggestions that its too
>> easy to type things from autocomplete.  Its certainly too hard to
>> clean up, I agree.  When you remove the type, the item no longer shows
>> up, but its still there in MQL.
>>
>> Im not claiming that its a 'good thing' that you made a postal code
>> into a radio station founder, just that loose typing is a prerequisite
>> for a system like this, where not everything is known up front.   For
>> example if you knew that 'Terry Gross' was a radio show host but we
>> only had her as a person, then adding her in to the right field would
>> co-type her and give her the correct reverse property.  Could there be
>> a confirmation step there, sure, but we dont want to not show you her
>> as an option if you typed in her name.
>>
>> We do have the beginnings of more structure in the type system,
>> enumerations and included types and one could imagine using these to
>> start to limit what gets done easily vs what requires confirmation.
>> So a radio host must already be a person might be a constraint we
>> could use in the UI.
>>
>> Ultimately we can imagine having even more metadata like type
>> exclusion information, that a zipcode is never a person.  But that
>> leads directly into the haunted wood called formal ontology.   If you
>> imagine a continuum between semi-structured user entered text
>> (wikipedia infoboxes say) and Cyc, I imagine that we will be most
>> successful if we end up somewhere in the middle.  So our type system
>> is *not* normative, and is loose specifically so we can capture
>> information that was unexpected and then, as a community, derive long-
>> lasting types from the data users created.
>>
>>> UI. This will break my application, which expects the property to  
>>> only
>>> refer to objects of the correct type.
>> MQL explicitly does not enforce strict typing.    If your application
>> has code that requires that its dealing with a radio station founder,
>> you should add that as a type constraint in the place you extract
>> those properties.  In theory we could add a stricter query mode to
>> MQL, but haven't yet.
>>
>> -jg
>>
>> _______________________________________________
>> 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