Conveying location

[Monica Keller]

Does anyone have a problem replacing
http://martin.atkins.me.uk/specs/activitystreams/activityschema#anchor17

With this:

3.3.1. Location
Location context describes the location where the user was at the time
the activity was performed. This may be an accurate geographic
coordinate, a street address, a free-form location name or a
combination of these.
Geographic coordinates can be included as a geo:point element as a
direct child of the activity entry, as described by the GeoRSS
specification.
<geo:point>33.9777 -118.4351</geo:point>
Addresses can be included using a poco:address element. Please see
http://portablecontacts.net/draft-spec.html#address_element
<poco:address>
<poco:locality>Marina del rey, CA</poco:locality>
<poco:postalCode>90292</poco:postalCode>
<poco:country>US</poco:country>
</poco:address>
Also note that if you don’t have the location of the user at the time
of the action or prefer not to syndicate this information for security
reasons you can also provide the published general location for the
user inside the actor element.
For free form addresses please use poco:formatted field. Example:
<poco:formatted>My House in SF< poco:formatted>

This was one of my TODOs from last meeting so I wanted to circulate.

Thanks
Monica

ps - all this is available on our real time stream and we have a
contest coming up to see the best use http://www.myspace.com/developerchallenge

[Chris Messina]

+1.

This is a good replacement for that section.

I appreciate the addition of the PoCo schema.

Chris

--

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.

--
Chris Messina
Open Web Advocate

Personal: http://factoryjoe.com
Follow me on Twitter: http://twitter.com/chrismessina

Citizen Agency: http://citizenagency.com
Diso Project: http://diso-project.org
OpenID Foundation: http://openid.net

This email is:   [ ] shareable    [X] ask first   [ ] private

[Sylvain Carle]

Can I suggest an optional Venue ID somewhere, to support identifiers
from external services, a bit like you they do on Flickr with machine
tags à la "foursquare:venue=351301". This could be useful when
constructing an activity stream with places as subject and aggregate
from multiple sources.

See some discussion on from Status.net at http://status.net/wiki/LocationPlan
with Geonames and OSM as examples.

We are thinking about how we can encode places in activity streams for
or next release in January, this discussion is timely.

--
Sylvain Carle / Praized

> +1.
>
> This is a good replacement for that section.
>
> I appreciate the addition of the PoCo schema.
>
> Chris
>

> > activity-strea...@googlegroups.com<activity-streams%2Bunsu...@googlegroups.com>

[Kevin Marks]

I think this is great. One thing it does make me wonder a little is if we want to enable locations other than 'the current one' to be referenced (eg if I post an old school photo, the location of the school makes more sense than where I happen to be)

[Martin Atkins]

On 12/22/2009 12:17 PM, Kevin Marks wrote:
> I think this is great. One thing it does make me wonder a little is if
> we want to enable locations other than 'the current one' to be
> referenced (eg if I post an old school photo, the location of the school
> makes more sense than where I happen to be)
>

I guess this could be represented by putting the location elements in
the photo object itself rather than the activity of posting the photo.

Though this does get more fuzzy when people take photos on their mobile
devices and post them immediately. The distinction betwen activity
location and photo location gets a lot more blurry in that situation.

[Bill de hOra]

> Geographic coordinates can be included as a geo:point element

There should be room in the spec to allow privacy. geo:location makes no
allowances for this, poco is an addess which is a very specific
construct. Maybe AS should have its own element?

Bill

Monica Keller wrote:
> Does anyone have a problem replacing
> http://martin.atkins.me.uk/specs/activitystreams/activityschema#anchor17
>
> With this:
>
> 3.3.1. Location
> Location context describes the location where the user was at the time
> the activity was performed. This may be an accurate geographic
> coordinate, a street address, a free-form location name or a
> combination of these.
> Geographic coordinates can be included as a geo:point element as a
> direct child of the activity entry, as described by the GeoRSS
> specification.
> <geo:point>33.9777 -118.4351</geo:point>
> Addresses can be included using a poco:address element. Please see
> http://portablecontacts.net/draft-spec.html#address_element
> <poco:address>
> <poco:locality>Marina del rey, CA</poco:locality>
> <poco:postalCode>90292</poco:postalCode>
> <poco:country>US</poco:country>
> </poco:address>

