W3C home > Mailing lists > Public > public-socialweb@w3.org > September 2014

Activity and Actions Vocabulary

From: James M Snell <jasnell@gmail.com>
Date: Mon, 29 Sep 2014 17:10:55 -0700
Message-ID: <CABP7RbdoU5s4Wq89mfCsz_PXG9Zv7DOYaL9VgA0toMdx9H2a3w@mail.gmail.com>
To: "public-socialweb@w3.org" <public-socialweb@w3.org>
Cc: "public-social-interest@w3.org" <public-social-interest@w3.org>
Ok,

So I've taken some time to update the Activity and Actions Vocabulary
document here [1]

[1] https://github.com/jasnell/w3c-socialwg-activitystreams/blob/ontology-approach/activitystreams2-vocabulary.html

This is done in a branch on github so this version of the document is
not yet "live". To view the HTML document properly, I recommend
checking out the branch from github and loading in your local browser.

git clone -b ontology-approach
https://github.com/jasnell/w3c-socialwg-activitystreams.git

Look specifically at the activitystreams2-vocabulary.html document.

There are a number of very specific and important changes in this document.

1. The notion of "Type Values" has been removed. I introduced the Type
Value concept into AS2.0 originally as a way of dealing with verb and
object type extensibility. However, if we end up primarily leaning
towards a JSON-LD based recommendation, Type Value is not ideal,
largely because it is incompatible with the way that JSON-LD's @type
keyword is currently defined. Eliminating Type Value allows us to
achieve better forwards compatibility with AS 1.0 documents and avoids
some processing-weirdness when using JSON-LD.

2. The notion of "Link Values" has been modified. Based on feedback
received from the community, it was felt that having a notion of a
Link that was distinct from Object was needed. There were also
questions about the interplay between Link Relations, Object
Properties and things like the "url" property. This modification
completely addresses those concerns, in my opinion. The new concept of
a "Link" replaces the previous "Link Value" concept. Several
properties, such as "url", "image" and "icon" are defined as
specifically having Link's as values. To illustrate by example:

  {
    "@id": "http://example.org/foo",
    "displayName": "This is a test",
    "image": {
      "@id": "http://example.org/img/foo.png",
      "mediaType": "image/png"
    },
    "url": {
      "@id": "http://example.org/thing.html",
      "mediaType": "text/html"
    }
  }

Because of the way the JSON-LD context is defined, the value of both
the "image" and the "url" properties can be Strings containing just
the URI of the resource. However, if additional details need to be
specified, those can be expanded out into objects, or even arrays of
objects. The JSON-LD model takes care of the specific details of that
for us.

In this example, there are several bits worth pointing out. First,
notice that "@id" is used to express the target URI. This is in
keeping with the existing JSON-LD model. Also note that the
"mediaType" attribute is moved into the Link object.

One thing that is not illustrated in the example above is that the
Link Relation ("rel" attribute) is strictly a property of the Link
object now. The regular AS Object class no longer has a "rel"
attribute and property names are no longer used as Link Relations.
This ought to eliminate any possible confusion. The only way for a
link to have a link relation is for the Link object itself to have a
"rel" attribute. This change ought to make quite a few people happier
;-)

3. The Actions model has been folded in and modified. Previously, the
Actions stuff was defined in a separate document
(activitystreams2-actions.html) and followed a different format. I
have folded those object types and terms into the core vocabulary and
have reworked the object model to be much closer aligned and similar
to the model currently adopted by the schema.org/Actions model without
introducing any dependencies on what has been done in schema.

For instance, previously, Actions on an object looked like this:

{
  "actions": {
    "like": {
      "objectType": "HttpActionHandler",
      "method": "GET",
      "url": "http://example.org/foo"
    },
    "share": {
      "objectType": "EmbedActionHandler",
      "content": "<p>...</p>",
      "mediaType": "text/html"
    }
  }
}

While this worked, it did leave a bit to be desired. After reworking
the model late last week, we came up with an alternative that is MUCH
better in my opinion. Here's what it would look like now:

{
  "action": [
    {
      "@type": "http://example.org/LikeAction",
      "using": {
        "@type": "http://activitystrea.ms/2.0/HttpRequest",
        "method": "POST",
        "url": "http://example.org/foo"
      }
    },
    {
      "@type": "http://example.org/ShareAction",
      "using": {
        "@type": "http://activitystrea.ms/2.0/EmbeddedView",
        "content": "<p>...</p>",
        "mediaType": "text/html"
      }
    }
  ]
}

Folks who are familiar with the schema.org/Action approach immediately
ought to be able to spot the similarities in this new approach. There
are a number of very important differences, however. I will take some
time to document many of those differences through examples a bit
later on (in a separate post).

4. There are several other important changes.

  a. The "duplicates" property which I introduced in AS2 as a
replacement for the AS1 "upstreamDuplicates" and
"downstreamDuplicates" properties is removed. Honestly, I've *never*
seen anyone use these in production. My preference would be to simply
deprecate upstreamDuplicates and downstreamDuplicates and not replace
them with anything at all.

  b. The AS1 "tags" and "attachments" properties are renamed to the
singular form "tag" and "attachment" to be consistent with the rest of
the vocabulary. Using the JSON-LD context, we can easily define "tags"
and "attachments" as aliases of the new singular forms -- doing so
gives us fairly seamless forwards compatibility.

 5. Note that the vocabulary document does not deal with serialization
options at all. The working assumption is that JSON-LD will be used.
However, because this is defined as an abstract vocabulary, it is
easily possible to support Microdata, RDFa or Microformat options in
HTML5 or even formats such as Turtle.

6. A complete JSON-LD @context document and vocabulary definition is
included in the activitystreams2-context.jsonld file.

In a separate post I will begin documenting example serializations of
this revised vocabulary model.

- James
Received on Tuesday, 30 September 2014 00:11:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:26:12 UTC