require explicit @vocab or define prefix if custom terms used, to remove current "@vocab": "_:" hack

[elf-pavlik]

I would like to propose requiring explicit @vocab in JSON-LD context, wherever data includes terms other than included in AS2.0 v2 context or already mapped to full URIs in local context. Those URIs only SHOULD (not MUST) to return useful description of a term - HTTP 404 also conforming in this case!

http://jasnell.github.io/w3c-socialwg-activitystreams/activitystreams2.html#extension-round-trip

would change to

{
  "@context": [
    "http://www.w3.org/ns/activitystreams",
    {"@vocab": "http://example.org/ns/"}
  ],
  "@type": "Note",
  "content": "This is a simple note",
  "foo": 123,
  "bar": 321
}

or could define prefix instead of using@vocab

{
  "@context": [
    "http://www.w3.org/ns/activitystreams",
    {"ex": "http://example.org/ns/"}
  ],
  "@type": "Note",
  "content": "This is a simple note",
  "ex:foo": 123,
  "ex:bar": 321
}

and prevent error prone hack with blank node label _:bar, especially when it gets used in aggregated streams which should NOT consider both bar properties as same one!

http://jasnell.github.io/w3c-socialwg-activitystreams/activitystreams2.html#aggregation-of-extensions

I remember @sandhawke also expressing concern about AS2 use of "@vocab": "_:" hack!

seeAlso: #108

[gobengo]

@elf-pavlik In your opinion, what is the best way to make a context document that extends AS?

This is what I'm working with so far:

• jsonld - http://livefyre-cdn.s3.amazonaws.com/libs/livefyre-activity-vocabulary/v0.0.0/context.json
• html - http://livefyre.github.io/activity-vocabulary/
• in the playground - http://json-ld.org/playground/#startTab=tab-expanded&json-ld=http%3A%2F%2Flivefyre-cdn.s3.amazonaws.com%2Flibs%2Flivefyre-activity-vocabulary%2Fv0.0.0%2Fcontext.json

[jasnell]

I'm -1 on this. While the "@vocab": "_:" bit is a bit of a hack, it allows undeclared extensions to survive JSON-LD expansion in tact which is still useful. Further, it requires that extensions are explicit with their namespaces given the fact that "@vocab":"_:" is part of the normative context (e.g. an extension is not permitted to override the default vocabulary. Granted, it's not the most elegant solution from a purely RDF point of view, but that's ok in my opinion.

[elf-pavlik]

To illustrate my concern better, I will modify example from Aggregation of Extensions. Let's also assume that both publishers served documents with application/activity+json relying on implicit JSON-LD @context we discuss in #132

AS2.0 published by ACME

{
  "@type": "Note",
  "content": "This is a simple note",
  "foo": 123
}

AS2.0 document published by Baz Inc.

{
  "@type": "Note",
  "content": "This is another note",
  "foo": "2015-12-11T12:34:56Z"
}

Once we merge them into single document, we get following in JSON-LD playground

Compacted:

{
  "@context": "http://www.w3.org/ns/activitystreams",
  "@graph": [{
    "@type": "Note",
    "content": "This is a simple note",
    "foo": 123
  }, {
    "@type": "Note",
    "content": "This is another note",
    "foo": "2015-12-11T12:34:56Z"
  }]
}

Expanded:

[
  {
    "@type": [
      "http://www.w3.org/ns/activitystreams#Note"
    ],
    "http://www.w3.org/ns/activitystreams#content": [
      {
        "@value": "This is a simple note"
      }
    ],
    "_:foo": [
      {
        "@value": 123
      }
    ]
  },
  {
    "@type": [
      "http://www.w3.org/ns/activitystreams#Note"
    ],
    "http://www.w3.org/ns/activitystreams#content": [
      {
        "@value": "This is another note"
      }
    ],
    "_:foo": [
      {
        "@value": "2015-12-11T12:34:56Z"
      }
    ]
  }
]

As we see, consumer ends up with a data where property _:foo has completely different meaning and possibly also data type for different objects. In such case we may need to clarify handling of all the _:foo properties.

We could also avoid such situations by adding requirement in direction of:

Publishers using properties not defined in ActivityStreams 2.0 Vocabylary, and not prefixing them as explained in Extensibility section, MUST include explicit @vocab in JSON-LD @context. This will set namespace which will act as prefix for all the properties not defined by normative AS2.0 JSON-LD @context, as well as those not using specific prefixes as explained in Extensibility section.

IMO we should still also recommend for consumers not using JSON-LD Algorithms, to at least expand Compact IRIs as seen in current working draft as well as expand properties without prefixes with namespace from @vocab which I suggest in this issue. Otherwise consumer will still end up with incorrect handling of foo property.

[
  { 
    "@type": "Note",
    "content": "This is a simple note",
    "foo": 123
  }, {
    "@type": "Note",
    "content": "This is another note",
    "foo": "2015-12-11T12:34:56Z"
  }
]

[jasnell]

I'm still -1 on this and I don't see any issue with your example. If the foo extension is undefined in any context and gets mapped to _:foo, then implementers simply need to be aware that collisions can happen. It's not that big of a deal.

[sandhawke]

RESOLVED: Keep the spec as is: namespaces SHOULD be declared, unknown terms are ignored but passed onto the application as blank nodes (closes #134)

[sandhawke]

+1 jasnell strengthen language in the spec about why you should give URLs to extension terms!

[elf-pavlik]

I would see in place a strong and to the point explanation, something in direction:

Given property foo - not defined by AS2 vocabulary and which does not have mapping to full URI, consuming systems MUST consider foo as completely different property (foo != foo) for any two AS documents, even if those two documents come from the same publisher! If you want consuming systems to interpret some property as the same one across multiple document, make sure that it has mapping to full URI, which makes it globally unique and possible to distinguish across any number of documents from any number of publishers.