> Also note that if you don�t have the location of the user at the time

> of the action or prefer not to syndicate this information for security
> reasons you can also provide the published general location for the
> user inside the actor element.
> For free form addresses please use poco:formatted field. Example:
> <poco:formatted>My House in SF< poco:formatted>
>
> This was one of my TODOs from last meeting so I wanted to circulate.
>
> Thanks
> Monica
>
>
> ps - all this is available on our real time stream and we have a
> contest coming up to see the best use http://www.myspace.com/developerchallenge
>
>
>
>

[Chris Messina]

Hi Bill,

I don't understand how privacy fits into this. You're describing what appears to me to be a policy issue — rather than one for the format to figure out.

Perhaps you can provide some guidance or examples as to how privacy information would be specified here? Basically, we're just talking about representing data — it should be up to the app to decide whether and with whom to share what data...

Chris

> Also note that if you don’t have the location of the user at the time

> of the action or prefer not to syndicate this information for security
> reasons you can also provide the published general location for the
> user inside the actor element.
> For free form addresses please use poco:formatted field. Example:
> <poco:formatted>My House in SF< poco:formatted>
>
> This was one of my TODOs from last meeting so I wanted to circulate.
>
> Thanks
> Monica
>
>
> ps - all this is available on our real time stream and we have a
> contest coming up to see the best use http://www.myspace.com/developerchallenge
>
>
>
>
> --
>
> 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.
>
>

--

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.

[Chris Messina]

Actually, this is really interesting and important.

Given our structure:

entry

- actor

- verb

- object

- target/indirect object

It would appear to me that perhaps it'd make more sense to move location into the actor and object.

While it would be simplest to feature location as an entry-level attribute...

entry

- actor

- verb

- object

- target/indirect object

- location

...it also seems like there might be those more granular cases:

entry

- actor

-- location

- verb

- object

-- location

- target/indirect object

As in...

"Martin took a photo in Vancouver but posted it from San Francisco, when he returned from his trip".

The activity is posting a photo, but the geo information for the photo itself would be different from the activity itself, or more importantly, where the actor was when he acted (posted the photo).

Clearly there's a need to define location separately — but at the same time, the convention (so far) of applying the geo to the entry itself seemed somewhat outmoded (that is, geoRSS is useful for hinting at the location of the author of the post, rather than what the post is about). 

Being able to distinguish between the actor's location and the object's location seems to me to be very valuable and important, and something that we can clarify over previous implementations.

Thoughts?

Chris

[Bob Aman]

> "Martin took a photo in Vancouver but posted it from San Francisco, when he
> returned from his trip".
> The activity is posting a photo, but the geo information for the photo
> itself would be different from the activity itself, or more importantly,
> where the actor was when he acted (posted the photo).
> Clearly there's a need to define location separately — but at the same time,
> the convention (so far) of applying the geo to the entry itself seemed
> somewhat outmoded (that is, geoRSS is useful for hinting at the location of
> the author of the post, rather than what the post is about).
> Being able to distinguish between the actor's location and the object's
> location seems to me to be very valuable and important, and something that
> we can clarify over previous implementations.

I can't think of even one circumstance where I would consider both
locations "interesting". Either I'm interested in where the object
was created, or I'm interested in where the actor is located, but I
don't think there's much value in knowing both if they're different,
and I'd be worried about confusing people if there were two locations,
especially if they're the same or very, very close together but not
identical. I see the value in making the distinction, and I think
that perhaps recommending against a single entry containing multiple
locations would be a bit much, but in that case, I'd like to see a
side-note along the lines of: "Including a location for both an actor
and an object is uncommon." Because it will be.

-Bob

[mary hodder]

Actually this comes up with news stories all the time.. and
presumably blog posts given some way to communicate locations in a
meaningful way.

