[Data-modeling] the commons / non distinction is a farce

[Iain Sproat]

>
> There's a new Freebase Suggest in the works which I hope will make it
> easier to distinguish between multiple types with the same name


+1, the number of times I've almost typed Politicians as Brazilian
Politicians<http://www.freebase.com/view/base/braziliangovt/politician/-/base/braziliangovt>
....

 The email notification system that just came
> live is a help as it allows us to contact schema admins more easily.


I've noticed emails making a big difference already.  good stuff!

Brainstorming, I've come up with the following ideas:

   1. A lot of types I create are just drafts.  I would rather create a
   draft type in the sandbox if it wasn't guaranteed that my hard work was
   scrubbed away each week.  Perhaps a way of flagging draft types in the
   sandbox so they are saved temporarily during scrubbing and get re-inserted.
    It would reduce one of the biggest hangups of sandbox use.  If the sandbox
   was used more, it would reduce the number of types in the production graph.
   2. Making it easier to clone types in the sandbox would help boost its
   popularity as the place to do schema drafts.  Once the draft is finished, a
   quick way of getting it from sandbox to a base in the production graph would
   help reduce friction.  One click would be great!
   3. A more drastic solution-> User properties.  Similar to having user
   types on topics, it might be possible to have user properties on types?
    Would definitely help with all the requests for reciprocation.  And if a
   user property proves useful, the type admin could click a button to bring it
   into the fold.
   4. And more complex; some Digg style voting on types and properties.
    Coupled with an algorithm which uses those votes and the number of links to
   types/properties could alter the UI visibility in the client, greying out
   unpopular and brightening up the popular.  Linking that to a leaderboard,
   rising and falling types/properties could be identified and would help to
   spot any candidates for commons promotion.

Acre code search is likely to be increasingly useful for seeing just how
> many people are using a certain schema in their apps

Ooh, is this available now?  This would be useful for discovering new apps
relevant to a domain.

Iain


On Mon, Jun 29, 2009 at 10:39 PM, Kirrily Robert <kirrily at metaweb.com>wrote:

> On Jun 29, 2009, at 11:20 AM, Stefano Mazzocchi wrote:
> >
> > Say it were and you were in charge of making it happen: how would
> > you do
> > it?
> >
> > I'm not defensive, I'm honestly curious.
>
>
> This was what I was going to ask too :)  We've talked about this a LOT
> internally and it's actually an extremely hard problem (or at least we
> find it to be so).  We would really welcome suggestions for the design
> of a more collaborative way of doing schema that doesn't break things
> for app developers.  Even just a workflow of "I'm a schema developer,
> here's what I would like to do, step by step" would help.
>
> Meanwhile, there are some things we can do to help with the main
> annoyances, I think.  The email notification system that just came
> live is a help as it allows us to contact schema admins more easily.
> There's a new Freebase Suggest in the works which I hope will make it
> easier to distinguish between multiple types with the same name.  Acre
> code search is likely to be increasingly useful for seeing just how
> many people are using a certain schema in their apps (it won't catch
> non-Acre apps, but as the number of apps grows, it will at least give
> us *some* idea.)
>
> K.
>
> --
> Kirrily Robert
> Freebase Community Director
> kirrily at metaweb.com
> http://freebase.com/
>
>
>
>
> _______________________________________________
> Data-modeling mailing list
> Data-modeling at freebase.com
> http://lists.freebase.com/mailman/listinfo/data-modeling
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freebase.com/pipermail/data-modeling/attachments/20090630/96422711/attachment.htm