[twitter-dev] Early look at Annotations

[Marcel Molina]

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 in size. The "worst case" annotation would a little more than double that payload to probably about 5k. We're erring on the side of thinking that the moderate increase in payload size for tweets with annotations, even on slow connections, is both more convenient and faster than the latency and inconvenience incurred by adding another HTTP round trip. Though we'd like to provide an embedded and non embedded option, the maintenance cost and fragment cache space increase makes supporting both likely unrealistic so we're going with what we think satisfies the 80% case. Push back as appropriate.

* What will the payloads look like?

This isn't final. The payloads could end up wildly different after we noodle around in things like RDF and the semantic web's literature and all that kind of stuff. You can't see me but my hands are waving vigorously.

Given a hypothetical tweet, "Just got 'Although Of Course You End Up Becoming Yourself' in the mail. Hopeful. Heart broken."

  JSON

'annotations':

{

  'iso':

  {

    'isbn': '030759243X'

  },

  'amazon':

  {

    'url': 'http://www.amazon.com/Although-Course-You-Becoming-Yourself/dp/030759243X'

  }

}

  XML option #1 which is succinct but restricts the possible values of namespaces and keys

  <annotations>

    <iso>

      <isbn>030759243X</isbn>

    </iso>

    <amazon>

      <url>http://www.amazon.com/Although-Course-You-Becoming-Yourself/dp/030759243X</url>

    </amazon>

  </annotations>

  XML option #2 which is more verbose but allows for namespaces and keys to contain arbitrary data

  <annotations>

    <annotation>

      <namespace>iso</namespace>

      <key>isbn</key>

      <value>030759243X</value>

    </annotation>

    <annotation>

      <namespace>amazon</namespace>

      <key>url</key>

      <value>http://www.amazon.com/Although-Course-You-Becoming-Yourself/dp/030759243X</value>

    </annotation>

  </annotations>

If we went with XML option #2 it may or may not be a problem that it isn't "symmetrical" with the JSON representation. On the other hand, JSON and XML tend to be culturally at opposite sides of the Pithiness Spectrum.

* Can I add annotations to a tweet after the tweet has been created?

No. Like the text of a tweet, its annotations are also immutable. They can only be specified when the tweet they are being attached to is created. For talking purposes, though, if you want to add annotations to a tweet after the fact, you could retweet the original tweet and attach annotations to the retweet.

* Ok, great. What should I use annotations for though?

We don't know! That's the cool thing. Annotations are a blank slate that lend themselves to myriad divergent use cases. We want to provide open-ended utility for all the developers to innovate on top of. Some of us have  initial ideas of cool potential uses cases that I'm sure we'll start to share just to seed the conversation as we get closer to launch. Developers will experiment with annotations. Certain ideas and approaches will catch on. Certain annotations will become standards democratically because everyone agrees. Some might have diverging opinions. It's something that we hope will grow organically and be driven by sociological and cultural forces.

* Ok, great. How are we going to figure out what Joe Random's annotations actually mean?

That's something we need to figure out as a community. But here is an early idea: People could add some agreed upon "meta-annotation" that points to something which *describes* the annotation or annotations that person is using. Think something sort of like XML DTD, though not necessarily machine readable. This meta annotation could point to a URL that simply has an HTML document that gives a description with some examples of the various annotations you're experimenting with or standardizing on.

* Will it be in search? Streaming? Mobile? My toaster?

We hope so! When we launch you will at minimum be able to attach annotations to a tweet and consume annotations from a tweet's payload via the REST API. Of course it would be awesome to be able to say to search or the streaming API, "give me all tweets with this namespace", or "give me all tweets with this namespace and key", or etc. We're working with the Search, Streaming and other teams to make all this happen. We can't promise it'll be ready by launch but we know it's killer and a must have and are trying to get it ready soon.

* When is it going to launch?

This is, pretty much, the only thing a couple of us are going to be working on until it's launched. We really can't wait to get it in your hands to see all the cool things you'll do with it, so we're cranking to get it out as soon as possible. If I had to provide a guestimate, I'd wave my hands in the direction of 2 months for a early, incremental roll out. We not only need to implement all the functionality, but we also need to productionize it in a measured and responsible way to ensure its quality of service is high.

In closing:

