AS 2.0 Update

[James M Snell]

A few additional updates to the proposed 2.0 update. This adds in the IETF boilerplate and folds in the audience targeting and replies extensions.

https://github.com/jasnell/json-activity/commit/7e35e50a213499e528b6a05d58eff910e593078f

[James M Snell]

Additional incremental updates...

https://raw.github.com/jasnell/json-activity/2.0/json-activity-2.txt

Based on feedback received so far, this draft:

1. Removes the @ prefix on the id, type and language fields. The
definition of these remains the same. This simplifies the pure AS
case, but makes it so that a @context is required in order to process
successfully as json-ld, which is perfectly acceptable.
2. Adds a json-ld example in the prefix
3. Includes a few editorial changes

- James

[Markus Lanthaler]

On Tuesday, June 04, 2013 6:51 PM, James M Snell wrote:
> Additional incremental updates...
>
> https://raw.github.com/jasnell/json-activity/2.0/json-activity-2.txt
>
> Based on feedback received so far, this draft:
>
> 1. Removes the @ prefix on the id, type and language fields. The
> definition of these remains the same. This simplifies the pure AS
> case, but makes it so that a @context is required in order to process
> successfully as json-ld, which is perfectly acceptable.
> 2. Adds a json-ld example in the prefix

Looks great!

The JSON-LD context in appendix B however contains an invalid mapping from
@id to http://schema.org. This would redefine the @id keyword which is not
allowed.

That example also uses single quotes instead of double quotes which should
be changed as it is invalid JSON. There's also a missing comma:

'name': 'John Doe'
} <---
'status':'completed',

You don't map things like "startTime" etc. to any URL. Is that intentional?
The easiest way to "fix" that would be to add something like

"@vocab": "http://activitystrea.ms/spec/2.0/"

to the context. This would map startTime to
http://activitystrea.ms/spec/2.0/startTime.


Hope this helps,
Markus


--
Markus Lanthaler
@markuslanthaler

[James M Snell]

Thx, will take a look at those. Any of you json-ld experts wanna take
a stab at a draft, non-normative context doc?

> --
> You received this message because you are subscribed to the Google Groups "Activity Streams" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to activity-strea...@googlegroups.com.
> To post to this group, send email to activity...@googlegroups.com.
> Visit this group at http://groups.google.com/group/activity-streams?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Markus Lanthaler]

On Tuesday, June 04, 2013 7:47 PM, James M Snell wrote:
> Thx, will take a look at those. Any of you json-ld experts wanna take
> a stab at a draft, non-normative context doc?

Sure. Shall I file a PR to some specific repo (yours?), the spec draft, or
just upload it somewhere for the time being?


--
Markus Lanthaler
@markuslanthaler

[James M Snell]

Either really. Feel free to submit a PR against my repo (note that I'm
working in the 2.0 branch).

[James M Snell]

Another iterative update...

https://raw.github.com/jasnell/json-activity/2.0/json-activity-2.txt

This one deals specifically with backwards compatibility. A section
dealing with 1.0 syntax is added, "name" is changed back to
"displayName".

- James

[Markus Lanthaler]

On Tuesday, June 04, 2013 7:47 PM, James M Snell wrote:
> Thx, will take a look at those. Any of you json-ld experts wanna take
> a stab at a draft, non-normative context doc?

As promised, I create a context. You can find it here:
https://raw.github.com/lanthaler/json-activity/master/context.jsonld

The creation was more or less straightforward. The only problem I had was
how to interpret the "alias" property. I don't really understand what the
spec is saying. Is it a (possibly relative) IRI or not? I assumed it is in
this version.

I use the following URL as the prefix for all properties (namespace URL)
http://activitystrea.ms/spec/2.0/#

The hash at the end allows to put a machine-readable description of all
properties in a single file. Here's a first (still very rough) version of
such a machine-readable description in JSON-LD:
https://raw.github.com/lanthaler/json-activity/master/vocab.jsonld

I think if AS 2.0 is going to adopt JSON-LD, it should be required to
include a reference to a context (probably hosted somewhere on a
activitystrea.ms) to signal that, e.g.:

