[Developers] Changing "/topic/en" to "/en".. maybe

[Arthur van Hoff]

Hi Alec,

When you update a text property you need to specify "lang":"/lang/en".
Is that going to change to "lang":"/en"?

If so, we'll have to update some of our code.

> -----Original Message-----
> From: developers-bounces at freebase.com [mailto:developers-
> bounces at freebase.com] On Behalf Of Alec Flett
> Sent: Wednesday, March 26, 2008 5:27 PM
> To: For discussions about MQL,Freebase API and apps built on Freebase
> Subject: Re: [Developers] Changing "/topic/en" to "/en".. maybe
> 
> As there has been no objection to this, I'd like to go forward. The
> schedule will look like this:
> 
> 3/27 (thursday) - In sandbox, I'll add the /en namespace to point to
> stuff in /topic/en.
> 3/31 (monday) - I'll make the same change in production
> Some (to be announced) date around 4/7: we'll update the code to
> always return /en/topic_name
>   4/30, we'll remove the /topic/en namespace from the graph.
> 
> This means you'll be able to start using /en/<topic_name> starting
> 3/27 on sandbox, and 3/31 on OTG.
> 
> Alec
> 
> On Mar 19, 2008, at 1:37 PM, Alec Flett wrote:
> 
> > Hey everyone -
> > So there has been some discussion internally about shortening the
> "/
> > topic/en" namespace down to just "/en". This is something that is
> > being tossed around inside metaweb and I wanted to open up the
> > discussion to the larger community to check the feasibility of
> this.
> > To be clear, this is a one-time change while we're still in alpha.
> We
> > really, really don't expect to do another system-wide change like
> > this, especially once we're out of alpha.
> >
> > The primary motivations are:
> > 1) /topic seems superfluous, and in general adds heirarchy where
> there
> > doesn't need to be.. it makes english names appear sooner in the
> id,
> > which is nice for readability. We don't think there will ever be an
> > actually domain "/en", "/fr" or whatever.
> >
> > 2) shortening urls - both at freebase and on anyone else using
> topic
> > names in their URLs.  In particular, it makes anyone who inserts
> ids
> > into their urls have a more readable url.
> >
> > If we decide to do this, here is what would probably happen -
> feedback
> > is encouraged!
> > 1) MQL would start returning "/en/topic_name" instead of
> "/topic/en/
> > topic_name" in queries where you say "id": null, such as:
> > {"name": "Bob Dylan",
> >  "type": "/music/artist",
> >  "id": null}
> >
> > (this would return "/en/bob_dylan")
> >
> > 2) MQL would continue to accept "/topic/en/bob_dylan" as a valid id
> > for some period of time (a week? a month? 3 months? that's
> something
> > we all need to decide)
> >
> > 3) During the time that the /topic/en compatibility exists, MQL
> would
> > also return "/topic/en/topic_name" when the /topic id is explicitly
> > specified in the query:
> >
> > {"id": "/topic/en/bob_dylan", "name": null}
> >
> > would return
> > {"id": "/topic/en/bob_dylan", "name": "Bob Dylan"}
> >
> > 4) Anyone can continue to link to http://www.freebase.com/view<id>
> > using either /topic/en/topic_name or /en/topic_name, but freebase
> > would do a HTTP 301 redirect to
> http://www.freebase.com/view/en/topic_name
> > . We'll probably support the /view/topic URL mapping forever.
> >
> > But of course the issue is: what will break? The big issue is
> > obviously if people are storing freebase keys in their databases,
> and
> > migration during a compatibility period is impossible.
> >
> > Please reply on this thread with your concerns/issues or even if
> you
> > just think this is an awesome idea :)
> >
> > Alec
> >
> >
> >
> > _______________________________________________
> > 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