Machine tags?

[Chris Messina]

Was thinking about our namespace solution and I'm concerned that it
might lead to some problems with getting adoption. I think we can
pursue it still, but I wanted to propose the use of machine tags in
the category attribute to ensure that activity stream elements are not
stripped from one site to the next.

Simply, we could add tags like these:

Activity:verb=gave
Activity:label=gifted
Activity:actor=Chris
Activity:context=SMS or Activity:via=SMS
Activity:indirect-object=Steve

Thoughts?

Chris

--
Chris Messina
Citizen-Participant &
Open Technology Advocate-at-Large
factoryjoe.com # diso-project.org
citizenagency.com # vidoop.com
This email is: [ ] bloggable [X] ask first [ ] private

[Edward Ho]

It's a good thought. I like the idea, specifically because category is well supported by crawlers and parsers.
Some comments inline somewhat unrelated...

On Sat, Dec 6, 2008 at 12:32 PM, Chris Messina <chris....@gmail.com> wrote:

Was thinking about our namespace solution and I'm concerned that it
might lead to some problems with getting adoption. I think we can
pursue it still, but I wanted to propose the use of machine tags in
the category attribute to ensure that activity stream elements are not
stripped from one site to the next.

Simply, we could add tags like these:

Activity:verb=gave
Activity:label=gifted
Activity:actor=Chris
Activity:context=SMS or Activity:via=SMS

It would be nice to separate device/transport from application. We might have:
Activity:transport=SMS and Activity:via=Twitter
or
Activity:transport=HTTP and Activity:via=Plaxo

Transport might not be the best word here, but I'm interested in capturing what device or mechanism was used to generate the activity (Web, SMS, mobile software) and the application used. Couldn't find if this was covered in another part of the spec.
 

[Monica Keller]

Hi Guys
I am new here so hopefully you can bare with me while I catch up a
bit :)

Ok so are you guys proposing to use the categories above instead of
these which were mentioned in another post ?
<category
scheme="http://activitystrea.ms/specs/1.0/verb"
term="http://activitystrea.ms/schema/1.0/post"
/>

Just want to make sure I am following.. seems more readable

I think we should also add "Activity:geolocation" and "Activity:tags"
unless of course that is already conveyed in a different manner. Tags
are more for the content itself and can be used for very powerful
filtering crawling these masses of activities :)

[Monica Keller]

Actually this looks a lot better
http://en.wikipedia.org/wiki/GeoRSS
for locations :D

[Chris Messina]

Hi Monica,

Welcome to the group and thanks for your post!

One design principle of the Activity Streams effort is to invent as little as humanly possible and to reuse existing formats and standards where they exist. We've started with ATOM as our transport mechanism and will happily reuse existing techniques for adding additional richness to feeds, like MediaRSS and GeoRSS. 

The Activity Streams work is predicated specifically on identifying the types of activities, actions and verbs used to produce content and social objects in feeds, in a way that is vendor and service agnostic.

One test for our success is the ability to create a service like FriendFeed or Facebook News Feed with a similar amount of richness, readability and expressiveness without having ever been aware of or exposed to the services that someone uses.

Simply by identifying types of verbs in feeds, we should be able to more appropriately display activities in feeds based on more than just content-type. Or that at least is the hope. We also would like to provide some mechanism to reduce echos across services — so that when someone crossposts to many services simultaneously you don't end up with a feed with lots of duplicate content.

To answer your original question, my proposal is something of an alternative to the custom namespace elements (turns out, my proposal is similar to what Martin suggested on December 1 -- which you were referring to). My concern is that the full URI is not readable and won't be likely adopted when compared with the simplicity and aesthetics of machine tags.

There are additional elements that could be useful:

activity:source=twitter.com

activity:source-id=1042411807

activity:source-url=http://twitter.com/factoryjoe/status/1042411807

Or something.

As for tags, those can be handled with the existing <category> element in ATOM.

Chris

[Monica Keller]

Makes perfect sense. Thanks for the recap. I will search for the list
of verbs you guys have currently agreed upon
Also would like to know how we would go about describing the
correlation of a verb with the format used to describe the activity
using RSS Extensions
Or is that up to the feed publisher ?

> This email is:   [ ] bloggable    [X] ask first   [ ] private- Hide quoted text -
>
> - Show quoted text -