The format that I worked on with AP and Google News is set up to deal
with this because location matters.... it was something that at first
they didn't see the need for but for news.. you do need it. Bylines
and author location are often one place, and subject location is
another.

mary

> --
>
> You received this message because you are subscribed to the Google
> Groups "Activity Streams" group.

> To post to this group, send email to activity-
> str...@googlegroups.com.
> To unsubscribe from this group, send email to activity-streams
> +unsub...@googlegroups.com.

[Chris Messina]

On Tue, Dec 22, 2009 at 4:22 PM, Bob Aman <api.b...@gmail.com> wrote:

> Being able to distinguish between the actor's location and the object's
> location seems to me to be very valuable and important, and something that
> we can clarify over previous implementations.

I can't think of even one circumstance where I would consider both
locations "interesting".  Either I'm interested in where the object
was created, or I'm interested in where the actor is located, but I
don't think there's much value in knowing both if they're different,
and I'd be worried about confusing people if there were two locations,
especially if they're the same or very, very close together but not
identical. 

A good example of a location-based activity, today, is Twitter. The Tweetie iPhone app, for one example, lets you geotag your tweets — so that when you tweet, your location is encoded into the activity. Simple, makes sense, provides context.

OTOH, a service like SimpleGeo provides contextual information ABOUT a location... regardless of where the author of the content was when it was put online. 

Furthermore, from an aggregation perspective, I think that real-time location information is valuable for context, but less valuable over time, when your goal is collect information relevant to a specific place. 

