Special case objectType's
James Snell
identifiers such as @me, @public, @all, @viewer, @owner, etc that
represent a variety of specific, well-known types of objects. What
currently does not exist, however, is a standardized way of
representing those within an Activity Stream document.. for instance,
if I wanted to indicate that the audience of a particular event is
@public... What I propose is that for these special case types of
objects, we utilize the convention of specifying the @value as the
objectType, for instance...
{
"to":[{"objectType":"@public"}],
"cc":[{"objectType":"@network"}]
}
To identify subsets of these, we can differentiate based on the "id"
property.. for instance, a service that offers identified groups of
friends (e.g. Google+ circles,etc), we could use the following
convention:
{"objectType":"@friends"} <== identifying ALL of my friends
{"objectType":"@friends","id":"urn:whatever:colleagues"} <==
references the subset of friends identified as "colleagues"
{"objectType":"@friends","id":"urn:whatever:family"} <== references
the subset of friends identified as "family" ,
... and so forth
Thoughts?
- James
Martin Atkins
Seems weird to overload objectType for this. Feels more natural to
define conventions for the "id" property since it seems like you are
trying to identify specific objects rather than classes of objects.
James Snell
Using something like id:@friends would work conceptually, but it falls down a bit when attempting to reference specific subgroups and there's the restriction that id MUST be an absolute IRI, requiring us to come up with some artificial uri scheme for these that just isn't necessary. Truthfully, I don't see the @values as being out of place in the object type.
--
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.
Martin Atkins
> Using something like id:@friends would work conceptually, but it falls
> down a bit when attempting to reference specific subgroups and there's
> the restriction that id MUST be an absolute IRI, requiring us to come up
> with some artificial uri scheme for these that just isn't necessary.
> Truthfully, I don't see the @values as being out of place in the object
> type.
>
I'm afraid I don't really understand how objectType is the right place
for this.
Object type is for defining class membership. "person" is a class, but
@me is a member of that class, not a class itself.
Likewise @all seems to me like a member of the class "group", although I
must admit I'm not sure from its name what the types of the members of
the group are.
There is the further problem that a lot of these seem to have an implied
"self" attached to them: "me", "MY friends", "MY family" but it's not
clear to me how a consumer is supposed to know who "me" is.
I think perhaps I'm just not seeing the end-to-end use-case here. Can
you elaborate about what these things are for? Maybe I'm just missing a
crucial detail.
James Snell
> On 11/14/2011 06:22 PM, James Snell wrote:
>>
>> Using something like id:@friends would work conceptually, but it falls
>> down a bit when attempting to reference specific subgroups and there's
>> the restriction that id MUST be an absolute IRI, requiring us to come up
>> with some artificial uri scheme for these that just isn't necessary.
>> Truthfully, I don't see the @values as being out of place in the object
>> type.
>>
>
> I'm afraid I don't really understand how objectType is the right place for
> this.
>
> Object type is for defining class membership. "person" is a class, but @me
> is a member of that class, not a class itself.
>
Well see this is what I struggled with too. Putting it in id doesn't
work very well either.. for instance, consider the example of wanting
to identify a subset of your @friends...
The way I've envisioned it, the @values are generally subclasses of
group, not members...
@me describes a group in which I am the only member
@friends describes a group that includes others that are directly
connected to me.
@all describes a group that includes everyone within a given context
In the case of @friends, there could be multiple subgroups each with
their own distinct identity (e.g. Google+'s All Circles vs. and
individual circle)
> Likewise @all seems to me like a member of the class "group", although I
> must admit I'm not sure from its name what the types of the members of the
> group are.
>
> There is the further problem that a lot of these seem to have an implied
> "self" attached to them: "me", "MY friends", "MY family" but it's not clear
> to me how a consumer is supposed to know who "me" is.
It's entirely based on the context of the operation. In OpenSocial,
for instance, @self and @me in a URI is mapped to the authenticated
user. That would be the case here as well... if I post a activity to
an endpoint that contains actor:{"objectType":"@me"} and I'm
authenticated, the endpoint would be expected to map my authenticated
identity as the actor. Likewise if the posted activity includes
"to":[{"objectType":"@network"}].. I'm telling the server that the
activity is targeted at anyone in my extended network without having
to call everyone out explicitly.
>
> I think perhaps I'm just not seeing the end-to-end use-case here. Can you
> elaborate about what these things are for? Maybe I'm just missing a crucial
> detail.
>
The primary use case for these is going to be audience targeting (used
with the to, bto, cc and bcc fields). There are other uses, of course,
but that one is the biggie.
Oh, and I would be open to using id if that's the right approach, but
it's just not a natural fit given that id requires a fully qualified
IRI and it doesn't address the problem of identifying subgroups... I'd
rather not have to deal with coming up with a URI syntax for this.
>
>
> --
> 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.
Martin Atkins
>
> Oh, and I would be open to using id if that's the right approach, but
> it's just not a natural fit given that id requires a fully qualified
> IRI and it doesn't address the problem of identifying subgroups... I'd
> rather not have to deal with coming up with a URI syntax for this.
>
I think I now understand your use-case better. I'd think of this as a
placeholder mechanism for referring to contextual objects:
* The author of this activity is the person object representing myself.
* The audience of this activity is the group object representing my
co-workers.
I would add a further use-case that seems to fit here, and is a new
solution to a problem I grappled with while trying to figure out how to
differentiate replies and reactions in Salmon-like workflows:
* The inReplyTo of this object is the object whose reactions endpoint
I'm submitting this to.
* The object of this activity is the object whose reactions endpoint I'm
submitting this to.
For example, (with pseudo-syntax so we don't get distracted by
serialization while we're defining the problem)
{
"verb": "post",
"actor": (the object representing me),
"object": {
"objectType": "comment",
"content": "That's awesome!",
"inReplyTo": (the object representing what I'm reacting to),
},
}
{
"verb": "share",
"actor": (the object representing me),
"object": (the object representing what I'm reacting to),
}
------
To me this seems like a new syntax element rather than a change to the
data model: we're providing a way to refer to objects by reference
rather than by value, and specifically to objects that are already known
by the consumer by context and so don't need to be included in the
stream at all.
My modest proposal is to just replace the entire object with a string
using your microsyntax, and call these things "object aliases":
"actor": "@me"
"to": [ "@friends" ]
This is a breaking change to syntax, but since this feature can only be
used when the producer and consumer share a common understanding of
these names an existing deployed consumer will never encounter this
syntax and so will not be broken.
I would then generalize this by saying that protocols built on Activity
Streams (of which OpenSocial is one example, and Salmon reactions could
be another example) can define in their protocol specification which
object aliases are available in a given context and what they mean.
Consumers implementing protocols that define object aliases can then
check if what they were given is a string or an object and react
appropriately.
------
Some time ago we'd discussed the possibility of doing something similar
as a compression technique where a top-level dictionary of keys maps to
objects that can be included by reference anywhere in the stream.
However, I still agree with the outcome of that discussion: this sort of
intra-stream redundancy is better dealt with by compression in a higher
layer, such as gzipping the data. Therefore I don't think we should aim
to solve for this with the mechanism I described above.
James Snell
I think there's even less value in trying to override the values types of core properties. That's a nonstarter for me. If anything, I can imagine a new extension property for this... Perhaps a "objectId" field that is distinct from "id" in that it provides a kind of static identifier for the class as opposed to an instance id. The value would be expected to be either a token or an absolute uri. E.g. "objectId":"@friends"... Achieves the goal and maintains compatibility.
Martin Atkins
> I think there's even less value in trying to override the values types
> of core properties. That's a nonstarter for me. If anything, I can
> imagine a new extension property for this... Perhaps a "objectId" field
> that is distinct from "id" in that it provides a kind of static
> identifier for the class as opposed to an instance id. The value would
> be expected to be either a token or an absolute uri. E.g.
> "objectId":"@friends"... Achieves the goal and maintains compatibility.
>
I'm curious to understand your objection to mixed type properties. It
seems pretty clean to me to just replace the whole object with a
placeholder, rather than a weird setup where you replace the whole
object with another object that just has a single property inside it.
Your proposal creates the syntactic possibility for muddled objects that
are both aliases and objects themselves, which just seems confusing to me.
I don't like the name "objectId" because it's too similar to "id".
Perhaps instead "aliasKey", which for now is defined only as an at sign
followed by a contextually-defined token name. Let's reserve judgement
on other possible values for this field until we have some real
use-cases; it's not clear to me why you'd put an absolute URI in here,
so I'd prefer not to allow it until we understand what it means.
James Snell
> On 11/16/2011 08:32 AM, James Snell wrote:
>>
>> I think there's even less value in trying to override the values types
>> of core properties. That's a nonstarter for me. If anything, I can
>> imagine a new extension property for this... Perhaps a "objectId" field
>> that is distinct from "id" in that it provides a kind of static
>> identifier for the class as opposed to an instance id. The value would
>> be expected to be either a token or an absolute uri. E.g.
>> "objectId":"@friends"... Achieves the goal and maintains compatibility.
>>
>
> I'm curious to understand your objection to mixed type properties. It seems
> pretty clean to me to just replace the whole object with a placeholder,
> rather than a weird setup where you replace the whole object with another
> object that just has a single property inside it.
>
Well, I'm definitely not a fan of breaking backwards compatibility for
an optional extension when we can easily fit this into the existing
model without breaking anything. The other part is, while the majority
of use cases would have just a single property, I've already
identified one that would have more than one property... that of
identifying a subgroup of @friends, e.g.
{"objectId":"@friends","id":"family"}.
> Your proposal creates the syntactic possibility for muddled objects that are
> both aliases and objects themselves, which just seems confusing to me.
>
Honestly, I don't see this as a problem.. consider, if I said,
{"objectId":"@me","id":"acct:jas...@us.ibm.com"} ... what is being
stated is very clear and unambiguous... this object represents me and
my specific identifier is "acct:jas...@us.ibm.com". There's nothing
muddled about that. A major point is it's not yet clear whether there
will be a need for additional properties or not but we do have a solid
use case already (the @friends example) where at least one additional
property is necessary. Keeping the values as objects and using
properties on those objects not only preserves backwards compatibility
by not requiring us to special case the basic spec requirements, it
maintains the already inherent extensibility and flexibility of spec
without artificially and prematurely restricting the possible
extension options.
> I don't like the name "objectId" because it's too similar to "id". Perhaps
> instead "aliasKey", which for now is defined only as an at sign followed by
> a contextually-defined token name. Let's reserve judgement on other possible
> values for this field until we have some real use-cases; it's not clear to
> me why you'd put an absolute URI in here, so I'd prefer not to allow it
> until we understand what it means.
>
Perhaps just "alias":"@value" and we keep the value spec as just a
string with no restrictions?
- James
Martin Atkins
>
> Well, I'm definitely not a fan of breaking backwards compatibility for
> an optional extension when we can easily fit this into the existing
> model without breaking anything. The other part is, while the majority
> of use cases would have just a single property, I've already
> identified one that would have more than one property... that of
> identifying a subgroup of @friends, e.g.
> {"objectId":"@friends","id":"family"}.
>
Why not just "@family"? I guess this is an OpenSocial feature I'm not
too familiar with.
I'm also not too convinced by the compatibility argument since all of
the use-cases we've explored so far are useless without support for this
feature, and therefore there ought to be zero overlap between existing
implementations that don't use this feature and new implementations that do.
>> Your proposal creates the syntactic possibility for muddled objects that are
>> both aliases and objects themselves, which just seems confusing to me.
>>
>
> Honestly, I don't see this as a problem.. consider, if I said,
>
> {"objectId":"@me","id":"acct:jas...@us.ibm.com"} ... what is being
> stated is very clear and unambiguous... this object represents me and
> my specific identifier is "acct:jas...@us.ibm.com". There's nothing
> muddled about that. A major point is it's not yet clear whether there
> will be a need for additional properties or not but we do have a solid
> use case already (the @friends example) where at least one additional
> property is necessary. Keeping the values as objects and using
> properties on those objects not only preserves backwards compatibility
> by not requiring us to special case the basic spec requirements, it
> maintains the already inherent extensibility and flexibility of spec
> without artificially and prematurely restricting the possible
> extension options.
If we go this route then I would want to define completely the correct
behavior for merging the data from the "alias" with the data from its
referent; this could be as simple as just "replace the whole object with
the referent and ignore all of the other properties", but then it's not
clear to me what the purpose of the other properties in the alias would be.
>> I don't like the name "objectId" because it's too similar to "id". Perhaps
>> instead "aliasKey", which for now is defined only as an at sign followed by
>> a contextually-defined token name. Let's reserve judgement on other possible
>> values for this field until we have some real use-cases; it's not clear to
>> me why you'd put an absolute URI in here, so I'd prefer not to allow it
>> until we understand what it means.
>>
>
> Perhaps just "alias":"@value" and we keep the value spec as just a
> string with no restrictions?
>
Fine by me.
James Snell
On Nov 16, 2011 10:37 AM, "Martin Atkins" <ma...@degeneration.co.uk> wrote:
>
> On 11/16/2011 09:52 AM, James Snell wrote:
>>
>>
>> Well, I'm definitely not a fan of breaking backwards compatibility for
>> an optional extension when we can easily fit this into the existing
>> model without breaking anything. The other part is, while the majority
>> of use cases would have just a single property, I've already
>> identified one that would have more than one property... that of
>> identifying a subgroup of @friends, e.g.
>> {"objectId":"@friends","id":"family"}.
>>
>
> Why not just "@family"? I guess this is an OpenSocial feature I'm not too familiar with.
>
The subgroups are arbitrarily named typically... Example would be individual circles but there, of course you have the argument that an alias is not required if you can identify the subgroup directly.
> I'm also not too convinced by the compatibility argument since all of the use-cases we've explored so far are useless without support for this feature, and therefore there ought to be zero overlap between existing implementations that don't use this feature and new implementations that do.
>
>
>>> Your proposal creates the syntactic possibility for muddled objects that are
>>> both aliases and objects themselves, which just seems confusing to me.
>>>
>>
>> Honestly, I don't see this as a problem.. consider, if I said,
>>
>> {"objectId":"@me","id":"acct:jas...@us.ibm.com"} ... what is being
>> stated is very clear and unambiguous... this object represents me and
>> my specific identifier is "acct:jas...@us.ibm.com". There's nothing
>> muddled about that. A major point is it's not yet clear whether there
>> will be a need for additional properties or not but we do have a solid
>> use case already (the @friends example) where at least one additional
>> property is necessary. Keeping the values as objects and using
>> properties on those objects not only preserves backwards compatibility
>> by not requiring us to special case the basic spec requirements, it
>> maintains the already inherent extensibility and flexibility of spec
>> without artificially and prematurely restricting the possible
>> extension options.
>
>
> If we go this route then I would want to define completely the correct behavior for merging the data from the "alias" with the data from its referent; this could be as simple as just "replace the whole object with the referent and ignore all of the other properties", but then it's not clear to me what the purpose of the other properties in the alias would be.
>
I don't think we have to define this anymore than we do for any other type of object. For instance, I could have two objects with the same id and same object type but one has an additional property the other doesn't... We don't define merge semantics for those so we shouldn't need to define it here. For now, let's leave it open and work on getting more implementation experience so we know what will be needed in practice. Having an object with a single alias property would meet the immediate need in a backwards compatible way that doesn't alter format syntax, it's the easiest solution in the term, so let's go with that for now.
>
>>> I don't like the name "objectId" because it's too similar to "id". Perhaps
>>> instead "aliasKey", which for now is defined only as an at sign followed by
>>> a contextually-defined token name. Let's reserve judgement on other possible
>>> values for this field until we have some real use-cases; it's not clear to
>>> me why you'd put an absolute URI in here, so I'd prefer not to allow it
>>> until we understand what it means.
>>>
>>
>> Perhaps just "alias":"@value" and we keep the value spec as just a
>> string with no restrictions?
>>
>
> Fine by me.
>
>
Laurent-Walter Goix
I have some questions about targeting and aliases:
Have you been investigating this usage in a federated context, say
with Salmon? what if i share an activity
"to":[
{"alias":"@friends"}
]
with some of my friends belonging to other social networks? PuSH does
not work in this context as it only is capable of dispatching "public"
activities.
supposing this is solved, would any comment (e.g. posted with Salmon)
to this activity by one of my friends automatically inherit from this
setting and be redispatched to the same list than my "original"
activity?
do you expect this friend to also apply targeting to his own comment,
e.g. to share it also to "his" friends?
besides, how would you expect to target more restricted groups of
users (e.g. circles or "internal/personal" lists like "my team", "my
cousins", etc) and not only "well-known" aliases?
walter
On Nov 17, 7:11 pm, James Snell <jasn...@gmail.com> wrote:
> On Nov 16, 2011 10:37 AM, "Martin Atkins" <m...@degeneration.co.uk> wrote:
>
>
>
>
>
>
>
>
>
>
>
> > On 11/16/2011 09:52 AM, James Snell wrote:
>
> >> Well, I'm definitely not a fan of breaking backwards compatibility for
> >> an optional extension when we can easily fit this into the existing
> >> model without breaking anything. The other part is, while the majority
> >> of use cases would have just a single property, I've already
> >> identified one that would have more than one property... that of
> >> identifying a subgroup of @friends, e.g.
> >> {"objectId":"@friends","id":"family"}.
>
> > Why not just "@family"? I guess this is an OpenSocial feature I'm not too
> familiar with.
>
> The subgroups are arbitrarily named typically... Example would be
> individual circles but there, of course you have the argument that an alias
> is not required if you can identify the subgroup directly.
>
> > I'm also not too convinced by the compatibility argument since all of the
>
> use-cases we've explored so far are useless without support for this
> feature, and therefore there ought to be zero overlap between existing
> implementations that don't use this feature and new implementations that do.
>
>
>
>
>
>
>
>
>
> >>> Your proposal creates the syntactic possibility for muddled objects
> that are
> >>> both aliases and objects themselves, which just seems confusing to me.
>
> >> Honestly, I don't see this as a problem.. consider, if I said,
>
> >> {"objectId":"@me","id":"acct:jasn...@us.ibm.com"} ... what is being
> >> stated is very clear and unambiguous... this object represents me and
> >> my specific identifier is "acct:jasn...@us.ibm.com". There's nothing
James Snell
social networks in a federation scenario, the best option would be use
a specifically identified group object rather than an alias... e.g.
"to":[{"objectType":"group","id":"http://the.other.network/@me/@friends"}]
or some such thing, rather than an alias object. Using the
"alias":"@friends" in this scenario could have unintended consequences
as the @friends group may have different meaning from one social
network to the next. If intentionally sharing with multiple services,
the more specific you can be, the better.