How about (if possible) making it blatantly obvious that the Topic being selected has already been typed the appropriate type and de-emphasizing the other Topics that match the search, but have not yet been given the expected type. Even just moving that type to the beginning of the list of types and bolding it would help.
<br><br>I like the fact that Freebase will automatically add the type for me if I make a relationship. If I had to leave the page I am editing, search for another page, add the "TV Actor" type then go back and add that actor, I don't think I would ever use Freebase. (That's not really a good example since most of the properties that expect a 'TV Actor' have reciprocal properties, but there are still some properties where the link is only one way at the moment where this example still stands)
<br><br><div><span class="gmail_quote">On 12/3/07, <b class="gmail_sendername">brendan neutra</b> <<a href="mailto:brendan@metaweb.com">brendan@metaweb.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>Better/easier cleanup seems like a win-win.<br><br>Prompting the user (or other obstacles in the UI pattern) involves trade-offs:<br>if simultaneously linking and typing a target object (e.g. linking to Terry<br>Gross *and* making her a radio host in one shot) is an action that improves the
<br>quality of the data the vast majority of the time, maybe it's best not to make<br>the users go through an extra hoop with a confirmation prompt. If it is an<br>action that has the potential of degrading the quality of the data (which this
<br>action does, currently) and the cost of the degradation outweighs the benefits<br>of the easy input, re-design.<br><br>This kind of tradeoff is likely to remain interesting, dare I say, forever (one<br>can hope?). What I mean is, we will always have domains of knowledge that are
<br>new and incomplete. I suppose a good design can side-step what often appears as<br>a dilemma. Just a thought, from a non-designer...<br><br>Brendan<br><br><br><br>Robert Cook wrote:<br>> This is my philosophy as well: Default to very open input in the
<br>> spirit of Wikipedia rather than that of a strict database.<br>><br>> Regarding the particular problem that was frustrating Arthur, I think<br>> there might be a simple solution we could incorporate into the
<br>> Freebase application. If a user removes a property value and he had<br>> created that property himself and the referenced topic (the topic on<br>> the other side of the link) was typed at the same time, then detype
<br>> that referenced topic.<br>><br>> This way the natural thing happens. If you make a mistake, it's<br>> cleaned up.<br>><br>> We probably need some similar logic for deleting CVTs, which often<br>
> leave behind cruft when they are deleted from one side.<br>><br>> R<br>><br>> On Dec 2, 2007, at 12:56 PM, John Giannandrea wrote:<br>><br>>> Arthur van Hoff wrote:<br>>>> Just for kicks I added the postal code 94025 as founder of the NPR
<br>>>> radio<br>>>> station. I don't understand why a postal code is allowed to also be a<br>>>> company founder and a person. Maybe you need to explain more clearly<br>>>> why<br>
>>> this is a good thing...<br>>> Ill let the client designers respond to the suggestions that its too<br>>> easy to type things from autocomplete. Its certainly too hard to<br>>> clean up, I agree. When you remove the type, the item no longer shows
<br>>> up, but its still there in MQL.<br>>><br>>> Im not claiming that its a 'good thing' that you made a postal code<br>>> into a radio station founder, just that loose typing is a prerequisite
<br>>> for a system like this, where not everything is known up front. For<br>>> example if you knew that 'Terry Gross' was a radio show host but we<br>>> only had her as a person, then adding her in to the right field would
<br>>> co-type her and give her the correct reverse property. Could there be<br>>> a confirmation step there, sure, but we dont want to not show you her<br>>> as an option if you typed in her name.<br>>>
<br>>> We do have the beginnings of more structure in the type system,<br>>> enumerations and included types and one could imagine using these to<br>>> start to limit what gets done easily vs what requires confirmation.
<br>>> So a radio host must already be a person might be a constraint we<br>>> could use in the UI.<br>>><br>>> Ultimately we can imagine having even more metadata like type<br>>> exclusion information, that a zipcode is never a person. But that
<br>>> leads directly into the haunted wood called formal ontology. If you<br>>> imagine a continuum between semi-structured user entered text<br>>> (wikipedia infoboxes say) and Cyc, I imagine that we will be most
<br>>> successful if we end up somewhere in the middle. So our type system<br>>> is *not* normative, and is loose specifically so we can capture<br>>> information that was unexpected and then, as a community, derive long-
<br>>> lasting types from the data users created.<br>>><br>>>> UI. This will break my application, which expects the property to<br>>>> only<br>>>> refer to objects of the correct type.
<br>>> MQL explicitly does not enforce strict typing. If your application<br>>> has code that requires that its dealing with a radio station founder,<br>>> you should add that as a type constraint in the place you extract
<br>>> those properties. In theory we could add a stricter query mode to<br>>> MQL, but haven't yet.<br>>><br>>> -jg<br>>><br>>> _______________________________________________<br>
>> Developers mailing list<br>>> <a href="mailto:Developers@freebase.com">Developers@freebase.com</a><br>>> <a href="http://lists.freebase.com/mailman/listinfo/developers">http://lists.freebase.com/mailman/listinfo/developers
</a><br>><br>> _______________________________________________<br>> Developers mailing list<br>> <a href="mailto:Developers@freebase.com">Developers@freebase.com</a><br>> <a href="http://lists.freebase.com/mailman/listinfo/developers">
http://lists.freebase.com/mailman/listinfo/developers</a><br>_______________________________________________<br>Developers mailing list<br><a href="mailto:Developers@freebase.com">Developers@freebase.com</a><br><a href="http://lists.freebase.com/mailman/listinfo/developers">
http://lists.freebase.com/mailman/listinfo/developers</a><br></blockquote></div><br>