[Developers] type checking?

[Daniel Renfer]

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.

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)

On 12/3/07, brendan neutra <brendan at metaweb.com> wrote:
>
>
> 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
> _______________________________________________
> 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/20071203/ccdb6661/attachment.htm