Closed elf-pavlik closed 9 years ago
@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:
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.
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"
}
]
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.
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.
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
or could define prefix instead of using
@vocab
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