In other words, the actor exists in space-time; the object of an activity, as it seems, exists more in space (depending on the object of course, but I'm thinking of places or immovable things).

In order to advance this conversation, I think we'll need more examples. I've started a page to document this conversation and collect other examples. Please help improve this page and add sections!

https://activitystreams.pbworks.com/Location

(public link: http://wiki.activitystrea.ms/Location)

[Bob Aman]

> Actually this comes up with news stories all the time.. and
> presumably blog posts given some way to communicate locations in a
> meaningful way.
>
> The format that I worked on with AP and Google News is set up to deal
> with this because location matters.... it was something that at first
> they didn't see the need for but for news.. you do need it.  Bylines
> and author location are often one place, and subject location is
> another.

Oh yeah, definitely. But the "interesting" location there is the
story location, not the author location. You could include the author
location, and it wouldn't be ambiguous, but for any application that
consumes the activity stream, they now have to figure out how to
present the location information to the user. If the author location
and story location are the same, and they show both locations it looks
like they're repeating themselves. If the locations are different and
they don't differentiate them somehow, it might not be clear why the
activity stream consumer has gone and shown a map of Chicago next to a
story about Tehran. Clearly, this is not an easy problem to solve,
but I think in the short term it might be a good idea to gently
encourage people not to make the work of the activity stream consumer
too hard by including more than one location in an entry.

-Bob

[Chris Messina]

On Tue, Dec 22, 2009 at 5:26 PM, Bob Aman <api.b...@gmail.com> wrote:

> Actually this comes up with news stories all the time.. and
> presumably blog posts given some way to communicate locations in a
> meaningful way.
>
> The format that I worked on with AP and Google News is set up to deal
> with this because location matters.... it was something that at first
> they didn't see the need for but for news.. you do need it.  Bylines
> and author location are often one place, and subject location is
> another.

Oh yeah, definitely.  But the "interesting" location there is the
story location, not the author location.  You could include the author
location, and it wouldn't be ambiguous, but for any application that
consumes the activity stream, they now have to figure out how to
present the location information to the user.  If the author location
and story location are the same, and they show both locations it looks
like they're repeating themselves.  If the locations are different and
they don't differentiate them somehow, it might not be clear why the
activity stream consumer has gone and shown a map of Chicago next to a
story about Tehran. 

Perhaps. But I think it's based on the consuming app's purpose.

If you're checking on your friends' status updates — their location is what interests you.

If you can see where your friends are right now on a map, that's also useful — especially if the app has aggregated their locations from many apps because the location data was provided.

However, when you go to look at the objects of the streams, that's when their location is the most interesting.

I get where you're coming from and what you're saying, and I'd be happy to see you write up a take on some guidelines for implementors. I'm for providing more information closer to the object being described and letting the client decide how to present the info — but you're right — if the client gets it wrong and does something weird — or a publisher misuses the location attribute — it could get messy.

Like I said, if you'd like to jot down some thoughts on the wiki, that'd be very useful.

Chris

[Kevin Marks]

Privacy is independent of format,  but the address structure is hierarchic so you could supply just the less exact parts to partially obfuscate ( just as you can round Geo points to lower precision)

On Dec 22, 2009 12:49 PM, "Bill de hOra" <bi...@dehora.net> wrote:

> Geographic coordinates can be included as a geo:point element

There should be room in the spec to allow privacy. geo:location makes no
allowances for this, poco is an addess which is a very specific
construct. Maybe AS should have its own element?

Bill

Monica Keller wrote: > Does anyone have a problem replacing > http://martin.atkins.me.uk/specs/acti...

[Monica Keller]

Agree with Kevin--> the publishers can select the level of granularity
by not including all the poco fields thus protecting the privacy of
the user.

Chris I like the idea of conveying location at the actor or object
level and not necessarily at the activity level.
Seems more straightforward. Bob even tho not all activities will have
both locations I think its valuable to distinguish whether the
location is for the object or the actor. Sounds like Mary has some
good examples of instances were both are used too.

At MySpace this is what we are doing so far:
In the real time stream api we provide the actors location down to the
city level
For events we put the location at the object level. In this case the
object is the event
The same should be done when reviewing venues (places)

Sylvain did you see this part of the spec which includes id, name and
uri for the venue
http://martin.atkins.me.uk/specs/activitystreams/activityschema#anchor15

I believe the only challenge left is how one would use this place
object type in lieu of poco:address or geo:point

Seems like we would need to create a new element to wrap the
properties of place.

Discussed this a bit with Martin but we didnt come to a conclusion
yet.
Should it be target ? context ? location?

Also do we want to address this for the 1st implementors draft ?

Thanks for the help guys

On Dec 22, 6:41 pm, Kevin Marks <kevinma...@gmail.com> wrote:
> Privacy is independent of format,  but the address structure is hierarchic
> so you could supply just the less exact parts to partially obfuscate ( just
> as you can round Geo points to lower precision)
>

[Rob Dolin]

I'm also +1 on supporting location data at the <author>/<activity:actor> level and the <activity:object>/<activity:target> level and not at the <entry> level.

I think a potentially common case is someone sitting at a computer and writing a review of a venue or composing an invitation to an event.

FWIW--
--Rob

--

[Bill de hOra]

> Privacy is independent of format,

I don't understand this- what do you mean?

> the address structure is
> hierarchic

Doesn't matter, it's still an address, which is a very specific
construct for a very general construct like an activity. Should all
activities imply an poco:address or a geo:location?

> so you could supply just the less exact parts to partially

Then it stops being an address and starts being a place. If
"poco:address" isn't simply an address and is designed to to describe a
place, then I'd understand how it can be used for AS.

Bill

Kevin Marks wrote:
> Privacy is independent of format, but the address structure is
> hierarchic so you could supply just the less exact parts to partially
> obfuscate ( just as you can round Geo points to lower precision)
>
>> On Dec 22, 2009 12:49 PM, "Bill de hOra" <bi...@dehora.net

>> <mailto:bi...@dehora.net>> wrote:
>>
>> > Geographic coordinates can be included as a geo:point element
>>
>> There should be room in the spec to allow privacy. geo:location makes no
>> allowances for this, poco is an addess which is a very specific
>> construct. Maybe AS should have its own element?
>>
>> Bill
>>
>> Monica Keller wrote: > Does anyone have a problem replacing >
>> http://martin.atkins.me.uk/specs/acti...
>>

[Kevin Marks]

On Wed, Dec 23, 2009 at 2:36 PM, Bill de hOra <bi...@dehora.net> wrote:

 > Privacy is independent of format,

I don't understand this- what do you mean?

I mean what Chris said, that what is disclosed to whom is the essence of privacy, not the format it is stored in; that is handled at the policy level, ie who gets what from the streams.

 
 > the address structure is
 > hierarchic

Doesn't matter, it's still an address, which is a very specific
construct for a very general construct like an activity. Should all
activities imply an poco:address or a geo:location?

no, it's optional. But ti is very useful. An address is the human-readable version of a geolocation, and it has implict and well understood fuzziness.

I'm at 800 W El Camino Real, Mountain View, CA 94041 USA

lets break that down:

streetAddress:

800 W El Camino Real

locality:

Mountain View.

region:

CA

postalCode:

94041

country:

USA

by omitting parts of this we can make this fuzzier, in  a way that is much clearer to people than truncating a geopoint.


 

 > so you could supply just the less exact parts to partially

Then it stops being an address and starts being a place. If
"poco:address" isn't simply an address and is designed to to describe a
place, then I'd understand how it can be used for AS.

yes, it's a place as the fields are optional. OpenSocial Address includes the lat/long fields too:

http://wiki.opensocial.org/index.php?title=Opensocial.Address_%28v0.9%29

which would make sense adding back to PoCo.

hCard/vcard likewise contains both adr and geo


To Sylvain's poitn about Venue IDs

I can see the case for some kind of feature ID, though I think expressing them as URLs is the best way, that can accommodate Yahoo WoeIDs,  Foursquare locations, google maps URLs or whatever.

eg http://where.yahooapis.com/v1/place/2347563 is california

http://foursquare.com/venue/62656 is my office

http://maps.google.com/places/us/mountain-view/w-el-camino-real/800/-ribbit-corporation

is Google's URL for it, and here's Upcoming's one for the Ooyala office downstairs:

http://upcoming.yahoo.com/venue/412217



 

[Martin Atkins]

On 12/22/2009 03:58 PM, Chris Messina wrote:
>
> entry
> - actor
> -- *location*
> - verb
> - object
> -- *location*
> - target/indirect object
>
[snip]

>
> Being able to distinguish between the actor's location and the object's
> location seems to me to be very valuable and important, and something
> that we can clarify over previous implementations.
>
> Thoughts?
>

I agree that the location where the actor was when the activity took
place and the location where the object is (or, more accurately, the
location of the real-world object that our digital artifact depicts or
represents) should be kept distinct.

However, I disagree that the right place to put this is inside the actor
object. In most implementations I would expect that actor object to be
produced from the *current state* of the actor at the time of feed
rendering, not from the state the actor had at the time the activity
took place. In other words, if I do something in Los Angeles but return
to San Francisco before you fetch my feed my actor object would tell you
that my current location is San Francisco even if you observe it in the
context of an activity that took place during my LA trip.

The activity:context element was devised to provide somewhere to put
this additional orthogonal context information about an activity, and I
think this design works well for the current use-cases. However, we
should be careful to define how locations are represented in such a way
that the same representation can be used both in the activity context
and inside an object that itself has a location.

One idea I discussed briefly with Monica yesterday was to define a new
"location" element which is the container for the various different
location properties we've used so far:

<somens:location>
<georss:blahblah>...</georss:blahblah>
<poco:something>...</poco:something>
....
</somens:location>

That element could be used either as a direct child of activity:context
inside an activity entry or as a direct child of an object element whose
type allows for a location.

Monica mentioned that when the location is actually something like a bar
or restaurant she'd like to actually refer to the real object that
describes that venue. To allow for this we can say that the content
model of somens:place can optionally be the content of an activity
streams place object, like this:

<somens:location>
<id>tag:blahblah.example.com,2009:venue-2342</id>
<title>Hotel Utah</title>
<activity:object-type>
http://activitystrea.ms/schema/1.0/place
</activity:object-type>
<georss:blahblah>...</georss:blahblah>
<poco:something>...</poco:something>
....
</somens:location>

So, to summarize, we'd use the georss and poco elements *only* as direct
children of the place object type. For other things which can have a
location associated with them, such as activity context, events and
photos, we'll use the somens:location element whose content is a place
object where the usual object-required properties of id, title,
publication time and permalink are optional. If they are not provided,
this is an "anonymous" location.

I think this approach rationalizes things somewhat, at the expense of
adding another container element. But the advantage here is that the
content of this new element can (in theory, at least) be processed using
the same code that would process a normal place object, assuming that an
implementation is able to deal with a place object that doesn't have an id.

My main concern is whether today's consumer code would need to be
drastically redesigned to support this idea of an anonymous object. I
know my toy consumer implementation can't deal with it as-is, but I have
a rough idea of what I'd change to make it work. Any thoughts from other
consumer implementors?

[Monica Keller]

1- For MySpace we are passing the hometown of the user inside actor
and I think this makes sense as we are already extending the actor
with poco fields for names and soon email so its natural to use the
address fields as well. This is valuable information in the public
real time stream as users do not necessarily know each other so this
provides more context.

2- Also if we do want to be explicit then we can allow location also
at the activity level. So I can say Im from SF but I was at MySpace HQ
in LA writing a review about a restaurant in Columbus, OH

I think *only* when describing the exact place where the action is
happening (which would be done at the activity level) do we need a
wrapping xml element like the proposed somens:location tag. Altho I
would just go for the activity namespace
activity:location will be an activity object with object type Place
residing at the atom:entry level

3- This allows you to always have a parser grab the geo or poco
address fields from within an activity object (because actor already
is)

For the first draft we can leave it as is allowing users to put geo
and poco fields on any activity:object whether its actor, main object,
target, etc and for the next version we can add this activity:location
similar to activity:target which describes the physical location of
the action only if different than the objects and needed to be
conveyed ?

> consumer implementors?- Hide quoted text -
>
> - Show quoted text -

[Chris Messina]

On Fri, Dec 25, 2009 at 11:23 PM, Monica Keller <monica...@gmail.com> wrote:

For the first draft we can leave it as is allowing users to put geo
and poco fields on any activity:object whether its actor, main object,
target, etc and for the next version we can add this activity:location
similar to activity:target which describes the physical location of
the action only if different than the objects and needed to be
conveyed ?

I would rather come up with the preferred, long-term approach and have that baked into 1.0 (which I would like to see finalized in Jan/Feb) than do something that appears interim but in the end is what sticks simply because people implement against it.

Providing "hometown" is somewhat different than the fields provided by PoCo, unfortunately. To me, "hometown" is the place that you associate with historically — like where you grew up — i.e. "Jenny from  the block" — rather than where you currently reside or are visiting temporarily.

PoCo does provide the "currentLocation" attribute from OpenSocial, which would be useful for the actor element in the case of defining where the ACTOR was at the time the activity was created (answering the question: "where was Johnny when he posted this photo?".

I wonder if we shouldn't amend PoCo to support "hometown" as an additional attribute — unless PoCo's address elements can take labels or tags (i.e. "home", "work", "hometown")?

I've updated the wiki page to flesh out the different "locations" that we're interested in.

http://activitystreams.pbworks.com/Location

. . .

Also: Martin, where did "somens:location" come from? Is there a precedent for that?

[Monica Keller]

Hmm hometown is the wrong term then it's the answer to the question where do you live ?

Users fill it as part of their profile info typical on most social sites

Also what I'm proposing would not go away long term you can use geo and poco to extend any object the only new thing we can introduce now or later is how to describe location of the activity if it cantbe conveyed via actor, object or target

Need a virtual whiteboard :) 

Monica 

--

[Martin Atkins]

Chris Messina wrote:
>
> Also: Martin, where did "somens:location" come from? Is there a
> precedent for that?
>

I invented it to give us a container in which we could nest a "place"
object. My goal was to be able to re-use the place object type for all
situations where a location is associated with something.