Activity Streams Vocabulary

This note might go a bit long. If so, my apologies.

First: a quick history of Activity Streams 2.0

The first version of Activity Streams 2.0 that I published as an
Internet Draft used JSON-LD as the primary serialization. Instead of
"objectType", I used "@type" and had dropped the "verb" property
entirely. The "id" property had become "@id". I used the "@language"
instead of just "language". As soon as I published that initial draft,
the feedback on the existing Activity Streams mailing list was that
breaking compatibility with Activity Streams 1.0 was unacceptable.

To address the compatibility concern, I backed off the changes and
took a "JSON-LD Compatible" approach that allowed Activity Streams 1.0
to be forward compatible with 2.0. In order to accomplish this, I had
to jump through a few hoops with the compatibility rules currently
outlined in [1].

I took some time this past week to have a detailed conversation with
Arnaud, reviewing IBM's goals around Activity Streams and determining
exactly what our requirements are. That discussion settled on one very
specific point: although we have product shipping today that uses the
Activity Streams 1.0 syntax, maintaining forwards or backwards
compatibility with that syntax in whatever this WG produces is *not* a
critical requirement for us.

After discussing it, Our proposal is to:

A. Define a formal Activity and Actions Ontology based on [2].
B. Define a requirement that all implementations MUST at least support
a JSON-LD serialization of this Ontology.
C. Model the Actions Ontology after the approach currently taken by
schema.org/Actions but without actually copying or using the
schema.org vocabulary.

[1] http://jasnell.github.io/w3c-socialwg-activitystreams/activitystreams2.html#jsonld
[2] http://jasnell.github.io/w3c-socialwg-activitystreams/activitystreams2-vocabulary.html

So what exactly does this mean in terms of the syntax? A couple of things.

1. We would be able to drop the Type Value and Link Value concepts.
"objectType" would be defined as an alias of "@type" with identical
semantics. "verb" would be defined as "@type": "@id". Properties that
are currently defined as Link Values would be defined as "@type":
"@id"

2. "id" would be defined as an alias of "@id", with identical semantics.

3. "language" would be defined as an alias of "@language", with
identical semantics.

Ultimately, the result would be essentially identical to what we have
today if someone were to support the existing JSON-LD approach
documented in the AS 2.0 document. The key difference is that the
serialization would conform 100% to JSON-LD.

However, there is an additional benefit to taking this approach: The
ability to also serialize Activities and Actions using HTML5
microdata. For instance:

<div itemscope itemtype ="http://activitystrea.ms/2.0/Activity">
  <a itemprop="http://activitystrea.ms/2.0/actor"
       itemscope itemtype="http://xmlns.com/foaf/0.1/Person">
       <span itemprop="http://activitystrea.ms/2.0/displayName">Sally</span>
  </a>
  <span itemprop="http://activitystrea.ms/2.0/verb"
             itemid="upload"
             itemscope
             itemtype="http://activitystrea.ms/2.0/verb">
    <span itemprop="http://activitystrea.ms/2.0/displayName">uploaded</span>
  </span>
  <span itemprop="http://activitystrea.ms/2.0/object"
             itemscope
             itemtype="urn:example:photo">
    <span itemprop="http://activitystrea.ms/2.0/displayName">a photo</span>
  </span>.
</div>

I must admit that my HTML5 microdata is rusty so this may be quite a
bit more verbose than is strictly necessary, but it ought to get the
point across. The key point is: by going with the ontology approach,
we are not limited to a strictly JSON view of the world, which is
good... particularly for folks who may thing that the JSON way of
doing things is less than ideal (I'm looking at you, IndieWeb Guys).

For folks who want a pure JSON view of the world, the requirement that
implementations MUST support the JSON-LD serialization gives us a
bridge. Using a well crafted @context, we can actually still achieve
AS1->AS2 forwards compatibility (that is, all existing Activity
Streams 1.0 documents will continue to be valid Activity Streams 2.0
documents). It'll just take a bit of magic in how the @context is
defined.

I'll be working this week to sketch up what the Activity Streams 2.0
formal ontology would look like. In terms of the specs, it would mean
a greatly simplified core spec, a bit more added to the vocabulary
document, and the creation of an accompanying OWL Ontology that
describes the vocabulary.

Anyway, that's our proposal. Feel free to throw flowers or eggs. What'cha think?

- James

Received on Sunday, 21 September 2014 22:35:28 UTC