- From: James M Snell <jasnell@gmail.com>
- Date: Mon, 29 Sep 2014 17:10:55 -0700
- 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