We're really excited about Annotations. Annotations mark one of our first of many departures from keeping in lock step with features on the web site. To truly be a platform, we want to expose high-leverage general purpose utility for the developer community to innovate on top of. Annotations is just the first of several high-leverage-general-purpose-utlity features we're hoping to get to after Annotations.

Think big. Blow our minds.

--
Marcel Molina
Twitter Platform Team
http://twitter.com/noradio

[Joseph Cheek]

awesome idea! I know I can find a use for it. Some concerns, however,
below...

Joseph Cheek

Marcel Molina wrote:

the sentence

> Namespaces aren't intended as a way for people to claim their little
> slice of the tweet space.

and the sentence

> 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.

seem to be at odds with each other. If you don't provide a way for us
devs to claim a particular namespace, you force each of us to figure out
what a dev meant with namespace xyz, which is what you way you want to
avoid. Perhaps namespaces can be prefixed with com.cheek.twitter or
somesuch à la Java. Just a thought.

> We're erring on the side of thinking that the moderate increase in
> payload size for tweets with annotations, even on slow connections, is
> both more convenient and faster than the latency and inconvenience
> incurred by adding another HTTP round trip.

agreed, especially with rate limiting in place.

> * Ok, great. How are we going to figure out what Joe Random's
> annotations actually mean?
>
> That's something we need to figure out as a community. But here is an
> early idea: People could add some agreed upon "meta-annotation" that
> points to something which *describes* the annotation or annotations
> that person is using. Think something sort of like XML DTD, though not
> necessarily machine readable. This meta annotation could point to a
> URL that simply has an HTML document that gives a description with
> some examples of the various annotations you're experimenting with or
> standardizing on.

Interesting. So I could add metadata to the tweet so that my foo
namespace isn't interpreted the same as other's foo namespaces? If so,
then I would want the ability to select this metadata in a search - if I
have to manually code something to recognize namespace foo for metadata
http://www.cheek.com/my_twitter_rules_are_here.html then I don't want
results for everyone else's namespace foo that my app won't recognize.
Make sense?

so then namespace com.cheek.foo becomes namespace foo with metadata
cheek.com/blahblah. ok, i can do that.




--
Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en

[Dewald Pretorius]

Marcel,

I'd strongly urge you to consider a more structured and controlled
environment for annotations.

Ideally, I think an OAuth app must register a namespace, or subscribe
to an existing namespace of another app, before it can create
annotations in that namespace. And these registrations and
subscriptions must be reviewed and approved before an app can actually
contribute to a namespace.

Being as open and free as you currently have it, it's fertile soil for
the poisoning of any namespace by any rogue or not-so-nice app.

It's better to plan and create the controls ahead of time. You're
going to save everyone, including yourselves, a lot of effort and
time.

>     'url': 'http://www.amazon.com/Although-Course-You-Becoming-Yourself/dp/030759...

>   }
>
> }
>
>   XML option #1 which is succinct but restricts the possible values of
> namespaces and keys
>
>   <annotations>
>     <iso>
>       <isbn>030759243X</isbn>
>     </iso>
>     <amazon>

>       <url>http://www.amazon.com/Although-Course-You-Becoming-Yourself/dp/030759...

> </url>
>     </amazon>
>   </annotations>
>
>   XML option #2 which is more verbose but allows for namespaces and keys to
> contain arbitrary data
>
>   <annotations>
>     <annotation>
>       <namespace>iso</namespace>
>       <key>isbn</key>
>       <value>030759243X</value>
>     </annotation>
>     <annotation>
>       <namespace>amazon</namespace>
>       <key>url</key>

>       <value>http://www.amazon.com/Although-Course-You-Becoming-Yourself/dp/030759...

[Joseph Cheek]

comments inline...

Dewald Pretorius wrote:
> Marcel,
>
> I'd strongly urge you to consider a more structured and controlled
> environment for annotations.
>

agreed, but...

> Ideally, I think an OAuth app must register a namespace, or subscribe
> to an existing namespace of another app, before it can create
> annotations in that namespace. And these registrations and
> subscriptions must be reviewed and approved before an app can actually
> contribute to a namespace.
>

... not to this extent. twitter becomes app and content police? I vote
no. I don't even think they have the manpower to review and approve
each app. And I sure don't want that job.

[Raffi Krikorian]

I'd strongly urge you to consider a more structured and controlled
environment for annotations.

