New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

can media type specify default JSON-LD context? #132

Closed
elf-pavlik opened this Issue May 29, 2015 · 17 comments

Comments

Projects
None yet
6 participants
@elf-pavlik
Member

elf-pavlik commented May 29, 2015

Note: I've left out @context from all AS examples because we agreed when missing, this is implied to be "http://www.w3.org/ns/activitystreams".
http://rhiaro.co.uk/2015/05/micropubbing-with

Can media type specify default JSON-LD context? e.g.

@dret @sandhawke

@dret

This comment has been minimized.

Show comment
Hide comment
@dret

dret May 29, 2015

Member

i thought one goal was to always allow AS2 to be processed by generic JSON-LD code. wouldn't that be compromised if the context is not explicit, but implicit?

Member

dret commented May 29, 2015

i thought one goal was to always allow AS2 to be processed by generic JSON-LD code. wouldn't that be compromised if the context is not explicit, but implicit?

@akuckartz

This comment has been minimized.

Show comment
Hide comment
@akuckartz

akuckartz May 29, 2015

This does not answer the question, but I do not like such additional media types. application/ld+json is enough and that does not specify a default JSON-LD context.

akuckartz commented May 29, 2015

This does not answer the question, but I do not like such additional media types. application/ld+json is enough and that does not specify a default JSON-LD context.

@elf-pavlik

This comment has been minimized.

Show comment
Hide comment
@elf-pavlik

elf-pavlik May 29, 2015

Member

@dret myself I would also prefer explicit JSON-LD but if we already define media types and create normative contexts for them, why not to formalize it somehow?

@akuckartz as you know I also currently prefer simply using application/ld+json with profile parameter. still to my understanding some people in WG would like to have JSON-LD context implied which would make using JSON-LD media type impossible... maybe we'll get there in AS3.0

Member

elf-pavlik commented May 29, 2015

@dret myself I would also prefer explicit JSON-LD but if we already define media types and create normative contexts for them, why not to formalize it somehow?

@akuckartz as you know I also currently prefer simply using application/ld+json with profile parameter. still to my understanding some people in WG would like to have JSON-LD context implied which would make using JSON-LD media type impossible... maybe we'll get there in AS3.0

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell May 29, 2015

Collaborator

You can still use application/ld+json if you wish. The application/activity+json media type implies a very specific profile of JSON-LD -- that is, JSON-LD in compacted form using the normative context definition. When using application/activity+json, the context can be implicit if you're not using any extensions.

Collaborator

jasnell commented May 29, 2015

You can still use application/ld+json if you wish. The application/activity+json media type implies a very specific profile of JSON-LD -- that is, JSON-LD in compacted form using the normative context definition. When using application/activity+json, the context can be implicit if you're not using any extensions.

@elf-pavlik

This comment has been minimized.

Show comment
Hide comment
@elf-pavlik

elf-pavlik May 29, 2015

Member

The application/activity+json media type implies a very specific profile of JSON-LD -- that is, JSON-LD in compacted form using the normative context definition. When using application/activity+json, the context can be implicit if you're not using any extensions.

@dret does it sound for you, as something that media type could mandate or at least capture?

@jasnell to my understanding application/stream+json implies (can imply) JSON-LD context with filename in this repo activitystreams1-context.jsonld

BTW how would such implicit contexts address #69 ?

Member

elf-pavlik commented May 29, 2015

The application/activity+json media type implies a very specific profile of JSON-LD -- that is, JSON-LD in compacted form using the normative context definition. When using application/activity+json, the context can be implicit if you're not using any extensions.

@dret does it sound for you, as something that media type could mandate or at least capture?

@jasnell to my understanding application/stream+json implies (can imply) JSON-LD context with filename in this repo activitystreams1-context.jsonld

BTW how would such implicit contexts address #69 ?

@dret

This comment has been minimized.

Show comment
Hide comment
@dret

dret May 30, 2015

Member

yes, if the processing model for the media type says that the assumption is that there is an implicit context, then this is how it must be processed. just to be clear i would add language about saying what to do if the context is there (probably ok), and what to do if any of the context prefixes is declared, but with a different URI than the implicit ones.

Member

dret commented May 30, 2015

