Any ideas on size limitations or restrictions for this meta data?
--
To unsubscribe, reply using "remove me" as the subject.
simple math based on average tweet status byte size (of status
structure coming through the streaming or REST interface) tells us
that it wouldn't take much being jammed into the annotation's field to
double that size. what status size increase is Twitter's
infrastructure ready/willing to tolerate?
it seems to me that a few things are NOT candidates for the
annotations field(s):
- void * (for you old schoolers on the list)
- media who's original native format is binary (e.g. photos/videos)
annotations will need limitations like:
- overall size
- if key/value pairs become the model... they'll need individual size
limitations (for name and value)
- max number of pairs
- etc.
the whole thing feels driven by the answer to the original "size"
question.
another question would be whether or not the tweet originator can
remove annotations that others put on their tweet? I'd assume that I'd
have control over my original tweet in that manner (e.g. "notes"
functionality on Flickr)
--
To unsubscribe, reply using "remove me" as the subject.
Is the planning for everyone's annotations to be available to everyone
else, or will there be private namespaces accessible only to the
source application?
--
To unsubscribe, reply using "remove me" as the subject.
> --
> To unsubscribe, reply using "remove me" as the subject.
In addition to size constraints, I'd like to *strongly* suggest that wherever possible, annotations use *existing* open standards! Please, let's not "reinvent the semantic web", even if we can. ;-)
On Apr 15, 9:05 am, Raffi Krikorian <ra...@twitter.com> wrote:
> please feel free to point us to standards that you would like us to
> consider. we are really attempting to make this insanely simple by
> literally just having a triple of items to store (namespace, key, value) --
> so, we are just really talking about representation, i assume.
>
>
>
>
>
> On Thu, Apr 15, 2010 at 12:09 AM, <zn...@comcast.net> wrote:
>
Part of this stems from my concern over something I thought I heard
yesterday about Twitter building its own "place" database. There are
dozens of place databases - why does Twitter need another one?
On Apr 15, 6:05 am, Raffi Krikorian <ra...@twitter.com> wrote:
> please feel free to point us to standards that you would like us to
> consider. we are really attempting to make this insanely simple by
> literally just having a triple of items to store (namespace, key, value) --
> so, we are just really talking about representation, i assume.
>
>
>
> On Thu, Apr 15, 2010 at 12:09 AM, <zn...@comcast.net> wrote:
>
Will annotations be indexed and searchable? Will I be able to search
for all tweets with a certain annotation namespace, or namespace:key?
I think this would be key to truly creating agreeable standards for
metadata that can be utilized by many clients.
I'm thinking of something like the RFC process for Internet protocols.
Part of this stems from my concern over something I thought I heard
yesterday about Twitter building its own "place" database. There are
dozens of place databases - why does Twitter need another one?
+1!! ;)
On Apr 15, 2010 7:09 a.m., <zn...@comcast.net> wrote:----- "Jud" <jval...@gmail.com> wrote: > On Apr 14, 5:05 pm, James Teters <jtet...@gmail.com> wro...
Thanks for that info. Will try to gather a few and send them later.
So you're ruling out concepts w/ multiple properties? Like a vcard?
This seems similar to what axschema.org have for openid. Namespaces have to be uris, obviously.
Cheers,
André Luís
On Apr 15, 2010 1:09 p.m., "Raffi Krikorian" <ra...@twitter.com> wrote:
please feel free to point us to standards that you would like us to consider. we are really attempting to make this insanely simple by literally just having a triple of items to store (namespace, key, value) -- so, we are just really talking about representation, i assume.
On Thu, Apr 15, 2010 at 12:09 AM, <zn...@comcast.net> wrote: > > > ----- "Jud" <jval...@gmail.com...
Hmm doesn't OSM contain sufficient data to actually be turned into a
place database?
I'm thinking administrative boundaries et al.
Mathias.
Why shorten links that won't count for 140 limit and are not viewed by user? It will only add un-needed requests and waste values on the twiter shortener.
André Luís
On Apr 15, 2010 2:18 p.m., "M. Edward (Ed) Borasky" <zzn...@gmail.com> wrote:
I'm thinking of something like the RFC process for Internet protocols.
By the way, on a related note, once the "Twitter link shortener" I've
been hearing rumors about is in place, can we have all the links in
tweets sent from the API shortened with it? Profile images, user
object URLs, etc. ;-)
Part of this stems from my concern over something I thought I heard
yesterday about Twitter building its own "place" database. There are
dozens of place databases - why does Twitter need another one?
On Apr 15, 6:05 am, Raffi Krikorian <ra...@twitter.com> wrote:
> please feel free to point us to standards that you would like us to > consider. we are really att...
> On Thu, Apr 15, 2010 at 12:09 AM, <zn...@comcast.net> wrote: >
> > ----- "Jud" <jvale...@gmail.com> wrote: > > > > On Apr 14, 5:05 pm, James Teters <jtet...@gmail....
On Apr 15, 7:49 am, Raffi Krikorian <ra...@twitter.com> wrote:
> a way to think about this is analogous to geo. people used to put geo
> information in the 140 characters -- but now, we allow you to put it out of
> band in a machine-readable way. we want to extend that functionality to all
> types of meta data (links to URLs, etc.).
>
> 2010/4/15 André Luís <andreluis...@gmail.com>
We've got a couple of really sharp open source mapping geeks in PDX -
try @GeoPDX and @elsewisemedia for starters.
How about keeping a new way of talking to Twitter human readable during its
initial implementation? Premature optimization.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- In Computer Science, we stand on each other's feet. -- Brian Reid ----------
--
To unsubscribe, reply using "remove me" as the subject.