Twitter Places - Activity Streams Transform

[ewryan]

At Gnip we are attempting to update our Twitter Activity Streams
transforms to include Twitter's Place data, and have uncovered a few
questions:

1. Twitter has a Places feature which includes more information about
locations (id, url, attributes, place_type, etc..). How do we
associate a status with a place in AS?
We see two options:
A. Insert a <poco:address> & <georss:polygon> of a place into the
<entry> (http://gist.github.com/486357#file_gnip_as_option_a.xml)
B. Nest a <context:location> within the note object, containing the
place. (http://gist.github.com/486357#file_gnip_as_option_b.xml)

Of the two, option A seems to be the simplest solution. However,
adding the place's location to the entry is results in losing a lot of
information about the place (such as id, url, attributes, place_type,
etc..). We'd like to move forward with option B or something
equivalent. Suggestions?

2. The other thing we were wondering about was whether we can use
other GeoRSS Simple tags to describe locations. The AS spec uses
<georss:point>, but there are places where it is unclear if other
types are allowed. Twitter supplies a bounding box element that
contains a <georss:polygon>. We'd like to use the polygons they give
us to describe the places we are adding to our AS markup. Would this
be valid AS?


There is some talk of adding places to activity objects on the wiki:
http://wiki.activitystrea.ms/Places
http://wiki.activitystrea.ms/Event

This post seems to be relevant to the 'Place metadata' discussion, but
there wasn't any response/resolution:
http://groups.google.com/group/activity-streams/browse_thread/thread/101eb510508d7b74/cdef98ddb6f5363c

[Monica Keller]

Hi Eric
Do you mind posting the json for a Twitter place so we can all be on
the same page as you ?
Comments inline:

On Jul 22, 11:24 am, ewryan <ewr...@gmail.com> wrote:
> At Gnip we are attempting to update our Twitter Activity Streams
> transforms to include Twitter's Place data, and have uncovered a few
> questions:
>
> 1.  Twitter has a Places feature which includes more information about
> locations (id, url, attributes, place_type, etc..). How do we
> associate a status with a place in AS?
> We see two options:
>   A. Insert a <poco:address> & <georss:polygon> of a place into the
> <entry> (http://gist.github.com/486357#file_gnip_as_option_a.xml)
>   B. Nest a <context:location> within the note object, containing the
> place. (http://gist.github.com/486357#file_gnip_as_option_b.xml)
>
> Of the two, option A seems to be the simplest solution. However,
> adding the place's location to the entry is results in losing a lot of
> information about the place (such as id, url, attributes, place_type,
> etc..).  We'd like to move forward with option B or something
> equivalent.  Suggestions?
>

Really what you are representing is the actor being at a place when
they tweet therefore the <context:location> should be at the activity
level
A place is like any other object and the initial set of properties are
documented here:
http://wiki.activitystrea.ms/Place

It has an id, url and you are welcome to create a new property "place
type" or we can use the object type for that and have it derive from
"Place"
if we think certain place types will have other attributes.
Also feel free to add properties to convey the polygon if this is
something you think makes sense in activities.
Personally feels like too much info but who knows.

> 2.  The other thing we were wondering about was whether we can use
> other GeoRSS Simple tags to describe locations. The AS spec uses
> <georss:point>, but there are places where it is unclear if other
> types are allowed. Twitter supplies a bounding box element that
> contains a <georss:polygon>. We'd like to use the polygons they give
> us to describe the places we are adding to our AS markup.  Would this
> be valid AS?
>

If you are using atom you can use any atom extension. That is how we
got started with geo and poco for example. But it would be good to
think about the concepts and the JSON representation so I invite you
to update the wiki page with your proposal and we can discuss here.
Cool ?

> There is some talk of adding places to activity objects on the wiki:http://wiki.activitystrea.ms/Places
>http://wiki.activitystrea.ms/Event
>
> This post seems to be relevant to the 'Place metadata' discussion, but

> there wasn't any response/resolution:http://groups.google.com/group/activity-streams/browse_thread/thread/...

[Kevin Marks]

Apologies for terse reply as I am lacking a mac or a phone.
Place needs Address, geopoint, and LIST of urls. That way we can point
back at twitter, foursquare, google, whomever for further info, and if
a processor normalizes to its own place id it can still presrve
originating ones.

> --
> You received this message because you are subscribed to the Google Groups "Activity Streams" group.
> To post to this group, send email to activity...@googlegroups.com.
> To unsubscribe from this group, send email to activity-strea...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/activity-streams?hl=en.
>
>

[Aaron Parecki]

Thoughts on representing places:
* address should be optional
* a place should be defined by either a lat/long point or a polygon
* I support the idea of a list of URLs

Will try to give a more thoughtful reply when I can get back to my computer.

aaronpk

On Jul 22, 2010 12:02 PM, "Kevin Marks" <kevin...@gmail.com> wrote:

Apologies for terse reply as I am lacking a mac or a phone.
Place needs Address, geopoint, and LIST of urls. That way we can point
back at twitter, foursquare, google, whomever for further info, and if
a processor normalizes to its own place id it can still presrve
originating ones.

On Thursday, July 22, 2010, ewryan <ewr...@gmail.com> wrote:

> At Gnip we are attempting to update ...

[ewryan]

Monica:

>Do you mind posting the json for a Twitter place so we can all be on the same page as you ?

We're consuming the xml representation of a tweet. See lines 52-71 -
http://gist.github.com/486357#file_twitter_original.xml

>Really what you are representing is the actor being at a place when
>they tweet therefore the <context:location> should be at the activity
>level

Ok cool.. we'll move the <context:location> element to be a child of
<entry> instead of <activity:object>

>If you are using atom you can use any atom extension...
Sound's good. We'll go ahead a leave the <geo:polygon> as a child of
the <context:location>

>so I invite you to update the wiki page

Will do.

Kevin:
>Place needs Address, geopoint
Twitter sometimes does not include a geopoint, only a geopolygon. Is
it still valid AS if we omit the geopoint?

>and LIST of urls
Is the json url supplied by twitter sufficient? See line 64 -
http://gist.github.com/486357#file_twitter_original.xml

> >http://groups.google.com/group/activity-streams/browse_thread/thread/...

[Monica Keller]

So we have links for all objects via link rel="alternate" in both atom
and JSON

On Jul 22, 12:17 pm, Aaron Parecki <aa...@parecki.com> wrote:
> Thoughts on representing places:
> * address should be optional
> * a place should be defined by either a lat/long point or a polygon
> * I support the idea of a list of URLs
>
> Will try to give a more thoughtful reply when I can get back to my computer.
>
> aaronpk
>

[ewryan]

Just to close the loop here..

We decided not to use the <context:location> element as it only
appeared in the wiki, not in the spec. Went this route since both
georss and poco are valid atom extensions and should therefore should
be valid AS. We are adding all relevant geo information as a child of
the <entry> element instead of the <activity:object> element.

Here is the AS transformed tweet we ended up with:
http://gist.github.com/490904#file_as_tweet.xml
Based off of this original tweet: http://gist.github.com/490904#file_original_tweet.xml

Note that we ended up dropping some of the place's fields from the
original tweet (id, place_type, attributes) in anticipation that they
will be covered by the spec at a future date.

Eric

[Kevin Marks]

On Mon, Jul 26, 2010 at 11:10 AM, ewryan <ewr...@gmail.com> wrote:

Just to close the loop here..

We decided not to use the <context:location> element as it only
appeared in the wiki, not in the spec.  Went this route since both
georss and poco are valid atom extensions and should therefore should
be valid AS.  We are adding all relevant geo information as a child of
the <entry> element instead of the <activity:object> element.

Here is the AS transformed tweet we ended up with:
http://gist.github.com/490904#file_as_tweet.xml
Based off of this original tweet:  http://gist.github.com/490904#file_original_tweet.xml

Note that we ended up dropping some of the place's fields from the
original tweet (id, place_type, attributes) in anticipation that they
will be covered by the spec at a future date.

you could preserve a link to them with poco:urls (which has a type field too)

 

Eric

On Jul 22, 1:26 pm, Monica Keller <monica.kel...@gmail.com> wrote:
> So we have links for all objects via link rel="alternate" in both atom
> and JSON
>
> On Jul 22, 12:17 pm, Aaron Parecki <aa...@parecki.com> wrote:
>
> > Thoughts on representing places:
> > * address should be optional
> > * a place should be defined by either a lat/long point or a polygon
> > * I support the idea of a list of URLs
>
> > Will try to give a more thoughtful reply when I can get back to my computer.
>
> > aaronpk
>
> > On Jul 22, 2010 12:02 PM, "Kevin Marks" <kevinma...@gmail.com> wrote:
>
> > Apologies for terse reply as I am lacking a mac or a phone.
> > Place needs Address, geopoint, and LIST of urls. That way we can point
> > back at twitter, foursquare, google, whomever for further info, and if
> > a processor normalizes to its own place id it can still presrve
> > originating ones.
>
> > On Thursday, July 22, 2010, ewryan <ewr...@gmail.com> wrote:
> > > At Gnip we are attempting to update ...

[Monica Keller]

I actually think the right answer is to add this to the spec since
there was consensus to represent places as objects using the
context:location tag
Will and Rob what do you think since we are trying to keep atom small.
Do we do a separate spec or same one but as v1.1

[ewryan]

Sounds good Monica. An update to the spec with more definition on how
to represent geo information would be beneficial. Unfortunately, we
just pushed our current transforms to production. For now we're going
to stick with adding georss/poco extensions as children of the <entry>
element. Once the spec is updated, we'll conform to that.

I'd like to see the spec define how to address following:
-point - lat/long pair
-polygon - n number of lat/long pairs
-id - publisher specific unique id representing the place
-url - publisher specific url representing the place

Assuming place_name and country are already addressed with
poco:address.

Eric

[Monica Keller]

Actually here is the section on the schema spec which matches what you
are doing today of not using context:location.

http://activitystrea.ms/head/activity-schema.html#location

We should leave this as is for Atom and only consider splitting for
JSON