VS: Re: Targeting Spec - Last Call
ollima...@gmail.com
---- alkuperäinen viesti ----
Lähettäjä: Laurent-Walter Goix
Lähetetty: 06-03-2012, 13:41
Vastaanottaja: Activity Streams
Aihe: Re: Targeting Spec - Last Call
thank you james for the update that greatly improves the spec.
the fully-qualified iri as group "alias" resolves the ambiguity issue
so that it becomes clear whose "friends" (or other) i am talking
about, also in a distributed context. As a side question in this case
would it make sense to reuse the standard "id" property and keep alias
only for this "non uri"/ambiguous value?
if i understood the new wording properly:
- the case of Evan's related to "mentions" is covered by using the
"to" property to draw attention
- the other case related to "restricted distribution" of content is
covered using the "bto" (or "bcc") property that would automatically
make the specific activity accessible *only* to that audience. in this
case it would be essential that recipients (eg servers) of activities
containing this extension do support it indeed, in order to avoid
privacy issues when storing/forwarding that activity and make it
available to others
am i right?
thank you again
walter
On Mar 6, 1:26 am, James M Snell <jasn...@gmail.com> wrote:
> Ok... Updated draft based on the feedback given here..
>
> http://activitystrea.ms/specs/json/targeting/1.0/
>
> Specific updates:
>
> - Language that clarifies that any objectType can be used.
> - Define "alias" as either a single path segment or fully qualified IRI
> - Language that warns that the use of single path segment aliases are
> ambiguous and are recommended only when the communicating parties
> share a common understanding of their meaning.
> - Language clarifying that there is no spec-defined default primary or
> second audience in the absence of targeting properties.
>
> - James
>
> On Mon, Mar 5, 2012 at 4:18 PM, James M Snell <jasn...@gmail.com> wrote:
>
>
>
>
>
>
>
> > Yes.. Yes it would.
>
> > On Mar 5, 2012 4:17 PM, "Bob Wyman" <b...@wyman.us> wrote:
>
> >> On Mon, Mar 5, 2012 at 6:28 PM, James M Snell <jasn...@gmail.com> wrote:
>
> >>> Bob,
>
> >>> Note that, in the targeting spec, the to, cc, bcc and bto properties
> >>> are defined in terms of an array of Objects... meaning any type of AS
> >>> Object, not just people or groups. Imagine, for instance, we someone
> >>> were to define a "Filter" objectType that did precisely the kind of
> >>> thing you're suggesting... e.g.
>
> >>> {
> >>> "to": [
> >>> {"objectType":"filter",
> >>> "objectTypes":["person"],
> >>> "filters":[
> >>> {"objectType":"place",
> >>> "position":"+12.123+123.123",
> >>> "radius":"10",
> >>> "radius-unit":"miles"}
> >>> ]
> >>> ],
> >>> ...
> >>> }
>
> >>> This would be a perfectly valid use of the audience targeting
> >>> extensions and makes the mechanism extremely flexible long term. Of
> >>> course, standardization of the objectTypes would be most desirable but
> >>> that's a separate issue from the syntax.
>
> >> Thanks for correcting me. Yes, I can see how the missing element isn't in
> >> your spec but rather lies in the absence of a "Filter" object. If we had a
> >> "Filter" object, then the value of the Targeting properties could include
> >> objects that *describe* a person or individual instead of the objects that
> >> merely *represent* a person or individual as in your current text.
>
> >> I suspect that such a Filter Object would have utility in many more
> >> contexts than just this one.
>
> >> bob wyman
>
> >>> - James
>
> >>> On Mon, Mar 5, 2012 at 2:44 PM, Bob Wyman <b...@wyman.us> wrote:
> >>> > I realize that this comment may be considered a bit too abstract to
> >>> > motivate
> >>> > a change... Nonetheless:
>
> >>> > This specification is clearly influenced by experience with existing
> >>> > distributed, push-based message routing systems. This is seen in the
> >>> > choice
> >>> > of To:, CC:, etc. keywords as well as in the fact that members of the
> >>> > intended audience are identified with the kind of unique identifiers
> >>> > that
> >>> > are typical of messaging systems.
> >>> > However, it seems to me that activities will not always be "pushed" but
> >>> > will
> >>> > sometimes be "pulled." (A system designed for "pull" processing would
> >>> > be
> >>> > different, I think). Also, my guess is that those who target activities
> >>> > will
> >>> > not always be able to enumerate all those in their intended audiences
> >>> > (even
> >>> > with the help of distribution-list like aliases.) Note: This is a
> >>> > general
> >>> > concern that I've had with email addressing ever since I implemented my
> >>> > first email system back in 1980...
>
> >>> > Often, what I would like to do is create a message which is targeted to
> >>> > anyone who has some "quality" or "attribute" where that attribute is
> >>> > something other than a personal identifier. For instance, if I create
> >>> > the
> >>> > activity "Observed a fire at 85th St. and Lexington Ave!," I might want
> >>> > the
> >>> > audience for that activity to be "Anyone now within one mile of 85th
> >>> > and
> >>> > Lexington Ave." This is addressing based on an attribute of the
> >>> > intended
> >>> > audience members, rather than just just the "name" or "address"
> >>> > attribute of
> >>> > the audience members. It is also addressing based on an attribute that
> >>> > may
> >>> > be constantly changing. Certainly, it would be possible for some system
> >>> > to
> >>> > implement a set of Alias Objects that are modified whenever people move
> >>> > from
> >>> > place to place, however, that would be relatively gross. I would rather
> >>> > have
> >>> > some more general method of specifying audience selectors that
> >>> > supported, as
> >>> > a subset, a means of identifying a well-known predefined list as well
> >>> > as
> >>> > sets of "addressees" based on their qualities.
>
> >>> > The desirability of "addressing by qualities" of the audience rather
> >>> > than
> >>> > the identities of audience members increases as we begin to consider
> >>> > the
> >>> > kind of pull-based message retrieval that happens when we store data
> >>> > and
> >>> > later "search" for it. For instance, I might create an activity that
> >>> > announces that I've "Created a new code for prospective search" and I
> >>> > want
> >>> > my audience to be "C++ Programmers." Well, it might serve my immediate
> >>> > purpose if I defined my audience as everyone currently on some actively
> >>> > maintained "C++ List". However, membership in that list is likely to
> >>> > change
> >>> > over time and thus those who search for relevant activities in the
> >>> > future
> >>> > might not be considered part of the audience unless they were on the
> >>> > original list or unless someone has been faithfully maintaining the
> >>> > list.
> >>> > (This would be a very real concern if aliases were "expanded" when
> >>> > activities transited system boundaries.) In this case, it would be much
> >>> > better for me if my reference to "C++ programmers" meant "Anyone with
> >>> > the
> >>> > C++ Programmer badge in their profile" rather than simply "anyone on
> >>> > the
> >>> > named list."
>
> >>> > it should be obvious as well that there are times when I'd like to be
> >>> > able
> >>> > to define my audience selector as: "C++ Programmers living or working
> >>> > in New
> >>> > York City" which would require a bit of Boolean logic applied to
> >>> > various
> >>> > attributes values...
>
> >>> > What this all boils down to is that I suggest that while the "Alias
> >>> > Object"
> >>> > might be a fine solution to the specific problem considered by the
> >>> > author,
> >>> > it may be non-optimally general in its ability to address other needs
> >>> > that
> >>> > either exist but weren't considered or that might arise in the future.
> >>> > The
> >>> > result might be unnecessary complexity in the future if someone finds
> >>> > that
> >>> > they need to define yet-another-spec in order to provide for
> >>> > "addressing by
> >>> > qualities" rather than just "addressing by identifier."
>
> >>> > What I'd like to suggest is that you replace "Alias Object" with an
> >>> > "Audience Selector Object" that supports "Alias" as one member of a set
> >>> > of
> >>> > selector types.
>
> >>> > bob wyman
>
> >>> > On Mon, Mar 5, 2012 at 11:02 AM, James M Snell <jasn...@gmail.com>
> >>> > wrote:
>
> >>> >> Ok, the Targeting Spec [1] has been out there for a while and is
> >>> >> stable. There are implementations available. I think it's time to put
> >>> >> a bow on it and call it done officially.
>
> >>> >> [1]http://activitystrea.ms/specs/json/targeting/1.0/
>
> >>> >> --
> >>> >> You received this message because you are subscribed to the Google
> >>> >> Groups
> >>> >> "Activity Streams" group.
> >>> >> To post to this group, send email to
> >>> >> activity...@googlegroups.com.
> >>> >> To unsubscribe from this group, send email to
> >>> >> activity-strea...@googlegroups.com.
> >>> >> For more options, visit this group at
> >>> >>http://groups.google.com/group/activity-streams?hl=en.
>
> >>> > --
> >>> > You received this message because you are subscribed to the Google
> >>> > Groups
> >>> > "Activity Streams" group.
> >>> > To post to this group, send email to activity...@googlegroups.com.
> >>> > To unsubscribe from this group, send email to
> >>> > activity-strea...@googlegroups.com.
> >>> > For more options, visit this group at
> >>> >http://groups.google.com/group/activity-streams?hl=en.
>
> >>> --
> >>> You received this message because you are subscribed to the Google Groups
> >>> "Activity Streams" group.
> >>> To post to this group, send email to activity...@googlegroups.com.
> >>> To unsubscribe from this group, send email to
> >>> activity-strea...@googlegroups.com.
> >>> For more options, visit this group at
> >>>http://groups.google.com/group/activity-streams?hl=en.
>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "Activity Streams" group.
> >> To post to this group, send email to activity...@googlegroups.com.
> >> To unsubscribe from this group, send email to
> >> activity-strea...@googlegroups.com.
> >> For more options, visit this group at
> >>http://groups.google.com/group/activity-streams?hl=en.
--
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.