[twitter-dev] Re: [twitter-api-announce] Early look at Annotations
* What is an annotation more exactly exactly? First off let's be clearer about what an annotation is. An annotation is a namespace, key, value triple. A tweet can have one or more annotations. Namespaces can have one or more key/value pairs. first, annotations are cool, thanks. But why triples instead of quads? Say, we'd like to store three groups of movie data . If I do movie: rating: 5 then we risk conflict with someone else using the same namespace in a different way, e.g. movie: rating: * . At the same time, if I use the namespace for my application to avoid conflicts, I have to encode two of the fields in one cascaad: movie_rating : or cascaad_movie : rating: Did you consider this and decided it's not worth making the effort for a fourth field, or just ignored the issue, or simply didn't think of it? If triples are staying, can we establish a _convention_ early on on how to best handle this? -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en
Re: [twitter-dev] Re: [twitter-api-announce] Early look at Annotations
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. On Fri, Apr 16, 2010 at 11:45 AM, gabriele renzi rff@gmail.com wrote: * What is an annotation more exactly exactly? First off let's be clearer about what an annotation is. An annotation is a namespace, key, value triple. A tweet can have one or more annotations. Namespaces can have one or more key/value pairs. first, annotations are cool, thanks. But why triples instead of quads? Say, we'd like to store three groups of movie data . If I do movie: rating: 5 then we risk conflict with someone else using the same namespace in a different way, e.g. movie: rating: * . At the same time, if I use the namespace for my application to avoid conflicts, I have to encode two of the fields in one cascaad: movie_rating : or cascaad_movie : rating: Did you consider this and decided it's not worth making the effort for a fourth field, or just ignored the issue, or simply didn't think of it? If triples are staying, can we establish a _convention_ early on on how to best handle this? -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
Re: [twitter-dev] Re: [twitter-api-announce] Early look at Annotations
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
Re: [twitter-dev] Re: [twitter-api-announce] Early look at Annotations
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 Team http://twitter.com/noradio
[twitter-dev] Re: [twitter-api-announce] Early look at Annotations
but this will create islands of information and information retrieval
based
on annotations will be difficult for other applications.
i.e. amazon.com:book-rating{isbn:34345434, rating: 5}
it should be easier for other applications to find information based
on
annotations.
On Apr 16, 11:59 pm, 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
[twitter-dev] Re: [twitter-api-announce] Early look at Annotations
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
Re: [twitter-dev] Re: [twitter-api-announce] Early look at Annotations
On Fri, Apr 16, 2010 at 9:21 PM, dhavaln dhaval.b.na...@gmail.com wrote:
but this will create islands of information and information retrieval
based
on annotations will be difficult for other applications.
i.e. amazon.com:book-rating{isbn:34345434, rating: 5}
it should be easier for other applications to find information based
on
annotations.
more on the lines of
a tweet:
amazon.com: book-isbn : 123
amazon.com: book-rating: 5
IMHO it's better than having
book: rating: 5
book: rating : *
book: rating: excellent
and having to disambiguate by heuristics
but as it goes: just my 2 cents of under namespaced currency ;)
--
Subscription settings:
http://groups.google.com/group/twitter-development-talk/subscribe?hl=en
[twitter-dev] Re: [twitter-api-announce] Early look at Annotations
Developers can use reverse-FQDNs (like Java's packages) for their namespaces, which prevents collisions without actually requiring nesting. -James A. Rosen On Apr 16, 2: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. On Fri, Apr 16, 2010 at 11:45 AM, gabriele renzi rff@gmail.com wrote: * What is an annotation more exactly exactly? First off let's be clearer about what an annotation is. An annotation is a namespace, key, value triple. A tweet can have one or more annotations. Namespaces can have one or more key/value pairs. first, annotations are cool, thanks. But why triples instead of quads? Say, we'd like to store three groups of movie data . If I do movie: rating: 5 then we risk conflict with someone else using the same namespace in a different way, e.g. movie: rating: * . At the same time, if I use the namespace for my application to avoid conflicts, I have to encode two of the fields in one cascaad: movie_rating : or cascaad_movie : rating: Did you consider this and decided it's not worth making the effort for a fourth field, or just ignored the issue, or simply didn't think of it? If triples are staying, can we establish a _convention_ early on on how to best handle this? -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio
[twitter-dev] Re: [twitter-api-announce] Early look at Annotations
I'd like to forward this to the Crisis Mapping / Disaster Response mailing lists I'm on. They're been very active with Twitter. Is that OK? On 04/16/2010 10:54 AM, Marcel Molina wrote: Hey everyone. One of the things we talked about at Chirp is the new Annotations feature we're working on. In short, it allows you to annotate a tweet with structured metadata. We're still working on Annotations, but I wanted to share with a wider audience beyond those I was able to talk to in person at Chirp about how we're thinking of doing Annotations. * What is an annotation more exactly exactly? First off let's be clearer about what an annotation is. An annotation is a namespace, key, value triple. A tweet can have one or more annotations. Namespaces can have one or more key/value pairs. * How do I specify what annotations a tweet should have? Annotations are specified for a tweet when the tweet is created. When submitting a POST to /statuses/update, you'll include an annotations parameter with your annotations. We're thinking we'll provide two mechanisms for specifying what a tweet's annotations are: 1. JSON 2. form encoded parameters * How big can an annotation be and how many annotations can I attach to a tweet? There is no limit on the size of any given namespace, key or value but the entire set of all annotations for a given tweet can not exceed some fixed byte size. That size isn't set in stone yet. We will be starting small (probably 512 bytes) and growing it gradually as we incrementally roll out the feature so we can gauge its scalability at various sizes. We'd like to (no promises) have it end up around 2K. How you use that 2K is up to you. You can attach one honking annotation, or a thousand+ tiny ones. You can attach one namespace with hundreds of key/value pairs, or hundreds of namespaces with just one key/value pair. We want to keep things as flexible and open ended as possible. * What kind of data can go into an annotation? We'd like to allow for any arbitrary data to be stored in an annotation. Arbitrary Unicode? Sure. MIDI? Go for it. Emoji? Yes please! There might be some tricky edge cases though. Skip the rest of this paragraph if you don't care about the details of edge cases... For one, since these annotations will be serialized to, among other formats, XML, and we'd like to keep the XML succinct, the namespace and key components of an annotation triple would likely be an XML tag with its value as, well, its value. If that's the case then the data of the key must be a valid XML tag. This greatly limits what it can contain (not even spaces for example). If allowing all three elements of the triple to contain any arbitrary data is more important than a succinct XML payload then we'll design a more verbose XML payload. Up to you all really. I've included examples of both options below. Make a case for another proposal if you have strong opinions. * What constitutes a valid annotation? Aside from the size and data type restrictions listed above, another requirement is that namespaces and keys be non-empty values. Values, on the other hand, may be empty. In this way the namespace/key pair can be treated like a flag of sorts. It should be noted: I'd encourage everyone to always think of a namespace as a namespace, to think of a key as a key and to think of a value as a value. Don't take the fact that a value can be empty to mean that you can skip out on the whole namespace think and morph the namespace into a key and the key into a value. While open endedness and flexibility is a quality of the Annotations feature that I'm most excited about for the developer community, this kind of approach seems prone to causing confusion by undermining namespaces. * What namespaces can I write to? What namespaces can I read from? Anyone can write to or read from any namespace. We aren't planning on enforcing any policy that restricts someone else from adding an annotation with your namespace or seeing annotations only if they are logged in with a certain account. In the absence of some really compelling reason to do that, we want to err on the side of making this feature as flexible and open ended as possible. Namespaces aren't intended as a way for people to claim their little slice of the tweet space. Rather they are intended to dramatically increase the possible significance of a given key/value pair. If you want a given key to mean one thing and someone else wants that same key to mean something else, and someone else still wants another meaning, consumers of your annotations are put in a tricky spot trying to figure out how to interpret a given annotation without the disambiguation of a namespace. * How do we consume annotations? For convenience, we plan on including annotations for a tweet directly embedded into that tweet's payload. The XML payload of a tweet I just inspected at random came out to about 2K
