Dealing with other people's @ prefixed terms

[BigBlueHat]

Relates a bit to #188 and other prefix handling issues in this repo...and also some in the syntax repo.

I began building a context file for the Microsoft Graph which uses OData which uses it's own @odata.* prefixed terms. This works relatively well with OData 4.0 (or earlier) JSON documents and a JSON-LD 1.0 processor.

However, given our resolution in w3c/json-ld-syntax#16 does that change mean it will become impossible to build context files for OData 4.0 JSON documents? ...because if so...I think we need to reconsider...

More troublesome is the fact that in the OData 4.01 spec they are deprecating the @odata prefix entirely:

Note that in OData 4.0 the metadata format parameter was prefixed with “odata.”. Payloads with an OData-Version header equal to 4.0 MUST include the “odata.” prefix. Payloads with an OData-Version header equal to 4.01 or greater SHOULD NOT include the “odata.” prefix.

Which likely mean's we'll have full-on term conflicts between @context, @type, and @id (at least). 😢

So, given the OData 4.0 @odata prefix (which is how Microsoft Graph is written now), is it possible to build a JSON-LD context file and use a JSON-LD 1.1 processor? Or did our resolution in w3c/json-ld-syntax#16 change that?

[BigBlueHat]

Unsurprisingly this has been previously discussed (circa 2013): https://json-ld.org/minutes/2013-10-08/

The OData 4.01 spec is still in draft status (as of late September), so perhaps there's still hope for avoiding this collision/conflict of ecosystems and instead birthing opportunities for developers. I'd certainly prefer that...and hopefully Microsoft and other OData developers would as well.

[BigBlueHat]

Here's a summary post from the 2013 era WG which highlights the (then) interest to work together, and how JSON-LD was (thanks to the context object/file) capable of enhancing OData JSON documents: https://lists.w3.org/Archives/Public/public-rdf-comments/2013Oct/0073.html

I'd hate to loose that capability in JSON-LD 1.1, and (obviously) would like to re-liaison with the OData folks to avoid conflicts in the forthcoming OData 4.01 spec.

So...back to the key topic. 😉 Does our change about @ prefix prevent the use of OData 4.0 (or earlier) and JSON-LD 1.1 together (as far as anyone can tell)?

[gkellogg]

Our change does prevent the use of other @-prefixed terms, to preserve our own space for keywords in the future. We've documented issues with errors such as @iri, which weren't caught.

Current algorithm behavior is to warn and ignore. We should discuss; the landscape's changed quite a bit since pre-1.0, when JSON-LD was looking for traction.

[iherman]

Current algorithm behavior is to warn and ignore

To be honest, I do not know what else we can do. The @iri example shows that going completely silent is not a good idea. I would think that processors may have flags, or some other means, to suppress warnings, but that is an implementation issue.

[akuckartz]

Is the current OData community aware of this issue?

[BigBlueHat]

Is the current OData community aware of this issue?

Which one? The change in JSON-LD 1.1 or the change in OData 4.01 which would make use with JSON-LD 1.0 or 1.1 impossible?

Both are concerning, but the OData 4.01 is the most concerning...

[BigBlueHat]

The @iri example shows that going completely silent is not a good idea.

Do you have a link to any other reading about "the @iri example"?

[dlongley]

One somewhat hacky solution here would be to permit keyword namespacing: @foo.bar to grandparent in @odata.*. So, you can use @ for keys as long as there is also one or more characters that follow and then a period establishing a namespace. Then we would just agree to never put a . in any standard JSON-LD keywords moving forward.

[BigBlueHat]

@dlongley that would certainly work for all existing OData content (afaik), and perhaps that major OData change can be removed from the OData 4.01 spec as it's still in draft--something I'll try to connect with OData folks about.

@gkellogg does the proposal above sound terribly insane? 😉

[iherman]

Do you have a link to any other reading about "the @iri example"?

I just referred to the comment of @gkellogg (#191 (comment)), I guess he may have a reference.

[gkellogg]

The @iri Usage was found in a schema.org example, which was since corrected. It is what prompted me to push this issue.

[gkellogg]

@dlongley that would certainly work for all existing OData content (afaik), and perhaps that major OData change can be removed from the OData 4.01 spec as it's still in draft--something I'll try to connect with OData folks about.

@gkellogg does the proposal above sound terribly insane? 😉

It’s hacky, but not insane. Perhaps if we considered a potential keyword to be composed of an @ followed by one or more alpha-numeric characters (not sure how to define those in Unicode), which would exclude anything with a punctuation mark from being considered a potential keyword, and allow it.

Less hacky, but perhaps overwrought, would be some explicit way to identify that a set of specific keyword-like strings should be allowed.

[BigBlueHat]

The @iri Usage was found in a schema.org example, which was since corrected. It is what prompted me to push this issue.

Ah. I think it was @url actually...and you found it and I fixed it. 😜 schemaorg/schemaorg#2036 (who knew?!)

[BigBlueHat]

@gkellogg I think I like the "alpha-numeric characters" option best, though limiting it to just . as a separator (and avoiding risk of folks attempting @foo:bar 😖) might be best. Certainly warrants discussion as this won't be the last time we run into this...

[gkellogg]

Proposal: let's reserve (as in SHOULD NOT and warnings issued) anything of the pattern @[a-zA-Z]+ as things that might be JSON-LD keywords some day. This would disallow using @odata, but would allow things like @odata.foo, @123, or even just @.

This would update principally Create Term Definition step 5:

... If term has the form of a keyword (i.e., it begins with "@" followed by one or more characters from the set "a-z" or "A-Z" (U+0061 through U+007A and U+0041 through U+005A)), return; processors SHOULD generate a warning.

It also affects 14.3, 16.3, and some bits if IRI Expansion along with 3.1 and 9.1 of the syntax document.

It might be worth defining the keyword expansion space to be this range, and then just refer to strings in this space as SHOULD be avoided and SHOULD generate warnings.