yes, if the processing model for the media type says that the assumption is that there is an implicit context, then this is how it must be processed. just to be clear i would add language about saying what to do if the context is there (probably ok), and what to do if any of the context prefixes is declared, but with a different URI than the implicit ones.

@elf-pavlik

This comment has been minimized.

Show comment
Hide comment
@elf-pavlik

elf-pavlik May 30, 2015

Member

just to be clear i would add language about saying what to do if the context is there (probably ok), and what to do if any of the context prefixes is declared, but with a different URI than the implicit ones.

@dret I don't fully understand what do your refer to as context prefixes? Latest editors draft only defines as: 'prefix' in JSON-LD context and removes all the other ones, previously included in http://www.w3.org/TR/2015/WD-activitystreams-core-20150129/#compact-iris

@jasnell we may also need anticipate cases where publishing party will assume the implicit context for given media type and just include explicit one with default language:

{
  "@context": { "@language": "en" },
  ...
}

In such case we can't just check if data has @context or not, but need to verify if it includes URI of the normative v1 or v2 JSON-LD context.

Another case, Content-Type: application/activity+json with only context(s) intended as additional overwrite of the AS normative context:

{
  "@context": "https://w3id.org/plp/v1",
  ...
}

Should consuming parties process it as

{
  "@context": [
    "http://www.w3.org/ns/activitystreams",
    "https://w3id.org/plp/v1"
  ],
  ...
}

?

Member

elf-pavlik commented May 30, 2015

just to be clear i would add language about saying what to do if the context is there (probably ok), and what to do if any of the context prefixes is declared, but with a different URI than the implicit ones.

@dret I don't fully understand what do your refer to as context prefixes? Latest editors draft only defines as: 'prefix' in JSON-LD context and removes all the other ones, previously included in http://www.w3.org/TR/2015/WD-activitystreams-core-20150129/#compact-iris

@jasnell we may also need anticipate cases where publishing party will assume the implicit context for given media type and just include explicit one with default language:

{
  "@context": { "@language": "en" },
  ...
}

In such case we can't just check if data has @context or not, but need to verify if it includes URI of the normative v1 or v2 JSON-LD context.

Another case, Content-Type: application/activity+json with only context(s) intended as additional overwrite of the AS normative context:

{
  "@context": "https://w3id.org/plp/v1",
  ...
}

Should consuming parties process it as

{
  "@context": [
    "http://www.w3.org/ns/activitystreams",
    "https://w3id.org/plp/v1"
  ],
  ...
}

?

@dret

This comment has been minimized.

Show comment
Hide comment
@dret

dret May 30, 2015

Member

@elf-pavlik, "I don't fully understand what do your refer to as context prefixes?": what i meant are the prefixes assumed to be defined as described here: http://www.w3.org/TR/2015/WD-activitystreams-core-20150129/#compact-iris, but if that has now been reduced to one prefix, then i should have used the singular. but the question remains: what's the processing model if a document is redefining this prefix in a way that is different from the default?

Member

dret commented May 30, 2015

@elf-pavlik, "I don't fully understand what do your refer to as context prefixes?": what i meant are the prefixes assumed to be defined as described here: http://www.w3.org/TR/2015/WD-activitystreams-core-20150129/#compact-iris, but if that has now been reduced to one prefix, then i should have used the singular. but the question remains: what's the processing model if a document is redefining this prefix in a way that is different from the default?

@elf-pavlik

This comment has been minimized.

Show comment
Hide comment
@elf-pavlik

elf-pavlik May 30, 2015

Member

good point @dret!
IMO together with #108 and #134 we have clear need for very concrete strategy on how we use JSON-LD contexts and how processing will differ for application/activity+json / application/stream+json and application/ld+json

Member

elf-pavlik commented May 30, 2015

good point @dret!
IMO together with #108 and #134 we have clear need for very concrete strategy on how we use JSON-LD contexts and how processing will differ for application/activity+json / application/stream+json and application/ld+json

@dret

This comment has been minimized.

Show comment
Hide comment
@dret

dret May 30, 2015

Member

