streams-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Franklin <m.ben.frank...@gmail.com>
Subject Re: New Generalized Extensions for ActivityStreams Schema
Date Tue, 06 May 2014 13:31:14 GMT
On Mon, May 5, 2014 at 12:54 PM, Steve Blackmon <steve@blackmon.org> wrote:

> I think it's a worthwhile exercise to attempt to standardize
> well-defined custom attributes across streams implementations.  I
> think gender and authoritative metrics sourced from upstream (total
> shares, likes as of some point in time) fall into that category.
>
> I do think we should keep a barrier between a core activity (defined
> by published spec) and usage of activity with additional designated
> fields.  I'd like to see a pattern where individual contributed
> modules can extend the core activity model and use bind-able jackson
> objects generated from schemas so other contributed modules with an
> asserted dependency can interact with the extended activity through a
> more specific typed interface.
>

I tend to agree, though it would be good to hear arguments for not
separating extensions into their own sub objects.


>
> Since some of the specific concepts referred to in this thread are
> global in nature i.e. not aligned directly to any specific module, i
> suggest that we put the associated schema and supporting classes in a
> streams-pojo-extensions module, which implementers can use if they
> want to gain access to these fields, and not use if they prefer to
> work with objects directly from the spec.
>

Makes sense.


>
> Steve
>
> On Thu, May 1, 2014 at 7:36 PM, Matt Franklin <m.ben.franklin@gmail.com>
> wrote:
> > On Tue, Apr 29, 2014 at 8:17 PM, Bill Christian <
> bill.christian@gmail.com>wrote:
> >
> >> Not a fan of a generic 'extensions' collection. I have, though, found
> >> use in defining entities collection for items referenced in the
> >> content section. The style mimics the approach from App.net messaging
> >> schema. From your examples, this would only address hashtags,
> >> mentions, and urls. The gender of the author should be a custom
> >> attribute on the actor or object. However, an example might clarify.
> >> Aren't rebroadcasts consider downstreamDuplicates?
> >>
> >
> > I think rebroadcasts in this case are shares, retweets, etc.
> >
> >
> >>
> >> On Tue, Apr 29, 2014 at 12:20 PM, Robert Douglas [W2O Digital]
> >> <rdouglas@w2odigital.com> wrote:
> >> > I¹m working on mocking up the new schema at the moment, but
> Œextensions¹
> >> > would become a new top-level element in the json structure. Each of
> the
> >> > proposed extensions would then be a sub-element in that Œextensions¹
> >> > element.
> >> >
> >> > On 4/29/14, 11:12 AM, "James M Snell" <jasnell@gmail.com> wrote:
> >> >
> >> >>In this proposal, how would these manifest in the json structure?
> >> >>
> >> >>On Tue, Apr 29, 2014 at 8:57 AM, Robert Douglas [W2O Digital]
> >> >><rdouglas@w2odigital.com> wrote:
> >> >>> Hi all,
> >> >>>
> >> >>> Given that there are certain attributes that are similar across
> >> >>>multiple social media feeds (ie. A Œlike¹ on Facebook, Œfavorite¹
on
> >> >>>twitter, and Œ+1¹ on Google+ are all equivalent) I think it makes
> sense
> >> >>>to break these out into generalized extensions. I¹d like to propose
> the
> >> >>>following extensions:
> >> >>>
> >> >>>
> >> >>>  *   extensions.hashtags
> >> >>>     *   An array that holds an entry for each unique hashtag
> mentioned
> >> >>>in a post
> >> >>>  *   extensions.likes.perspectival
> >> >>>     *   A boolean field that denotes whether or not this post was
> >> >>>favorited by another user
> >> >>>  *   extensions.likes.count
> >> >>>     *   The total number of likes a post received
> >> >>>  *   extensions.rebroadcasts.perspectival
> >> >>>     *   Whether or not this post was rebroadcasted
> >> >>>  *   extensions.rebroadcasts.count
> >> >>>     *   The total number of rebroadcasts this post received
> >> >>>  *   extensions.rebroadcasts.users
> >> >>>     *   An array that holds an entry for each user that
> rebroadcasted
> >> >>>this post
> >> >>>  *   extensions.user_mentions
> >> >>>     *   An array that holds an entry for each user that is
> mentioned in
> >> >>>this post
> >> >>>  *   extensions.urls
> >> >>>     *   An array that holds an entry for each URL that is mentioned
> in
> >> >>>this post. Each entry would have both the raw URL in addition to
just
> >> >>>its domain
> >> >>>  *   extensions.gender
> >> >>>     *   The gender of the author
> >> >>>
> >> >>> What are everyone¹s thoughts?
> >> >>>
> >> >>> Thanks,
> >> >>> Robert Douglas
> >> >
> >>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message