Re: **PROPOSED** AS2 spec update

On Thu, Nov 6, 2014 at 11:40 AM, ☮ elf Pavlik ☮
<perpetual-tripper@wwelves.org> 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.

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

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

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

For instance, while

{
  "@context": ["http://asjsonld.mybluemix.net", {"foo": "as:displayName"}],
  "foo": "test"
}

Might be a valid JSON-LD document, it ought not to be considered a
valid Activity Streams 2.0 document. The language in the draft allows
additions to be made to the @context but requires that the normative
terms not be modified. I can work on the wording here to make it
clearer.

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

Good, hopefully others agree ;-)

- James

> o/

Received on Thursday, 6 November 2014 20:11:24 UTC