Ideally, I think an OAuth app must register a namespace, or subscribe
to an existing namespace of another app, before it can create
annotations in that namespace. And these registrations and
subscriptions must be reviewed and approved before an app can actually
contribute to a namespace.

Being as open and free as you currently have it, it's fertile soil for
the poisoning of any namespace by any rogue or not-so-nice app.

It's better to plan and create the controls ahead of time. You're
going to save everyone, including yourselves, a lot of effort and
time.

the same could happen right now - if somebody puts a $ before something, stock twits may try to parse that as a stock market commodity.  i don't see us (for some) enforcing anything on the namespaces, and will let the community try to work it out.

if there happens to be a rogue app, then users will stop using it.

 

--
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi

[Joseph Cheek]

not necessarily - twitterbots are easy to build. you can't rely on lack
of usage by humans to kill a twitter app.

Raffi Krikorian wrote:
> if there happens to be a rogue app, then users will stop using it.
>
> --
> Raffi Krikorian
> Twitter Platform Team
> http://twitter.com/raffi

[gabriele renzi]

> * 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 : XXXX
or
cascaad_movie : rating: XXXX

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?

[Dewald Pretorius]

Raffi,

It's not about people using or not using rogue apps. It's about rogue
apps poisoning the annotation data and ruining it for everybody.

Rogue apps can continue to refresh their consumer keys with new
accounts and OAuth app registrations, as soon as the one currently in
use is suspended.

Meaning, a new class of rogue app will emerge. Ones with the express
purpose of getting their data into the namespaces.

To name one example (with reference to Marcel's examples):

- A rogue app that creates tweets with an affiliate link in the
<amazon> namespace.

> Twitter Platform Teamhttp://twitter.com/raffi
>
> --
> Subscription settings:http://groups.google.com/group/twitter-development-talk/subscribe?hl=en- Hide quoted text -
>
> - Show quoted text -

[Marcel Molina]

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.

[Raffi Krikorian]

right now, i could send out a whole bunch of tweets with crappy yfrog URLs (that all return 404s).  to end users, again, it seems like yfrog is a bad service.

i mean, you have good points - and i hear all of them - its not something we are going to with for now, but i totally understand everything you're saying.

[gabriele renzi]

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"

[Marcel Molina]

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.

[dhavaln]

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.

[Jaanus]

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

[gabriele renzi]

On Fri, Apr 16, 2010 at 9:21 PM, dhavaln <dhaval....@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 ;)

[Jaanus]

Another 2c: you should think about publishing numbers/stats for
annotations. Easiest to start on the level of namespaces. Publish
stats about popularity of namespaces: how many tweets and how many
users use which namespaces. And don't do "that's a good idea and there
are still many moving parts and we are thinking of it for the future,"
do "this is absolutely vital for the community from day 1" :) This
would be a good measure for community to inform what namespaces to
support, what works and what doesn't, etc.


J

[James A. Rosen]

Developers can use reverse-FQDNs (like Java's packages) for their
namespaces, which prevents collisions without actually requiring
nesting.

-James A. Rosen

[Marcel Molina]

This is a great idea for how to bootstrap and fuel the adoption and consensus on namespaces and key names. I'm going to talk to our analytics team and see if we can surface analytics on the most used namespaces and those namespace's most used keys.

[Zac Bowling]

Thanks for the insight this early into everything. This helps from the communication standpoint. 

I hope this devolve thought into design by commit on this thread though for the name-spacing. I have a few ideas but I'm reserving them because they may be obvious and not going to hurt me because I can work around anything you make. 

Now make some annotations. :-)

Zac Bowling

[Marcel Molina]

I've talked to the analytics team. Three main metrics we're going to work to surface on something like dev.twitter.com initially (and maybe even an API so you all can build experiences/explorers around annotations):

1) All time most used namespaces/keys.

2) Trending namespace/keys.

3) Most widely adopted namespace/keys (i.e. not necessarily the most used but the ones used by the highest number of different client applications)

On Fri, Apr 16, 2010 at 1:43 PM, Marcel Molina <mar...@twitter.com> wrote:

[Nigel Legg]

Been following the conversation; very interesting to see, even today, the devlopment of ideas around potential standards from the community of developers. To see the trends, most used, etc will definitely help us work towards the namespaces and keys with the most utility for ourselves and our users.

[Robby Grossman]

