Update verb review
Monica Keller
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.
https://wiki.activitystrea.ms/Update
Here is an example of an update activity using dot fragment resolution
from json-schema. Its optional the new value can be inlined.
{
"actor" : {"id":1212, "displayName" : "Peter"}
"verb" : "update",
{
"change" :
{"name" : "street address"},
{"value" : {"$ref": #object.streetAddress}
}
"object" : {
"id": 12121,
"displayName" : "Peter's House",
"streetAddress" : "234 Amazing St",
"city" : "San Francisco",
"state" : "California"
}
}
Thoughts on having a change construct ?
Monica Keller
{
"actor" : {"id":1212, "displayName" : "Peter"},
"change" :
{
"name" : "street address",
"value" : {"$ref": "#object.streetAddress"}
Martin Atkins
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?
Monica Keller
On Jul 27, 2010, at 5:50 PM, Martin Atkins wrote:
> 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.
>>
>> https://wiki.activitystrea.ms/Update
>>
>> Here is an example of an update activity using dot fragment resolution
>> from json-schema. Its optional the new value can be inlined.
>>
>> {
>> "actor" : {"id":1212, "displayName" : "Peter"}
>> "verb" : "update",
>> {
>> "change" :
>> {"name" : "street address"},
>> {"value" : {"$ref": #object.streetAddress}
>> }
>> "object" : {
>> "id": 12121,
>> "displayName" : "Peter's House",
>> "streetAddress" : "234 Amazing St",
>> "city" : "San Francisco",
>> "state" : "California"
>> }
>> }
>>
>> Thoughts on having a change construct ?
>>
>
> 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
{
"actor" : {"id":1212, "displayName" : "Peter"},
"verb" : "update",
"change" :
{
"name" : "street address",
"value" : "234 Awesome St"
}
}
and
{
"actor" : {"id":1212, "displayName" : "Peter"},
"verb" :"delete",
"object" : {"id":23232}
}
Altho this could be
{
"actor" : {"id":1212, "displayName" : "Peter"},
"deleted" : 23232
}
If its absolutely certain it will not be rendered. Thoughts ?
>
> --
> 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.
>
Martin Atkins
>
>>
>> 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.
Monica Keller
On Jul 27, 2010, at 8:53 PM, Martin Atkins wrote:
> On 07/27/2010 06:15 PM, Monica Keller wrote:
>>
>>>
>>> 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 !
Kevin Marks
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...@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 "Activity...
Monica Keller
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.
> 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.
{
"verb" : "update",
"change" :
{
"value" : {"$ref": "#object.relationship.status"}
},
"object" : {
"displayName" : "Peter",
"relationship" : {
"status" : "married",
"to" : {"id":"878787", "displayName" : "Sally", "type" :
"person"}
}
}
}
Using labels would be:
{
"actor" : {"id":1212, "displayName" : "Peter"},
"change" : "relationship-status",
"object" : {
"displayName" : "Peter",
"relationship" : {
"status" : "married",
"to" : {"id":"878787", "displayName" : "Sally", "type" :
"person"}
}
}
}
Which seems harder for consumers as they would need to do their own
mapping of label name to location in object.
Unless we just did
{
"verb" : "update",
"value" : "married"
}
Which is leaner but assumes the consumer already has the remaining
properties which allow them to correlate the info
Adina Levin
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.
Monica Keller
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