Contents 1 Activity Streams Base Schema 1.1 Example 1.2 3.1. Base Verbs 1.3 3.2. Base Object Types 1.4 3.3. Base Activity Context Elements 1.5 3.4. Replies 1.6 4.1. Event Verbs 1.7 4.2. Event Object Types 1.8 5.1. Music Object Types 1.9 Extending the ActivityStreams namespace

Activity Streams Base Schema

Mapping of activitystrea.ms' base schema to PSYC. Activities are notices in PSYC. They have an Actor which is the _context routingwise, a Verb which is a derivate method of _notice, an Object which is specified in various variables and a Context which isn't a context in PSYC's sense but rather extra information such as a timestamp, a geolocation (address) or a mood.

Example

Here's an example of how it looks like in PSYC syntax to send a video clip to a channel of subscribers, indicating that you like it and that it cheers you up (The aligned whitespace is a cheat for readability – actually we use a single TAB character on each of those lines).

|
:_context              psyc://<your-host-key>:g/~sammyjoe#_fun

=_degree_mood          7
=_action               rolling on the floor about this
:_title_media_video    My pig whistles the theme tune of Bonanza
:_image_media_video    <some binary data here>
:_degree_appreciation  99
:_page_media_video     http://example.com/v/wKlHQBhOIX4
_notice_mark
|

Not exactly typical, as it is unlikely that a user would like a video while also writing a /me to it and choosing a new mood level.. but hey, just in case.. some people love to spend time on making their social activities really fancy and inviting.. right?

As you see for this kind of procedure the variables aren't stored into the distributed state, as there is no need to maintain a notion of your 'currently liked video.' The activity is simply stored into the channel's distributed history which is a more volatile kind of storage (you only keep as much of it as you care to and you can ask for old slices of it at the source or at other subscribing or relaying nodes).

For the following things, you can deduct how it should look like - when the time is right we shall refine this into an obvious to use specification.

3.1. Base Verbs

These "base verbs" are event notifications generated by a person entity to be sent to its contexts, be it private (friends) or public (followers).

       3.1.1.  Mark as Favorite

Map to _notice_mark with _degree_relevance [0..9]+

       3.1.2.  Start Following

Announce that we have done a context subscription / started followership: _notice_context_follow with _uniform_context

       3.1.3.  Mark as Liked

Map to _notice_mark with _degree_appreciation [0..9]+

       3.1.4.  Make Friend

Announce that we completed a friendship negotiation with somebody (if you know the person you should get a confirmation from her, too): _notice_friend_made with _uniform_friend.

       3.1.5.  Join

This would be a _notice_context_enter. See context.

       3.1.6.  Play

We already have _notice_play_music_title in psycmp3 but a generic _notice_play makes more sense here. See below for object types.

       3.1.7.  Post

isn't properly defined apparently. The onesocialweb draft has this featuring an object as provided below. Here's an example of "post" with a "status" object as a PSYC packet equivalent to the example featured in the draft.

:_context       psyc://denmark.lit/~hamlet#_follow

:_subject       to be or not to be ?
:_type_content  text/plain
_message
to be or not to be ?
|

       3.1.8.  Save

Huh? Who wants to know?

       3.1.9.  Share

_notice_share it, if you like, but dropping a URL into a friendcast /shout or chatroom _message should have the same result, since sharing is what you do all the time.

       3.1.10.  Tag

I'd like to think of something better than _notice_tag.

       3.1.11.  Update

We do indeed have _notice_update in various notification apps.

3.2. Base Object Types

       3.2.1.  Article

1. _title_article
2. _description_article (a summary usually)
3. _content_article
4. _page_article

       3.2.2.  Audio

1. _title_audio
2. _uniform_audio (or _stream ?)
3. _page_audio
4. _page_audio_player
5. _description_audio

There's also a special event type for audio that is known to be music.

       3.2.3.  Bookmark

1. _title_bookmark
2. _description_bookmark
3. _page_bookmark
4. _page_bookmark_about
5. _title_bookmark_target
6. _uniform_image_bookmark or _image_bookmark for actual embedded binary image data

       3.2.4.  Comment

1. _title_comment
2. _comment
3. _page_comment

Actually what we need here is a _thread id. See threaded discussion rooms.

       3.2.5.  File

According to file transfer this would be _notice_available_file with

1. _uniform_file

but it also makes sense to share the file directly or even embed it.

       3.2.6.  Folder