[Chris Messina]

The idea is that once we've identified the verb-type, the aggregator can determine how to coalesce different activities of the same type, and how to output them in an aggregated view.

We have the idea that we could create discreet templates that aggregators could use for certain known/popular verb types but that they would not be mandatory or necessarily part of the spec.

There's more info on the wiki, though we probably should write this all up in more detail:

http://wiki.diso-project.org/activity-streams

http://wiki.diso-project.org/activity-streams-verbs

http://wiki.diso-project.org/activity-streams-brainstorming

http://wiki.diso-project.org/activity-streams-examples

Chris

[Monica Keller]

I see. At MySpace we also map an activity "type" to a template which
describes how to render and group.

I guess my question was more about mapping an activity type to a
document which would describe the kind of data contained in the
activity using rss extensions. Promoting discovery so then aggregators
would not need additional templates. Hmmm

Where you guys thinking the atom feed would contain xhtml or not ?

On Dec 7, 7:06 pm, "Chris Messina" <chris.mess...@gmail.com> wrote:
> The idea is that once we've identified the verb-type, the aggregator can
> determine how to coalesce different activities of the same type, and how to
> output them in an aggregated view.
> We have the idea that we could create discreet templates that aggregators
> could use for certain known/popular verb types but that they would not be
> mandatory or necessarily part of the spec.
>
> There's more info on the wiki, though we probably should write this all up
> in more detail:
>

> http://wiki.diso-project.org/activity-streamshttp://wiki.diso-project.org/activity-streams-verbshttp://wiki.diso-project.org/activity-streams-brainstorminghttp://wiki.diso-project.org/activity-streams-examples
>
> Chris

[Chris Messina]

Yes, the ATOM feed would contain XHTML -- and microformats very likely. 

There is a balance between having feeds which are "activity feeds" -- and describe the look of a referent to an activity -- and conventional feeds which have "activity hints".

It's unclear which we ultimately will need -- and how much we can count on aggregator to do the work of interpreting verb types and outputting them in a sensible way.

But then, that's why Martin is working on code -- so that we can look at the delta between the current "hint" approach versus having entirely separate (and therefore redundant) activity feeds.

Chris

[Martin Atkins]

(sorry for jumping into this late; GMail has for some reason taken to
dropping my incoming mailing list messages on the floor, so I didn't
see this thread until now. Reply below...)

On Dec 6, 12:32 pm, "Chris Messina" <chris.mess...@gmail.com> wrote:
> Was thinking about our namespace solution and I'm concerned that it
> might lead to some problems with getting adoption. I think we can
> pursue it still, but I wanted to propose the use of machine tags in
> the category attribute to ensure that activity stream elements are not
> stripped from one site to the next.
>
> Simply, we could add tags like these:
>
> Activity:verb=gave
> Activity:label=gifted
> Activity:actor=Chris
> Activity:context=SMS or Activity:via=SMS
> Activity:indirect-object=Steve
>

There's definitely merit to the idea of using atom:category. It would
make it much more likely that activity streams would make it through
aggregators and such intact.

However, I'm not keen on the idea of whacking key-value pairs inside
the category elements. I assume you're imagining something like this:
<category term="Activity:verb=gave" />

As an implementer I'd much rather use the structures provided by XML
so that I don't have to additionally parse/produce an ad-hoc sub-
language within that attribute. I'll concede that it's not a major
burden to with this particular structure, but XML libraries already
have functions for creating and parsing the constructs provided by XML
itself which are understood by developers and also supported in most
existing Atom libraries.

We also previously seemed to agree that it was good to re-use existing
Atom extensions for describing items such as photos so that processing
code could be re-used; that doesn't seem to be compatible with putting
the object metadata in atom:category term attribute, since no existing
Atom extension does this.

My suspicion is that we'll end up somewhere in between these
approaches, possibly using atom:category for the verb/object-type
annotations but extension elements for the more meaty stuff. However,
we should definitely try these various approaches in the wild with
different producer/consumer/aggregator implementations and see what
works and what doesn't.

[Monica Keller]

Yes after doing some more reading and seeing Microsoft's integration
feed requirements I think that we could just use different schemes in
category to store the verb and object type

http://www.majordojo.com/2006/05/overloading-atomcategory.php