imho, anything that means that people cannot use off-the-shelf (i.e., non-AS-aware) JSON-LD components should be avoided. i don't know if many/most JSON-LD components allow the "injection" of external contexts, but if they do, then this is kind of ok. but it's still a horrible hack, imho, because this does go down a path where AS is not just JSON-LD, but some variant that requires special processing.

Member

dret commented May 30, 2015

imho, anything that means that people cannot use off-the-shelf (i.e., non-AS-aware) JSON-LD components should be avoided. i don't know if many/most JSON-LD components allow the "injection" of external contexts, but if they do, then this is kind of ok. but it's still a horrible hack, imho, because this does go down a path where AS is not just JSON-LD, but some variant that requires special processing.

@elf-pavlik

This comment has been minimized.

Show comment
Hide comment
@elf-pavlik

elf-pavlik May 30, 2015

Member

JSON-LD 1.0 spec defines way for using application/json with context defined in HTTP header http://www.w3.org/TR/json-ld/#interpreting-json-as-json-ld rel="http://www.w3.org/ns/json-ld#context"

imho, anything that means that people cannot use off-the-shelf (i.e., non-AS-aware) JSON-LD components should be avoided.

why do we need custom application/activity+json media type in such case? (back to #52 ...)

Member

elf-pavlik commented May 30, 2015

JSON-LD 1.0 spec defines way for using application/json with context defined in HTTP header http://www.w3.org/TR/json-ld/#interpreting-json-as-json-ld rel="http://www.w3.org/ns/json-ld#context"

imho, anything that means that people cannot use off-the-shelf (i.e., non-AS-aware) JSON-LD components should be avoided.

why do we need custom application/activity+json media type in such case? (back to #52 ...)

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Jun 3, 2015

Collaborator

AS2 is not just JSON-LD, it's JSON-LD plus a number of additional constraints. The application/activity+json media type is used to indicate that those additional constraints are in effect. Yes, you can still treat it as straightforward JSON-LD, and yes, it's best if implementers make the @context explicit in order to maximize interoperability with existing JSON-LD stacks as well as performance, but when the document is served up as application/activity+json, there are certain assumptions that can be made.

Collaborator

jasnell commented Jun 3, 2015

AS2 is not just JSON-LD, it's JSON-LD plus a number of additional constraints. The application/activity+json media type is used to indicate that those additional constraints are in effect. Yes, you can still treat it as straightforward JSON-LD, and yes, it's best if implementers make the @context explicit in order to maximize interoperability with existing JSON-LD stacks as well as performance, but when the document is served up as application/activity+json, there are certain assumptions that can be made.

@elf-pavlik

This comment has been minimized.

Show comment
Hide comment
@elf-pavlik

elf-pavlik Jun 3, 2015

Member

I understand that this registration: http://jasnell.github.io/w3c-socialwg-activitystreams/activitystreams2.html#media-type

Says that document with Content-Type: application/activity+json conforms to http://www.w3.org/TR/activitystreams-core/

In this spec we find (same as in latest editor's draft)

The serialized JSON form of an Activity Streams 2.0 document must be consistent with what would be produced by the standard JSON-LD 1.0 Processing Algorithms and API [JSON-LD-API] Compaction Algorithm using, at least, the normative JSON-LD @context definition provided here. Implementations may augment the provided @context with additional @context definitions but must not override or change the normative context. Implementations may also include in the serialized JSON document additional properties and values not defined in the JSON-LD @context with the understanding that any such properties will likely be unsupported and ignored by consuming implementations that use the standard JSON-LD algorithms. See the Extensibility section for more information on handling extensions within Activity Streams 2.0 documents.

http://jasnell.github.io/w3c-socialwg-activitystreams/activitystreams2.html#syntaxconventions

I agree that this part suggest an implicit JSON-LD @context

The serialized JSON form of an Activity Streams 2.0 document must be consistent with what would be produced by the standard JSON-LD 1.0 Processing Algorithms and API [JSON-LD-API] Compaction Algorithm using, at least, the normative JSON-LD @context definition provided here

Could we add stronger statement with MUST? Something in direction of:

In cases where consumer receives Activity Streams 2.0 document (Content-Type: application/activity+json) with no explicit JSON-LD @context, it MUST assume Activity Streams 2.0 normative JSON-LD @context definition

We should also possibly clearly explain, or simply forbid (MUST NOT) scenario where Link in HTTP Header sets the JSON-LD @context

Member

elf-pavlik commented Jun 3, 2015

I understand that this registration: http://jasnell.github.io/w3c-socialwg-activitystreams/activitystreams2.html#media-type

Says that document with Content-Type: application/activity+json conforms to http://www.w3.org/TR/activitystreams-core/

In this spec we find (same as in latest editor's draft)

The serialized JSON form of an Activity Streams 2.0 document must be consistent with what would be produced by the standard JSON-LD 1.0 Processing Algorithms and API [JSON-LD-API] Compaction Algorithm using, at least, the normative JSON-LD @context definition provided here. Implementations may augment the provided @context with additional @context definitions but must not override or change the normative context. Implementations may also include in the serialized JSON document additional properties and values not defined in the JSON-LD @context with the understanding that any such properties will likely be unsupported and ignored by consuming implementations that use the standard JSON-LD algorithms. See the Extensibility section for more information on handling extensions within Activity Streams 2.0 documents.

http://jasnell.github.io/w3c-socialwg-activitystreams/activitystreams2.html#syntaxconventions

I agree that this part suggest an implicit JSON-LD @context

The serialized JSON form of an Activity Streams 2.0 document must be consistent with what would be produced by the standard JSON-LD 1.0 Processing Algorithms and API [JSON-LD-API] Compaction Algorithm using, at least, the normative JSON-LD @context definition provided here

Could we add stronger statement with MUST? Something in direction of:

In cases where consumer receives Activity Streams 2.0 document (Content-Type: application/activity+json) with no explicit JSON-LD @context, it MUST assume Activity Streams 2.0 normative JSON-LD @context definition

We should also possibly clearly explain, or simply forbid (MUST NOT) scenario where Link in HTTP Header sets the JSON-LD @context

@akuckartz

This comment has been minimized.

Show comment
Hide comment
@akuckartz

akuckartz Jul 8, 2015

How was this resolved?

akuckartz commented Jul 8, 2015

How was this resolved?

@dret

This comment has been minimized.

Show comment
Hide comment
@dret

dret Jul 9, 2015

Member

personally, i am not even sure this one is well-defined in JSON-LD. json-ld/json-ld.org#391 is where i have asked this question, and maybe the JSON-LD experts can help us to better understand what exactly it means to have an implicit context.

Member

dret commented Jul 9, 2015

personally, i am not even sure this one is well-defined in JSON-LD. json-ld/json-ld.org#391 is where i have asked this question, and maybe the JSON-LD experts can help us to better understand what exactly it means to have an implicit context.

@lanthaler

This comment has been minimized.

Show comment
Hide comment
@lanthaler

lanthaler Jul 9, 2015

Member

AS2 is not just JSON-LD, it's JSON-LD plus a number of additional constraints.

For exactly such cases we introduced the profile media type parameter. It allows you to communicate additional constraints. There's also a profile URI registry maintained by IANA so that you can register new profiles.

The application/activity+json media type is used to indicate that those additional constraints are in effect.

As said, you can use the profile parameter instead. That enables the usage of existing JSON-LD tools and libraries.

Yes, you can still treat it as straightforward JSON-LD

No, you can't if there's no explicit context.

Member

lanthaler commented Jul 9, 2015

AS2 is not just JSON-LD, it's JSON-LD plus a number of additional constraints.

For exactly such cases we introduced the profile media type parameter. It allows you to communicate additional constraints. There's also a profile URI registry maintained by IANA so that you can register new profiles.

The application/activity+json media type is used to indicate that those additional constraints are in effect.

As said, you can use the profile parameter instead. That enables the usage of existing JSON-LD tools and libraries.

Yes, you can still treat it as straightforward JSON-LD

No, you can't if there's no explicit context.

@akuckartz

This comment has been minimized.

Show comment
Hide comment
@akuckartz

akuckartz Jul 21, 2015

The Social Web WG is on a path of incompatibility with JSON-LD. Very bad.

akuckartz commented Jul 21, 2015

The Social Web WG is on a path of incompatibility with JSON-LD. Very bad.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment