Re: **PROPOSED** AS2 spec update

On 11/06/2014 07:40 PM, James M Snell wrote:
> Based on a number of conversations and feedback since the face to face
> at TPAC, I have written a **PROPOSED** update to the AS2 draft. These
> are checked in to a **Branch** in github. I have not updated the
> official Editor's Drafts. The proposed modification can be viewed
> here:
> 
> http://rawgit.com/jasnell/w3c-socialwg-activitystreams/refactor2/activitystreams2.html
> http://rawgit.com/jasnell/w3c-socialwg-activitystreams/refactor2/activitystreams2-vocabulary.html
Great news!


> 
> The updates tackle a number of issues:
> 
> 1. Refactor's Natural Language Context to address JSON-LD
> compatibility and serialization concerns. For instance, rather than
> "displayName" having a value that is *either* a string or a Language
> Map, this creates a separate "displayNameMap" for the Language Map
> case and keeps "displayName" as a String only. The JSON-LD processing
> algorithms handle this just fine and non-JSON-LD implementations end
> up with a more predictable, consistent target.
https://github.com/jasnell/w3c-socialwg-activitystreams/issues/46
I think we could wait for little more feedback on that part of proposal.


> 
> 2. Remove the "language" property
+1

> 
> 3. Refactor as:Link, add as:href to indicate the target of the Link,
> move away from overloading @id. This ought to resolve the modeling
> issues that have been discussed.
-1 Now we get IMO very inconvenient blank nodes since href 'hijacks' @id

i propose instead of this one
{
  "@context": "http://www.w3.org/ns/activitystreams",
  "@type": "urn:example:types:application",
  "image": [
    "http://example.org/foo.jpg",
    {
      "@type": "http://www.w3.org/ns/activitystreams#Link",
      "href": "http://example.org/screens/1.jpg",
      "rel": "preview",
      "mediaType": "image/jpeg"
    }
  ]
}
where we see: 1.jpg a as:Link (.jpg not a Image?) and with multiple
images we can't match image and its preview/thumbnail any more, instead
we could use pattern used in schema.org
{
  "@context": "http://www.w3.org/ns/activitystreams",
  "@type": "urn:example:types:application",
  "image": [
    {
      "@type": "ImageObject",
      "@id": "http://example.org/foo.jpg",
      "thumbnail": {
        "@type": "ImageObject",
        "@id": "http://example.org/screens/1.jpg",
        "mediaType": "image/jpeg"
      }
    },
    {
      "@type": "ImageObject",
      ...
      "thumbnail": {
        "@type": "ImageObject"
        ...
    }
  ]
}
where each image clearly links to its thumbnail, both have proper @id
and @type ImageObject which makes sense for .jpg

> 
> 4. Deprecate the "verb" property in AS 2.0, use @type instead to
> represent the Activity Type. Provide clear guidelines for handling the
> "verb" property when moving from AS 1.0 to AS 2.0.
+1
seeing in draft "urn:example:verbs:Post"" i think we just need to stay
careful to distinguish Activity from its result! preferably *not* using
also urn:example:nouns:Post

{
  "@type": ["as:Activity", "ex:ReviewActivity"],
  "actor": "foo:an_elf",
  "object" "bar:some_movie",
  "result": {
    "@type": "ex:Review",
    "about": "bar:some_movie",
    "author": "foo:an_elf"
  }
}

* http://schema.org/ReviewAction
* http://schema.org/Review

> 
> 5. Require JSON-LD compacted form using a normative JSON-LD @context
> definition. Forbid implementations from altering the normative JSON-LD
> @context. This will ensure that the serialized JSON will remain
> consistent for the key properties, making it easier for
> implementations that choose not to use the JSON-LD standard
> algorithms.
I don't think we can *forbid* altering context, just adding @language
already alters it and we need to include it in compacting. Maybe we just
need a section on what to avoid to make it usable also without
interpreting as JSON-LD


> 
> 6. Strengthen the MUST IGNORE requirement for extensions. Make it
> clear that implementations SHOULD define extension properties using an
> @context and spell out the consequences if they do not. Make it clear
> that there are some valid JSON constructs (arrays of arrays) that are
> not supported in JSON-LD and show an example using the one significant
> case we are currently aware of (GeoJSON).
I understand we need to use those additions to @context also for
compacting we want to require?

> 
> 7. Provide a AS1-to-AS2 specific @context definition that is
> specifically for processing AS1 documents using AS2 semantics.
+1 https://github.com/jasnell/w3c-socialwg-activitystreams/issues/30

> 
> 8. Remove the Verb and ObjectType abstract classes. Verb is no longer
> needed with the move to @type. Verbs just become subclasses of
> as:Activity. The ObjectType definition can be handled better using
> other constructs. Overall, this simplifies our vocabulary, which is
> good.
+1

> 
> That's a large number of updates, I know, so please review this
> carefully. The goal here is to strike a balance between a number of
> competing points of view. Overall, however, I believe it's an
> iterative improvement over the FPWD.
Looks like solid incremental improvement to me!

o/

Received on Thursday, 6 November 2014 19:42:52 UTC