I feel what Marcel proposed is pretty cool, and does not need much
change before rolling out the first version, to start discovering what
needs to be improved based on real use.

Rogue apps are a concern with or without annotations. It's the same
problem as, say, spamming people with @mentions or #hashtags
excessively. Twitter is not pre-emptively policing this right now, I'm
sure they work on it behind the scenes, and it's fine.

For namespaces, one random thought is that you may want to consider
registering them, so that you know who has created a namespace, and
you could then validate them upon tweet posting, helping against
things like typos. I may still submit annotations in any namespace, as
long as _someone_ has registered the namespace. And they would be in a
browsable directory. Registration process could be similar to current
OAuth/@anywhere app registration, but independent of apps.

A lighter version of the above with all the benefits sans validation
is a free-for-all wiki where people just register their namespace on a
wikipage, and it helps people collaborate and discover what's going
on. Maybe Twitter wiki can have a section for that, or there will be
another semi-official one somewhere.


J


On Apr 16, 3:11 pm, Marcel Molina <mar...@twitter.com> wrote:
> We definitely want to have documents on dev.twitter.com with best practices
> and guildelines. That will be key. We're looking for everyone to help devise
> the rules of the road.
>
>
>
>
>
> On Fri, Apr 16, 2010 at 11:59 AM, gabriele renzi <rff....@gmail.com> wrote:
> > On Fri, Apr 16, 2010 at 8:51 PM, Marcel Molina <mar...@twitter.com> wrote:
> > > More namespace nesting would of course increase people's ability to
> > > taxonomize. It's a splippery slope though and we are trying to balance
> > > expressiveness with simplicity. Providing for arbitrarily nested
> > namespaces
> > > increases complexity considerably both from an implementation perspective
> > > and a comprehension perspective.
>
> > I am not in favour of arbitrarrily nested, quads are ok to express
> > almost anything useful apart from temporal logic :) (consider a
> > namespace app: subject-verb-object).
>
> > But I'm ok with you choice, just, as i said, can we at least put some
> > guidelines so we can avoid unintentional conflicts among implementors?
> > E.g. "if you want to store triples and avoid conflicts with other
> > applications use a namespace such as yourapp:subnamespace - key -
> > value"
>
> > --
> > Subscription settings:
> >http://groups.google.com/group/twitter-development-talk/subscribe?hl=en
>
> --
> Marcel Molina
> Twitter Platform Teamhttp://twitter.com/noradio

Reply via email to