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 dont 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.
> 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 dont 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.
> You received this message because you are subscribed to the Google Groups > "Activity Streams" group. > To post to this group, send email to activity-streams@googlegroups.com. > To unsubscribe from this group, send email to > activity-streams+unsubscribe@googlegroups.com<activity-streams%2Bunsubscrib e@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/activity-streams?hl=en.
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.
> > 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 dont 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.
> > You received this message because you are subscribed to the Google Groups > > "Activity Streams" group. > > To post to this group, send email to activity-streams@googlegroups.com. > > To unsubscribe from this group, send email to > > activity-streams+unsubscribe@googlegroups.com<activity-streams%2Bunsubscrib e@googlegroups.com> > > . > > For more options, visit this group at > >http://groups.google.com/group/activity-streams?hl=en.
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)
On Tue, Dec 22, 2009 at 11:55 AM, Chris Messina <chris.mess...@gmail.com>wrote:
>> 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 dont 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.
>> You received this message because you are subscribed to the Google Groups >> "Activity Streams" group. >> To post to this group, send email to activity-streams@googlegroups.com. >> To unsubscribe from this group, send email to >> activity-streams+unsubscribe@googlegroups.com<activity-streams%2Bunsubscrib e@googlegroups.com> >> . >> For more options, visit this group at >> http://groups.google.com/group/activity-streams?hl=en.
> This email is: [ ] shareable [X] ask first [ ] private
> -- > You received this message because you are subscribed to the Google Groups > "Activity Streams" group. > To post to this group, send email to activity-streams@googlegroups.com. > To unsubscribe from this group, send email to > activity-streams+unsubscribe@googlegroups.com<activity-streams%2Bunsubscrib e@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/activity-streams?hl=en.
> 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.
> 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?
> 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.
> You received this message because you are subscribed to the Google Groups "Activity Streams" group. > To post to this group, send email to activity-streams@googlegroups.com. > To unsubscribe from this group, send email to activity-streams+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/activity-streams?hl=en.
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
On Tue, Dec 22, 2009 at 12:49 PM, Bill de hOra <b...@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?
> > 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 dont 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.
> > You received this message because you are subscribed to the Google Groups > "Activity Streams" group. > > To post to this group, send email to activity-streams@googlegroups.com. > > To unsubscribe from this group, send email to > activity-streams+unsubscribe@googlegroups.com<activity-streams%2Bunsubscrib e@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-streams@googlegroups.com. > To unsubscribe from this group, send email to > activity-streams+unsubscribe@googlegroups.com<activity-streams%2Bunsubscrib e@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/activity-streams?hl=en.
On Tue, Dec 22, 2009 at 12:20 PM, Martin Atkins <m...@degeneration.co.uk>wrote:
> 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.
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...
"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.
> "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.
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.
>> "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
> --
> You received this message because you are subscribed to the Google > Groups "Activity Streams" group. > To post to this group, send email to activity- > streams@googlegroups.com. > To unsubscribe from this group, send email to activity-streams > +unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/ > group/activity-streams?hl=en.
On Tue, Dec 22, 2009 at 4:22 PM, Bob Aman <api.boba...@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!
> 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.
On Tue, Dec 22, 2009 at 5:26 PM, Bob Aman <api.boba...@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.
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" <b...@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 >
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)
> 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" <b...@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 >
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.
-----Original Message----- From: activity-streams@googlegroups.com [mailto:activity-streams@googlegroups.com] On Behalf Of Monica Keller Sent: Tuesday, December 22, 2009 9:16 PM To: Activity Streams Subject: Re: Conveying location
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)
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)
> On Dec 22, 2009 12:49 PM, "Bill de hOra" <b...@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 >
You received this message because you are subscribed to the Google Groups "Activity Streams" group. To post to this group, send email to activity-streams@googlegroups.com. To unsubscribe from this group, send email to activity-streams+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/activity-streams?hl=en.
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.
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" <b...@dehora.net >> <mailto:b...@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?
> You received this message because you are subscribed to the Google > Groups "Activity Streams" group. > To post to this group, send email to activity-streams@googlegroups.com. > To unsubscribe from this group, send email to > activity-streams+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/activity-streams?hl=en.
On Wed, Dec 23, 2009 at 2:36 PM, Bill de hOra <b...@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 Reallocality: Mountain View. region: CA postalCode: 94041country: 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:
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.
> 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" <b...@dehora.net > >> <mailto:b...@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?
> 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:
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:
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?
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 ?
On Dec 23, 5:20 pm, Martin Atkins <m...@degeneration.co.uk> wrote:
> 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:
> 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:
> 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?- Hide quoted text -
On Fri, Dec 25, 2009 at 11:23 PM, Monica Keller <monica.kel...@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.
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
On Dec 26, 2009, at 12:19 PM, Chris Messina <chris.mess...@gmail.com> wrote:
> On Fri, Dec 25, 2009 at 11:23 PM, Monica Keller <monica.kel...@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 label > s or tags (i.e. "home", "work", "hometown")?
> I've updated the wiki page to flesh out the different "locations" > that we're interested in.
> This email is: [ ] shareable [X] ask first [ ] private > --
> You received this message because you are subscribed to the Google > Groups "Activity Streams" group. > To post to this group, send email to activity- > streams@googlegroups.com. > To unsubscribe from this group, send email to activity-streams+unsubscribe@googlegroups.com > . > For more options, visit this group at http://groups.google.com/group/activity-streams?hl=en > .
> 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.