Make sense to call this _notice_available_folder although it isn't entirely clear why the directory listing should be transferred by HTTP if it can be a _list_uniform.

1. _title_list_folder
2. _page_list_folder
3. _uniform_image_list_folder or _image_list_folder for actual embedded binary image data

Folder would be a derivate of List below.

       3.2.7.  Group

1. _title_group
2. _uniform_image_group or _image_group for actual embedded binary image data

but.. ahem.. where do you put the actual _uniform_group !?

       3.2.8.  List

1. _title_list
2. _description_list
3. _page_list but a _list_uniform would be better

       3.2.9.  Note

Threads uses _notice_thread because it allows for comments, but since in future any _notice should be commentable the method name may change.

1. <data>
2. _page_thread

Message body belongs into the body of course.

       3.2.10.  Person

1. _name_person
2. _uniform_image or actual _image data

Haha, again they forgot the most important information.. the _uniform_person. You may want to provide some _size_image or the actual binary _image data.

       3.2.11.  Photo

1. _title_image
2. _uniform_image_small or _image_small for actual embedded binary image data
3. _uniform_image or _image for actual embedded binary image data
4. _page_image
5. _description_image

       3.2.12.  Photo Album

1. _title_list_image
2. _uniform_image_list_image or _image_list_image for actual embedded binary image data
3. _page_list_image

       3.2.13.  Place

1. _title_address
2. various _address stuff (see profile)

       3.2.14.  Playlist

1. _title_list_media
2. _uniform_image_list_media or _image_list_media for actual embedded binary image data
3. _page_list_media

but of you could have a _list_uniform_media with the actual items...

       3.2.15.  Product

Oh yeah, great idea. Let's enforce SPAM marked as SPAM so we can automatically ignore it.

1. _title_product
2. _uniform_image_product_small or _image_product_small for actual embedded binary image data
3. _uniform_image_product or _image_product for actual embedded binary image data
4. _page_product
5. _description_product

       3.2.16.  Review

1. _title_article_review
2. _content_article_review
3. _page_article_review
4. provide the packet id of a previous _notice_share_product or provide all the variables for a _product as defined above
5. _degree_rating

       3.2.17.  Service

1. _title_service
2. _uniform_service
3. _uniform_image_service_small or _image_service_small for actual embedded binary image data
4. _uniform_image_service or _image_service for actual embedded binary image data

       3.2.18.  Status

This could be considered a presence announcement:

1. _description_presence
2. _page_presence

Of course it doesn't have an associated _page in a world of real chat systems. Or it could be a _message posted to the microblogging channel, in that case a _message with a body and optionally a _page would do.

       3.2.19.  Video

1. _title_media_video
2. _uniform_image_media_video or _image_media_video
3. _uniform_media_video
4. _page_media_video
5. _page_media_video_player
6. _description_media_video

3.3. Base Activity Context Elements

       3.3.1.  Location

See address and Place above.

       3.3.2.  Mood

Mood in PSYC is a _degree, but you can have actions for free format text.

3.4. Replies

This needs packet ids in a _reply variable.

4.1. Event Verbs

       4.1.1.  Positive RSVP
       4.1.2.  Possible RSVP
       4.1.3.  Negative RSVP

_notice_calendar_attendance with _degree_attendance where 0 = no, 5 = maybe and 9 = yes.

When sending out such an event it makes sense to also provide the calendar data, thus it is a derivate of _notice_calendar

4.2. Event Object Types

       4.2.1.  Event

Here's the _notice_calendar:

1. _name_calendar
2. _date_calendar_start
3. _date_calendar_end
4. _description_calendar

Oops, they left out the _page_calendar!

5.1. Music Object Types

       5.1.1.  Song

1. _title_audio_music

What about all the other Audio information?

Extending the ActivityStreams namespace

It's nice about XML namespaces how they can by definition never collide, but this degree of engineering perfection causes us a lot of overhead, making ActivityStreams very large when rendered in RDF and XMPP. When doing custom extension in PSYC, the approach is to just extend the name of the method - as long as people use differing method names, protocol extensions can exist next to each other happily. Method name unicity cannot mathematically be ensured, but it's enough to append your company name to make it unlikely for anyone else on earth to have the same name. How this kind of safety is delivered when using the JSON syntax of ActivityStreams is unclear. Apparently it was no longer an important design criterion, so using the JSON encoding of ActivityStreams may cause trouble at a later time.

See the libpsyc benchmarks comparing an activity in its respective XMPP(OneSocialWeb), JSON and PSYC encodings.