I just saw that we had the verb update defined on the spec but not on
the wiki so I have added it to the wiki, given that there is a
possibility we may be using it for real - time updates.
> I just saw that we had the verb update defined on the spec but not on
> the wiki so I have added it to the wiki, given that there is a
> possibility we may be using it for real - time updates.
> I just saw that we had the verb update defined on the spec but not on > the wiki so I have added it to the wiki, given that there is a > possibility we may be using it for real - time updates.
My initial reaction is that this seems a little too generic to be useful. Do we expect that consumers of this will know how to present any possible change to a user in a human-readable way?
I think this need highlights the fact that the way we think about activities doesn't work for cases where the interaction is not with a social object. The fact that you had to re-state the actor as the object indicates that this serialization is unnatural.
What you wanted to say here is "Peter changed his address". I think we should collect some specific examples and design a solution that models those well rather than jumping to the really generic solution you proposed.
Here are some real-world examples I can think of off the top of my head: * Changed my own userpic * Changed my own relationship * Changed the date/time/venue of an event.
What else?
I wonder if we should investigate whether a different data model would be better for representing these activities that do not follow the model "actor verbed object". In TypePad's internal data model we model "changed my own userpic" as a verb in its own right, but we don't currently surface that in Activity Streams because it doesn't fit the model. Facebook has more examples of this, with "was tagged in a photo", "is now married", etc... can you share a little about what these look like internally?
> On 07/27/2010 05:40 PM, Monica Keller wrote: >> I just saw that we had the verb update defined on the spec but not on >> the wiki so I have added it to the wiki, given that there is a >> possibility we may be using it for real - time updates.
> My initial reaction is that this seems a little too generic to be useful. Do we expect that consumers of this will know how to present any possible change to a user in a human-readable way?
The use case is data synchronization but I was also able to produce a human readable sentence thanks to the name field. Here is the template: {actor.displayName} updated {object.displayName}'s {change.name} to {change.value}
> I think this need highlights the fact that the way we think about activities doesn't work for cases where the interaction is not with a social object. The fact that you had to re-state the actor as the object indicates that this serialization is unnatural.
For data synchronization you would not need the social object. For human consumption it can be useful to provide context so a map can be rendered for example.
> What you wanted to say here is "Peter changed his address". I think we should collect some specific examples and design a solution that models those well rather than jumping to the really generic solution you proposed.
> Here are some real-world examples I can think of off the top of my head: > * Changed my own userpic > * Changed my own relationship > * Changed the date/time/venue of an event.
> What else?
I have a list of about 40 fields just for user. Ex: timezone preference, language preference, gender, birthday, name etc
> I wonder if we should investigate whether a different data model would be better for representing these activities that do not follow the model "actor verbed object". In TypePad's internal data model we model "changed my own userpic" as a verb in its own right, but we don't currently surface that in Activity Streams because it doesn't fit the model. Facebook has more examples of this, with "was tagged in a photo", "is now married", etc... can you share a little about what these look like internally?
Yes I was thinking about having a set of verbs specifically for data sync: update, delete and add (or we can reuse post) but it is a different use case. Update and delete don't necessarily need the full blown object
> -- > 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.
>> My initial reaction is that this seems a little too generic to be useful. Do we expect that consumers of this will know how to present any possible change to a user in a human-readable way? > The use case is data synchronization but I was also able to produce a human readable sentence thanks to the name field. > Here is the template: > {actor.displayName} updated {object.displayName}'s {change.name} to {change.value}
We've always said that activity streams is not a synchronization protocol, so this is surprising. I'm sure there's a more concise way you could serialize this if serialization is the primary use-case.
Your approach for forming a sentence suffers from the problem of building a sentence out of parts, which fails when change.name is not in the same language as the rest of the sentence. It would be weird if my aggregator told me that Monica updated Monica's nome.
>> I think this need highlights the fact that the way we think about activities doesn't work for cases where the interaction is not with a social object. The fact that you had to re-state the actor as the object indicates that this serialization is unnatural. > For data synchronization you would not need the social object. For human consumption it can be useful to provide context so a map can be rendered for example.
In your example the social object appeared to just be the actor again. You cheated by only provided a partial serialization of the actor and providing more details in the object, but that's asking consumers to make a leap of faith that the spec doesn't currently call for and merge the two objects together because they had the same id.
>> What you wanted to say here is "Peter changed his address". I think we should collect some specific examples and design a solution that models those well rather than jumping to the really generic solution you proposed.
>> Here are some real-world examples I can think of off the top of my head: >> * Changed my own userpic >> * Changed my own relationship >> * Changed the date/time/venue of an event.
>> What else? > I have a list of about 40 fields just for user. Ex: timezone preference, language preference, gender, birthday, name etc
Are all of these things really things that you'd expect to show in an activity stream? I'm doubtful that you'd syndicate "Martin is now in the PDT timezone instead of the GMT timezone!" as an activity, but maybe I'm wrong. It feels to me like this is just shoe-horning profile sync use-cases into activity streams, when that sort of thing would be much more naturally handled by a dedicated synchronization protocol.
>> I wonder if we should investigate whether a different data model would be better for representing these activities that do not follow the model "actor verbed object". In TypePad's internal data model we model "changed my own userpic" as a verb in its own right, but we don't currently surface that in Activity Streams because it doesn't fit the model. Facebook has more examples of this, with "was tagged in a photo", "is now married", etc... can you share a little about what these look like internally? > Yes I was thinking about having a set of verbs specifically for data sync: update, delete and add (or we can reuse post) but it is a different use case. Update and delete don't necessarily need the full blown object
My leaning is that data sync should be a different protocol entirely. The requirements are different and there doesn't seem to be much overlap between profile sync and our traditional definition of activities.
I think a more natural sync protocol would only contain the "change" component in your example along with the id of the thing that's being changed, and would not concern itself with all of the other activity streams stuff that is essentially noise to a sync client.
But with all of that said, there is definitely value in communicating via activity streams that certain things have changed. A new profile pic is a popular example that is important because it broadcasts that henceforth this person will be represented by a new icon. Similarly a person's name. But I would be pretty nonplussed if "Anna was now born on Apr 5 2010" or "Anna is now in the Mountain Timezone" appeared in the stream of activities from my friends; the first should never happen unless either the previous or the new birthdates were incorrect, and the latter is only interesting to software.
>>> My initial reaction is that this seems a little too generic to be useful. Do we expect that consumers of this will know how to present any possible change to a user in a human-readable way? >> The use case is data synchronization but I was also able to produce a human readable sentence thanks to the name field. >> Here is the template: >> {actor.displayName} updated {object.displayName}'s {change.name} to {change.value}
> We've always said that activity streams is not a synchronization protocol, so this is surprising. I'm sure there's a more concise way you could serialize this if serialization is the primary use-case.
It should not be surprising as I brought this use case up during our last spec editors meetup. The requirement of activity streams being for human consumption made more sense when we only looked at it as an extension of Atom. Now that we have a format which can easily model anything(json) we could use activity streams as a change log for synchronization. It appeared to me that others like StatusNet were looking at doing this. So this is a proposal for modeling updates to any resource as a feed using activity streams. On the conciseness aspect so many of the activity stream fields are optional that is not particularly extra verbose.
> Your approach for forming a sentence suffers from the problem of building a sentence out of parts, which fails when change.name is not in the same language as the rest of the sentence. It would be weird if my aggregator told me that Monica updated Monica's nome.
The consumer needs to request the appropriate language via the Accept-Language header. Its the same for body and title they will be syndicated in the appropriate language. change.name needs to be represented in the proper language
>>> I think this need highlights the fact that the way we think about activities doesn't work for cases where the interaction is not with a social object. The fact that you had to re-state the actor as the object indicates that this serialization is unnatural. >> For data synchronization you would not need the social object. For human consumption it can be useful to provide context so a map can be rendered for example.
> In your example the social object appeared to just be the actor again. You cheated by only provided a partial serialization of the actor and providing more details in the object, but that's asking consumers to make a leap of faith that the spec doesn't currently call for and merge the two objects together because they had the same id.
Yes in that case it was but it can be anything. I am not sure I follow your point of cheating. We do describe ids as the means to correlate social objects and publishers are open to provide as much detail as they want on social objects.
>>> What you wanted to say here is "Peter changed his address". I think we should collect some specific examples and design a solution that models those well rather than jumping to the really generic solution you proposed.
>>> Here are some real-world examples I can think of off the top of my head: >>> * Changed my own userpic >>> * Changed my own relationship >>> * Changed the date/time/venue of an event.
>>> What else? >> I have a list of about 40 fields just for user. Ex: timezone preference, language preference, gender, birthday, name etc
> Are all of these things really things that you'd expect to show in an activity stream? I'm doubtful that you'd syndicate "Martin is now in the PDT timezone instead of the GMT timezone!"
Right this is the data sync case
> as an activity, but maybe I'm wrong. It feels to me like this is just shoe-horning profile sync use-cases into activity streams, when that sort of thing would be much more naturally handled by a dedicated synchronization protocol.
That is the question for the community. Should we have update, delete and add verbs here which are used for a sync case or are we going to restrict to use only verbs and objects which are intended to be displayed as stories. I personally think that a dedicated sync protocol would end up looking very similar to activity streams in json. You need a timestamp, what changed and who did it. Its a feed. I think it would get confusing for publishers to pick a format in some scenarios if the 2 choices look pretty much the same.
>>> I wonder if we should investigate whether a different data model would be better for representing these activities that do not follow the model "actor verbed object". In TypePad's internal data model we model "changed my own userpic" as a verb in its own right, but we don't currently surface that in Activity Streams because it doesn't fit the model. Facebook has more examples of this, with "was tagged in a photo", "is now married", etc... can you share a little about what these look like internally? >> Yes I was thinking about having a set of verbs specifically for data sync: update, delete and add (or we can reuse post) but it is a different use case. Update and delete don't necessarily need the full blown object
> My leaning is that data sync should be a different protocol entirely. The requirements are different and there doesn't seem to be much overlap between profile sync and our traditional definition of activities.
Yes we can do it separate as well I just want to do that if and only if it really looks different. Also the update verb is already on the spec. I forgot who added it. Can someone post an example of how they were planning on using it ? All that I did was expand on how I think it could be used for data sync. Update by itself is very boring to humans on the stream. Ex: "Monica updated her profile" so the current spec needs a bit more info on how what actually changed.
> I think a more natural sync protocol would only contain the "change" component in your example along with the id of the thing that's being changed, and would not concern itself with all of the other activity streams stuff that is essentially noise to a sync client.
> But with all of that said, there is definitely value in communicating via activity streams that certain things have changed. A new profile pic is a popular example that is important because it broadcasts that henceforth this person will be represented by a new icon. Similarly a person's name. But I would be pretty nonplussed if "Anna was now born on Apr 5 2010" or "Anna is now in the Mountain Timezone" appeared in the stream of activities from my friends; the first should never happen unless either the previous or the new birthdates were incorrect, and the latter is only interesting to software.
Right that is why we have all the semantics so the consumer can decide what to surface but as stated above I was not proposing this for human consumption but for the data sync case. Thanks for reviewing !
> -- > 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.
The changes to profile elements can constitute interesting activities- the relationship update discussion makes that clear. The Open Social model for handling localization of the field names and values was to define them in English in a common vocabulary, and provide site specific mapping functions (which also handles the case of two sites having different names for the same field). For unenumerated fields, or extensions outside the enum, there may be some slight linguistic anomalies.
On Jul 27, 2010 10:46 PM, "Monica Keller" <monica.kel...@gmail.com> wrote:
On Jul 27, 2010, at 8:53 PM, Martin Atkins wrote:
> On 07/27/2010 06:15 PM, Monica Keller wrote: >...
It should not be surprising as I brought this use case up during our last spec editors meetup. The requirement of activity streams being for human consumption made more sense when we only looked at it as an extension of Atom. Now that we have a format which can easily model anything(json) we could use activity streams as a change log for synchronization. It appeared to me that others like StatusNet were looking at doing this. So this is a proposal for modeling updates to any resource as a feed using activity streams. On the conciseness aspect so many of the activity stream fields are optional that is not particularly extra verbose.
> Your approach for forming a sentence suffers from the problem of building
a sentence out of par... The consumer needs to request the appropriate language via the Accept-Language header. Its the same for body and title they will be syndicated in the appropriate language. change.name needs to be represented in the proper language
>>> I think this need highlights the fact that the way we think about
activities doesn't wor... Yes in that case it was but it can be anything. I am not sure I follow your point of cheating. We do describe ids as the means to correlate social objects and publishers are open to provide as much detail as they want on social objects.
>>> What you wanted to say here is "Peter changed his address". I think we
should collect s... Right this is the data sync case
> as an activity, but maybe I'm wrong. It feels to me like this is just
shoe-horning profile sync u... That is the question for the community. Should we have update, delete and add verbs here which are used for a sync case or are we going to restrict to use only verbs and objects which are intended to be displayed as stories. I personally think that a dedicated sync protocol would end up looking very similar to activity streams in json. You need a timestamp, what changed and who did it. Its a feed. I think it would get confusing for publishers to pick a format in some scenarios if the 2 choices look pretty much the same.
>>> I wonder if we should investigate whether a different data model would
be better for rep... Yes we can do it separate as well I just want to do that if and only if it really looks different. Also the update verb is already on the spec. I forgot who added it. Can someone post an example of how they were planning on using it ? All that I did was expand on how I think it could be used for data sync. Update by itself is very boring to humans on the stream. Ex: "Monica updated her profile" so the current spec needs a bit more info on how what actually changed.
> I think a more natural sync protocol would only contain the "change"
component in your example... Right that is why we have all the semantics so the consumer can decide what to surface but as stated above I was not proposing this for human consumption but for the data sync case. Thanks for reviewing !
> -- > You received this message because you are subscribed to the Google Groups
On Jul 27, 11:28 pm, Kevin Marks <kevinma...@gmail.com> wrote:
> The changes to profile elements can constitute interesting activities- the
> relationship update discussion makes that clear.
Yes
> The Open Social model for handling localization of the field names and
> values was to define them in English in a common vocabulary, and provide
> site specific mapping functions (which also handles the case of two sites
> having different names for the same field).
> For unenumerated fields, or extensions outside the enum, there may be some
> slight linguistic anomalies.
Yes so I was using the value ref to act as the enum as seen here:
> It should not be surprising as I brought this use case up during our last
> spec editors meetup.
> The requirement of activity streams being for human consumption made more
> sense when we only looked at it as an extension of Atom.
> Now that we have a format which can easily model anything(json) we could use
> activity streams as a change log for synchronization.
> It appeared to me that others like StatusNet were looking at doing this. So
> this is a proposal for modeling updates to any resource as a feed using
> activity streams.
> On the conciseness aspect so many of the activity stream fields are optional
> that is not particularly extra verbose.
> > Your approach for forming a sentence suffers from the problem of building
> a sentence out of par...
> The consumer needs to request the appropriate language via the
> Accept-Language header.
> Its the same for body and title they will be syndicated in the appropriate
> language. change.name needs to be represented in the proper language
> >>> I think this need highlights the fact that the way we think about
> activities doesn't wor...
> Yes in that case it was but it can be anything. I am not sure I follow your
> point of cheating. We do describe ids as the means to correlate social
> objects and publishers are open to provide as much detail as they want on
> social objects.
> >>> What you wanted to say here is "Peter changed his address". I think we
> should collect s...
> Right this is the data sync case
> > as an activity, but maybe I'm wrong. It feels to me like this is just
> shoe-horning profile sync u...
> That is the question for the community. Should we have update, delete and
> add verbs here which are used for a sync case or are we going to restrict to
> use only verbs and objects which are intended to be displayed as stories.
> I personally think that a dedicated sync protocol would end up looking very
> similar to activity streams in json. You need a timestamp, what changed and
> who did it. Its a feed. I think it would get confusing for publishers to
> pick a format in some scenarios if the 2 choices look pretty much the same.
> >>> I wonder if we should investigate whether a different data model would
> be better for rep...
> Yes we can do it separate as well I just want to do that if and only if it
> really looks different. Also the update verb is already on the spec. I
> forgot who added it. Can someone post an example of how they were planning
> on using it ?
> All that I did was expand on how I think it could be used for data sync.
> Update by itself is very boring to humans on the stream. Ex: "Monica
> updated her profile" so the current spec needs a bit more info on how what
> actually changed.
> > I think a more natural sync protocol would only contain the "change"
> component in your example...
> Right that is why we have all the semantics so the consumer can decide what
> to surface but as stated above I was not proposing this for human
> consumption but for the data sync case.
> Thanks for reviewing !
> > --
> > You received this message because you are subscribed to the Google Groups
> On Jul 27, 11:28 pm, Kevin Marks <kevinma...@gmail.com> wrote:> The changes to profile elements can constitute interesting activities- the
> > relationship update discussion makes that clear.
> Yes
> > The Open Social model for handling localization of the field names and
> > values was to define them in English in a common vocabulary, and provide
> > site specific mapping functions (which also handles the case of two sites
> > having different names for the same field).
> > For unenumerated fields, or extensions outside the enum, there may be some
> > slight linguistic anomalies.
> Yes so I was using the value ref to act as the enum as seen here:
> > It should not be surprising as I brought this use case up during our last
> > spec editors meetup.
> > The requirement of activity streams being for human consumption made more
> > sense when we only looked at it as an extension of Atom.
> > Now that we have a format which can easily model anything(json) we could use
> > activity streams as a change log for synchronization.
> > It appeared to me that others like StatusNet were looking at doing this. So
> > this is a proposal for modeling updates to any resource as a feed using
> > activity streams.
> > On the conciseness aspect so many of the activity stream fields are optional
> > that is not particularly extra verbose.
> > > Your approach for forming a sentence suffers from the problem of building
> > a sentence out of par...
> > The consumer needs to request the appropriate language via the
> > Accept-Language header.
> > Its the same for body and title they will be syndicated in the appropriate
> > language. change.name needs to be represented in the proper language
> > >>> I think this need highlights the fact that the way we think about
> > activities doesn't wor...
> > Yes in that case it was but it can be anything. I am not sure I follow your
> > point of cheating. We do describe ids as the means to correlate social
> > objects and publishers are open to provide as much detail as they want on
> > social objects.
> > >>> What you wanted to say here is "Peter changed his address". I think we
> > should collect s...
> > Right this is the data sync case
> > > as an activity, but maybe I'm wrong. It feels to me like this is just
> > shoe-horning profile sync u...
> > That is the question for the community. Should we have update, delete and
> > add verbs here which are used for a sync case or are we going to restrict to
> > use only verbs and objects which are intended to be displayed as stories.
> > I personally think that a dedicated sync protocol would end up looking very
> > similar to activity streams in json. You need a timestamp, what changed and
> > who did it. Its a feed. I think it would get confusing for publishers to
> > pick a format in some scenarios if the 2 choices look pretty much the same.
> > >>> I wonder if we should investigate whether a different data model would
> > be better for rep...
> > Yes we can do it separate as well I just want to do that if and only if it
> > really looks different. Also the update verb is already on the spec. I
> > forgot who added it. Can someone post an example of how they were planning
> > on using it ?
> > All that I did was expand on how I think it could be used for data sync.
> > Update by itself is very boring to humans on the stream. Ex: "Monica
> > updated her profile" so the current spec needs a bit more info on how what
> > actually changed.
> > > I think a more natural sync protocol would only contain the "change"
> > component in your example...
> > Right that is why we have all the semantics so the consumer can decide what
> > to surface but as stated above I was not proposing this for human
> > consumption but for the data sync case.
> > Thanks for reviewing !
> > > --
> > > You received this message because you are subscribed to the Google Groups
Right parsing is separate from display.
The application logic for parsing can be very specific or more
generic. The proposal for the verb update I am presenting leans
towards providing generic parsing. At display time the consumer can do
whatever they want and key on each property to add targeting,
relevance, change the display icon, etc
On Aug 2, 12:20 pm, Adina Levin <aldeivn...@gmail.com> wrote:
> Mapping is orthogonal to deciding what to show, yes?
> There is and I think always will be app-level logic about what actions
> to show, using reasoning that is social not mathematical.
> For example, Facebook doesn't show "defriending" in the stream even
> though they logically could.
> On Aug 2, 11:06 am, Monica Keller <monica.kel...@gmail.com> wrote:
> > On Jul 27, 11:28 pm, Kevin Marks <kevinma...@gmail.com> wrote:> The changes to profile elements can constitute interesting activities- the
> > > relationship update discussion makes that clear.
> > Yes
> > > The Open Social model for handling localization of the field names and
> > > values was to define them in English in a common vocabulary, and provide
> > > site specific mapping functions (which also handles the case of two sites
> > > having different names for the same field).
> > > For unenumerated fields, or extensions outside the enum, there may be some
> > > slight linguistic anomalies.
> > Yes so I was using the value ref to act as the enum as seen here:
> > > It should not be surprising as I brought this use case up during our last
> > > spec editors meetup.
> > > The requirement of activity streams being for human consumption made more
> > > sense when we only looked at it as an extension of Atom.
> > > Now that we have a format which can easily model anything(json) we could use
> > > activity streams as a change log for synchronization.
> > > It appeared to me that others like StatusNet were looking at doing this. So
> > > this is a proposal for modeling updates to any resource as a feed using
> > > activity streams.
> > > On the conciseness aspect so many of the activity stream fields are optional
> > > that is not particularly extra verbose.
> > > > Your approach for forming a sentence suffers from the problem of building
> > > a sentence out of par...
> > > The consumer needs to request the appropriate language via the
> > > Accept-Language header.
> > > Its the same for body and title they will be syndicated in the appropriate
> > > language. change.name needs to be represented in the proper language
> > > >>> I think this need highlights the fact that the way we think about
> > > activities doesn't wor...
> > > Yes in that case it was but it can be anything. I am not sure I follow your
> > > point of cheating. We do describe ids as the means to correlate social
> > > objects and publishers are open to provide as much detail as they want on
> > > social objects.
> > > >>> What you wanted to say here is "Peter changed his address". I think we
> > > should collect s...
> > > Right this is the data sync case
> > > > as an activity, but maybe I'm wrong. It feels to me like this is just
> > > shoe-horning profile sync u...
> > > That is the question for the community. Should we have update, delete and
> > > add verbs here which are used for a sync case or are we going to restrict to
> > > use only verbs and objects which are intended to be displayed as stories.
> > > I personally think that a dedicated sync protocol would end up looking very
> > > similar to activity streams in json. You need a timestamp, what changed and
> > > who did it. Its a feed. I think it would get confusing for publishers to
> > > pick a format in some scenarios if the 2 choices look pretty much the same.
> > > >>> I wonder if we should investigate whether a different data model would
> > > be better for rep...
> > > Yes we can do it separate as well I just want to do that if and only if it
> > > really looks different. Also the update verb is already on the spec. I
> > > forgot who added it. Can someone post an example of how they were planning
> > > on using it ?
> > > All that I did was expand on how I think it could be used for data sync.
> > > Update by itself is very boring to humans on the stream. Ex: "Monica
> > > updated her profile" so the current spec needs a bit more info on how what
> > > actually changed.
> > > > I think a more natural sync protocol would only contain the "change"
> > > component in your example...
> > > Right that is why we have all the semantics so the consumer can decide what
> > > to surface but as stated above I was not proposing this for human
> > > consumption but for the data sync case.
> > > Thanks for reviewing !
> > > > --
> > > > You received this message because you are subscribed to the Google Groups