"@context": "http://activitystrea.ms/spec/2.0/"

This can be safely ignored by all clients not using a document as JSON-LD.

[James M Snell]

On Mon, Jun 10, 2013 at 6:58 AM, Markus Lanthaler
<markus.l...@gmx.net> wrote:
> On Tuesday, June 04, 2013 7:47 PM, James M Snell wrote:
>> Thx, will take a look at those. Any of you json-ld experts wanna take
>> a stab at a draft, non-normative context doc?
>
> As promised, I create a context. You can find it here:
> https://raw.github.com/lanthaler/json-activity/master/context.jsonld
>

Excellent :-)

> The creation was more or less straightforward. The only problem I had was
> how to interpret the "alias" property. I don't really understand what the
> spec is saying. Is it a (possibly relative) IRI or not? I assumed it is in
> this version.
>

The alias is a local identifier. In my use cases, this is typically
something like "@public". Let's define it strictly to be a possibly
relative IRI.

> I use the following URL as the prefix for all properties (namespace URL)
> http://activitystrea.ms/spec/2.0/#
>
> The hash at the end allows to put a machine-readable description of all
> properties in a single file. Here's a first (still very rough) version of
> such a machine-readable description in JSON-LD:
> https://raw.github.com/lanthaler/json-activity/master/vocab.jsonld
>
> I think if AS 2.0 is going to adopt JSON-LD, it should be required to
> include a reference to a context (probably hosted somewhere on a
> activitystrea.ms) to signal that, e.g.:
>
> "@context": "http://activitystrea.ms/spec/2.0/"
>
> This can be safely ignored by all clients not using a document as JSON-LD.
>

Well, the goal is json-ld compatibility, not necessarily json-ld
dependency. Perhaps we can call this out in the spec as a MAY include.

Definitely appreciate the work!

- James

>
> Hope this helps,
> Markus
>
>
> --
> Markus Lanthaler
> @markuslanthaler
>

[Markus Lanthaler]

On Monday, June 10, 2013 6:39 PM, James M Snell wrote:

> On Mon, Jun 10, 2013 at 6:58 AM, Markus Lanthaler wrote:
>> The creation was more or less straightforward. The only problem I had was
>> how to interpret the "alias" property. I don't really understand what the
>> spec is saying. Is it a (possibly relative) IRI or not? I assumed it is
>> in this version.
>>
>
> The alias is a local identifier. In my use cases, this is typically
> something like "@public". Let's define it strictly to be a possibly
> relative IRI.

But it isn't intended to be resolved to an absolute IRI, right?

>> I use the following URL as the prefix for all properties (namespace URL)
>> http://activitystrea.ms/spec/2.0/#
>>
>> The hash at the end allows to put a machine-readable description of all
>> properties in a single file. Here's a first (still very rough) version of
>> such a machine-readable description in JSON-LD:
>> https://raw.github.com/lanthaler/json-activity/master/vocab.jsonld
>>
>> I think if AS 2.0 is going to adopt JSON-LD, it should be required to
>> include a reference to a context (probably hosted somewhere on a
>> activitystrea.ms) to signal that, e.g.:
>>
>> "@context": "http://activitystrea.ms/spec/2.0/"
>>
>> This can be safely ignored by all clients not using a document as
JSON-LD.
>
> Well, the goal is json-ld compatibility, not necessarily json-ld
> dependency. Perhaps we can call this out in the spec as a MAY include.

Yeah, that's how I see it as well. However, without linking to the context,
no off-the-shelf JSON-LD processor would be able to make sense out of the
data.

This doesn't add a dependency on JSON-LD though. The structure of the data
etc. will still be defined by the AS spec and everything can still be
interpreted without even knowing that it is JSON-LD or what that @context is
about.


--
Markus Lanthaler
@markuslanthaler

[James M Snell]

On Jun 11, 2013 3:43 PM, "Markus Lanthaler" <markus.l...@gmx.net> wrote:
>
[snip]