Thanks for all of the info, Marcel. Cool stuff!

How would people feel about a wiki for developers to share thoughts on
how to use/standardize on annotations? That would give us a chance to
flesh out some of the namespacing issues that have been raised so that
we can hit the ground running when Annotations are launched. I'd be
happy to set up a PBWorks page or maybe a Google Doc that can be
shared
with this list.

--Robby

[Raffi Krikorian]

i expect we'll put a page up on dev.twitter.com that will allow people to list out namespaces, keys, etc.  all for the community.

[Nigel Legg]

I'd say keep it all on dev.twitter.com - minimise sites to visit.

[Shannon Whitley]

I think this will be a great addition to the platform.  I suppose it will be up to each software client to determine how (classic) retweets are handled.  The annotations could be copied and edited.  I assume new retweets will simply reference the original tweet and its annotations. 

[M. Edward (Ed) Borasky]

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?

M. Edward (Ed) Borasky
borasky-research.net/m-edward-ed-borasky

"A mathematician is a device for turning coffee into theorems." ~ Paul Erdős

[sean]

XML option #2 feels like the best option to me, because it seems the
most flexible, most forward compatible, and plays well with AWS:
http://docs.amazonwebservices.com/AmazonSimpleDB/latest/DeveloperGuide/SDB_API_GetAttributes.html

(that's my $0.02)

_s.

>   XML option #2 which is more verbose but allows for namespaces and keys to
> contain arbitrary data
>
>   <annotations>
>     <annotation>
>       <namespace>iso</namespace>
>       <key>isbn</key>
>       <value>030759243X</value>
>     </annotation>
>     <annotation>
>       <namespace>amazon</namespace>
>       <key>url</key>

>       <value>http://www.amazon.com/Although-Course-You-Becoming-Yourself/dp/030759...

> </value>
>     </annotation>
>   </annotations>
>
> If we went with XML option #2 it may or may not be a problem that it isn't
> "symmetrical" with the JSON representation. On the other hand, JSON and XML
> tend to be culturally at opposite sides of the Pithiness Spectrum.

[Kingsley Idehen]

Marcel Molina wrote:
> I've talked to the analytics team. Three main metrics we're going to
> work to surface on something like dev.twitter.com

> <http://dev.twitter.com> initially (and maybe even an API so you all

Marcel,

Please take a look at this blog post which covers the issue of
Structured Data [1].

At the end of the day, every Tweet is a uniquely identifiable data
object (entity). Annotations ultimately come down to making simple
statements about the attributes of a Tweet, thus the
Entity-Attribute-Value (EAV) works here as it does everywhere else re.
data representation flexibility (XML, JSON, and other data
representation formats).

Links:

1. http://bit.ly/cA0zxw -- Data 3.0 Manifesto (all about Structured Data
and the EAV Model)
2. http://semantictwitter.appspot.com/ -- an example of compact EAV
style 3-tuple approach to annotations
3. http://smob.me/ -- ditto .

--

Regards,

Kingsley Idehen
President & CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen

[R_Macdonald]

On Apr 16, 10:54 am, Marcel Molina <mar...@twitter.com> wrote:
> This isn't final. The payloads could end up wildly different after we noodle
> around in things like RDF and the semantic web's literature and all that
> kind of stuff. You can't see me but my hands are waving vigorously.

I think there are amazing opportunities in Twitter's new annotation
feature.

I am awestruck by the potential of developers applying Linked Data /
Semantic Web schema and using RDF in Twitter annotations. It would
massively scale search effectiveness and distribution opportunities
while allowing sophisticated on-the-fly analysis of Twitter's firehose
& other feeds.

