RE: **PROPOSED** AS2 spec update

On 6 Nov 2014 at 21:10, James M Snell wrote:
> On Thu, Nov 6, 2014 at 11:40 AM, ☮ elf Pavlik ☮ wrote:
> [snip]
>>> 
>>> 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.
> 
> Additional review is always good but I've been all over the various
> options here. While this option may not be perfect, it (a) preserves
> AS1 compatibility, (b) works with the JSON-LD language context model,
> and (c) gives developers a predictable JSON serialization to work
> with. All of the other possible approaches require mechanisms that are
> incompatible with JSON-LD as currently defined which, in turn, would
> require developers to perform additional pre or post processing on the
> Activity Streams document, which is definitely less than ideal.

I find this solution quite elegant. We can of course argue whether the suffix for those properties should be "Map" or something like "Multilingual".. but let's not go there.. at least not now :-)


>>> 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
> 
> While the blank nodes here may be inconvenient, they are easy to work
> with in JSON-LD and are no more inconvenient than working with the
> MediaLink construct in AS1. The goal here is a model that works, not
> one that attempts to make everyone happy. I don't see how your
> suggested alternative below is an improvement.

I'm also a bit on the fence about this. I have to admit I fail to fully understand why we need this. The examples in the updated draft without "rel" would be completely fine and idiomatic JSON(-LD) without introducing as:Link and href as you really just describe the referenced resource:

        "image": {
          "@id": "http://example.org/martin/image",
      -->          "@type": "as:Link",  <-- not needed *
          "mediaType": "image/jpeg",
          "width": 250,
          "height": 250
        }

* but if you want, you could either declare this to be a as:Image or just a dereferenceable resource as:Resource (analogous to what Hydra does). I would it find cleaner though if the *property* itself would tell you whether it's value should be expected to be dereferenceable or not (rdf:Property vs. hydra:Link)

instead of

        "image": {
          "@type": "as:Link",
          "href": "http://example.org/martin/image",
          "mediaType": "image/jpeg",
          "width": 250,
          "height": 250
        }

For the as:Link's with a "rel", I would find it cleaner to use a more specific property instead. So

      "object" : {
        "@type": "http://example.org/Photo",
        "@id": "http://example.org/album/my_fluffy_cat.jpg",
        "image": {
          "@type": "as:Link",
          "href": "http://example.org/album/my_fluffy_cat_thumb.jpg",
          "mediaType": "image/jpeg",
          "rel": "preview"
        }
      },

Would become

      "object" : {
        "@type": "http://example.org/Photo",
        "@id": "http://example.org/album/my_fluffy_cat.jpg",
     -->   "preview": {  <-- or, e.g., thumbnail
          "@id": "http://example.org/album/my_fluffy_cat_thumb.jpg",
          "mediaType": "image/jpeg"
        }
      },



> [snip]
>>> 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

I think it is OK the way it is currently written in the draft

   "Implementations MAY augment the provided @context with additional
    @context definitions but MUST NOT override or change the normative
    context."


> For "Valid" serialized Activity Streams 2.0 documents yes we can forbid it.

At some point I would like to discuss whether we actually need a separate media type or whether defining a profile would be enough. I filed ISSUE-52 for this:

  https://github.com/jasnell/w3c-socialwg-activitystreams/issues/52


>>> 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!

+1


--
Markus Lanthaler
@markuslanthaler

Received on Thursday, 6 November 2014 20:39:34 UTC