> >>
> >
> > The alias is a local identifier. In my use cases, this is typically
> > something like "@public". Let's define it strictly to be a possibly
> > relative IRI.
>
> But it isn't intended to be resolved to an absolute IRI, right?
>
>

Not in any case I am aware of.

> >> I use the following URL as the prefix for all properties (namespace URL)
> >>   http://activitystrea.ms/spec/2.0/#
> >>
> >> The hash at the end allows to put a machine-readable description of all
> >> properties in a single file. Here's a first (still very rough) version of
> >> such a machine-readable description in JSON-LD:
> >>   https://raw.github.com/lanthaler/json-activity/master/vocab.jsonld
> >>
> >> I think if AS 2.0 is going to adopt JSON-LD, it should be required to
> >> include a reference to a context (probably hosted somewhere on a
> >> activitystrea.ms) to signal that, e.g.:
> >>
> >>   "@context": "http://activitystrea.ms/spec/2.0/"
> >>
> >> This can be safely ignored by all clients not using a document as
> JSON-LD.
> >
> > Well, the goal is json-ld compatibility, not necessarily json-ld
> > dependency. Perhaps we can call this out in the spec as a MAY include.
>
> Yeah, that's how I see it as well. However, without linking to the context,
> no off-the-shelf JSON-LD processor would be able to make sense out of the
> data.
>
> This doesn't add a dependency on JSON-LD though. The structure of the data
> etc. will still be defined by the AS spec and everything can still be
> interpreted without even knowing that it is JSON-LD or what that @context is
> about.
>

Please correct me if I'm wrong,  but it's possible to link the @context using a link header too, correct?

[Markus Lanthaler]

On Wednesday, June 12, 2013 5:56 AM, James M Snell wrote:

On Jun 11, 2013 3:43 PM, "Markus Lanthaler" wrote:
>>
>[snip]
>> >>
>> >
>> > The alias is a local identifier. In my use cases, this is typically
>> > something like "@public". Let's define it strictly to be a possibly
>> > relative IRI.
>>
>> But it isn't intended to be resolved to an absolute IRI, right?
>>
>>
> Not in any case I am aware of.

That's what I figured. In that case it doesn't make much sense to
type-coerce it to @id. I've just updated the context accordingly.

>> > Well, the goal is json-ld compatibility, not necessarily json-ld
>> > dependency. Perhaps we can call this out in the spec as a MAY include.
>>
>> Yeah, that's how I see it as well. However, without linking to the
context,
>> no off-the-shelf JSON-LD processor would be able to make sense out of the
>> data.
>>
>> This doesn't add a dependency on JSON-LD though. The structure of the
data
>> etc. will still be defined by the AS spec and everything can still be
>> interpreted without even knowing that it is JSON-LD or what that @context
is
>> about.
>
> Please correct me if I'm wrong, but it's possible to link the
> @context using a link header too, correct?

Yes, that's correct. It has a number of downsides though; the most important
probably being that setting the link header is much more complicated and
that it is easy to "lose" that information when passing an AS response
around. You can of course take the link header and add it to the AS response
before passing it around. But wouldn't it be much simpler to do that when
the AS response is generated? What are the disadvantages you see in that
approach?



--
Markus Lanthaler
@markuslanthaler

[Owen Shepherd]

As someone interested in this work, I have a query to raise: Why the unification of verbs and objectTypes?

I only see the following come out of this:

• Confusion between objects and verbs which are homonyms. The simplest example I can give of this, which is also incredibly common, is the word "post" 
  
• Less information for processors to work with: if I have an object of "type":"http://example.org/foo", I have no information as to whether this is an activity or an object without seeing its' schema.
• Incompatibility with existing implementations

Being as JSON-LD actually permits keeping both the objectType and verb properties (and will even understand them), I see no reason for changing this just for the sake of change.

My opinion is that it would be best to maintain backwards compatibility as much as possible, in the sense of backwards compatibility that existing documents remain compatible and valid. It might also make sense to define a way of "encoding" the added data so it can pass through an AS1 transport losslessly.

Besides the one change, I don't see any other incompatible changes in your proposed specification in that sense?