The Twitter ecosystem is particularly suited to applying principles of
the Semantic Web in that machine interpolated meaning could be
continually refined the more humans tweet & retweet about the same and
related topics (resolved by semantic entity detection; coupled with
author, location, hashes, platform, temporal and other information.

The vision of Semantic Web is occasionally dismissed as long on dream
and short on practice. However, early implementations are gaining
significant traction and offering substantive value to early
adopters. Thompson Reuters, no slouch in the business of information,
was quite visionary in acquiring the now @OpenCalais service. The
mostly free service is currently identifying semantic entities in over
5 million documents submitted to it per day. @zemanta is also finding
a significant user base among bloggers for its related services.

Twitter annotations may well be a turning point in the early practical
application of Tim Berners-Lee’s 1999 “dream for the Web [in which
computers] become capable of analyzing all the data on the Web – the
content, links, and transactions between people and computers.”

It is all about the metadata!

[Aral Balkan]

I like that annotations will be open so that the various schema can
live/die organically based on client adoption (or lack thereof) rather
than an artificially-emposed constraint.

I outlined some of my ideas for annotations (or "Twitterformats", as I
called them) at the end of last year at http://twitterformats.org —
hope they add to the conversation.

Aral

Sent from my iPhone

On 16 Apr 2010, at 19:24, Joseph Cheek <jos...@cheek.com> wrote:

> awesome idea! I know I can find a use for it. Some concerns,
> however, below...
>
> Joseph Cheek
>
> Marcel Molina wrote:
>
> the sentence

>> Namespaces aren't intended as a way for people to claim their
>> little slice of the tweet space.

> and the sentence

>> 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.

> seem to be at odds with each other. If you don't provide a way for
> us devs to claim a particular namespace, you force each of us to
> figure out what a dev meant with namespace xyz, which is what you
> way you want to avoid. Perhaps namespaces can be prefixed with
> com.cheek.twitter or somesuch à la Java. Just a thought.

>> We're erring on the side of thinking that the moderate increase in
>> payload size for tweets with annotations, even on slow connections,
>> is both more convenient and faster than the latency and
>> inconvenience incurred by adding another HTTP round trip.

> agreed, especially with rate limiting in place.

>> * Ok, great. How are we going to figure out what Joe Random's
>> annotations actually mean?
>>
>> That's something we need to figure out as a community. But here is
>> an early idea: People could add some agreed upon "meta-annotation"
>> that points to something which *describes* the annotation or
>> annotations that person is using. Think something sort of like XML
>> DTD, though not necessarily machine readable. This meta annotation
>> could point to a URL that simply has an HTML document that gives a
>> description with some examples of the various annotations you're
>> experimenting with or standardizing on.

> Interesting. So I could add metadata to the tweet so that my foo
> namespace isn't interpreted the same as other's foo namespaces? If
> so, then I would want the ability to select this metadata in a
> search - if I have to manually code something to recognize namespace
> foo for metadata http://www.cheek.com/my_twitter_rules_are_here.html
> then I don't want results for everyone else's namespace foo that my
> app won't recognize. Make sense?
>
> so then namespace com.cheek.foo becomes namespace foo with metadata cheek.com/blahblah
> . ok, i can do that.

[R_Macdonald]

ReadWriteWebs's Co-Editor, Marshall Kirkpatrick, suggests today that
Twitter intends to leave the annotation classification system to be
determined by the market.
http://bit.ly/csK8Od

Although I appreciate that Twitter values keeping the annotation
ecosystem open for innovation and adaptation, I hope the conversation
on Linked Data metadata standards within Twitter annotations is just
beginning.

It could be an historic lost opportunity if the hard driving Twitter
team doesn’t step back and consider soliciting the counsel of the W3C,
Sir TB-L, Nigel Shadbolt and others in the Linked Data community.
After all, Metaweb's Freebase team is just 3 blocks away.

[M. Edward (Ed) Borasky]

On 04/19/2010 08:06 PM, R_Macdonald wrote:
> ReadWriteWebs's Co-Editor, Marshall Kirkpatrick, suggests today that
> Twitter intends to leave the annotation classification system to be
> determined by the market.
> http://bit.ly/csK8Od
>
> Although I appreciate that Twitter values keeping the annotation
> ecosystem open for innovation and adaptation, I hope the conversation
> on Linked Data metadata standards within Twitter annotations is just
> beginning.
>
> It could be an historic lost opportunity if the hard driving Twitter
> team doesn’t step back and consider soliciting the counsel of the W3C,
> Sir TB-L, Nigel Shadbolt and others in the Linked Data community.
> After all, Metaweb's Freebase team is just 3 blocks away.
>
>

That's *exactly* what I told Marshall! I know him - he lives here in
PDX. Sir Tim Berners-Lee got a significant chunk of funding to develop
the Semantic Web, and I'd think he'd have a lot to say about Twitter
Annotations if we'd only ask him!

--
M. Edward (Ed) Borasky
borasky-research.net/m-edward-ed-borasky

"A mathematician is a device for turning coffee into theorems." ~ Paul Erdős

[Raffi Krikorian]

Not to be glib, but they are more than welcome to join in on the
conversation in the community. We plan to let the community really
drive this one.



On Apr 19, 2010, at 8:06 PM, R_Macdonald <roger.g....@gmail.com>
wrote:

[Kingsley Idehen]

Raffi Krikorian wrote:
> Not to be glib, but they are more than welcome to join in on the
> conversation in the community. We plan to let the community really
> drive this one.
>
>
>
> On Apr 19, 2010, at 8:06 PM, R_Macdonald <roger.g....@gmail.com>
> wrote:
>
>> ReadWriteWebs's Co-Editor, Marshall Kirkpatrick, suggests today that
>> Twitter intends to leave the annotation classification system to be
>> determined by the market.
>> http://bit.ly/csK8Od
>>
>> Although I appreciate that Twitter values keeping the annotation
>> ecosystem open for innovation and adaptation, I hope the conversation
>> on Linked Data metadata standards within Twitter annotations is just
>> beginning.
>>
>> It could be an historic lost opportunity if the hard driving Twitter

>> team doesn�ft step back and consider soliciting the counsel of the W3C,

>> Sir TB-L, Nigel Shadbolt and others in the Linked Data community.
>> After all, Metaweb's Freebase team is just 3 blocks away.
>>
>>
>> --
>> Subscription settings:
>> http://groups.google.com/group/twitter-development-talk/subscribe?hl=en
>

Raffi,

Is is a Wiki or some other publicly accessible shared document space
where the What, Why, and How of Twitter's Structured Annotations is
being developed?

[M. Edward (Ed) Borasky]

On 04/19/2010 11:21 PM, Raffi Krikorian wrote:
> Not to be glib, but they are more than welcome to join in on the
> conversation in the community. We plan to let the community really
> drive this one.

Yes, but, for example, is Sir Tim Berners-Lee even *on* Twitter? I know
Marshall Kirkpatrick is, but he's a journalist, not a standards-maker.

Of course, there are *lots* of people I'd like to see on Twitter.

http://borasky-research.net/2010/04/18/the-top-ten-people-who-should-be-on-twitter-but-arent/

>
>
>
> On Apr 19, 2010, at 8:06 PM, R_Macdonald <roger.g....@gmail.com>
> wrote:
>
>> ReadWriteWebs's Co-Editor, Marshall Kirkpatrick, suggests today that
>> Twitter intends to leave the annotation classification system to be
>> determined by the market.
>> http://bit.ly/csK8Od
>>
>> Although I appreciate that Twitter values keeping the annotation
>> ecosystem open for innovation and adaptation, I hope the conversation
>> on Linked Data metadata standards within Twitter annotations is just
>> beginning.
>>
>> It could be an historic lost opportunity if the hard driving Twitter
>> team doesn’t step back and consider soliciting the counsel of the W3C,
>> Sir TB-L, Nigel Shadbolt and others in the Linked Data community.
>> After all, Metaweb's Freebase team is just 3 blocks away.
>>
>>
>> --
>> Subscription settings:
>> http://groups.google.com/group/twitter-development-talk/subscribe?hl=en
>
>

[Raffi Krikorian]

Not to be glib, but they are more than welcome to join in on the conversation in the community. We plan to let the community really drive this one.

ReadWriteWebs's Co-Editor, Marshall Kirkpatrick, suggests today that
Twitter intends to leave the annotation classification system to be
determined by the market.
http://bit.ly/csK8Od

Although I appreciate that Twitter values keeping the annotation
ecosystem open for innovation and adaptation, I hope the conversation
on Linked Data metadata standards within Twitter annotations is just
beginning.

It could be an historic lost opportunity if the hard driving Twitter

team doesn�ft step back and consider soliciting the counsel of the W3C,

Sir TB-L, Nigel Shadbolt and others in the Linked Data community.
After all, Metaweb's Freebase team is just 3 blocks away.

Raffi,

Is is a Wiki or some other publicly accessible shared document space where the What, Why, and How of Twitter's Structured Annotations is being developed?

there will be soon!  taylor and i will work on getting a page up.

 

[Kingsley Idehen]

Raffi,

Great! I think once that's in place, the community process will accelerate.

--

Regards,

Kingsley Idehen
President & CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen