Default namespace for plain old JSON in 1.2 (?)

[melvincarvalho]

Thinking about JSON-LD v.next one thing that comes up quite often in the developer experience is that it's quite a heavy lift for users starting out to create a context, a vocab, and adding URI, for every predicate (ie json key/attribute)

This could be mitigated by having a default namespace for keys that are "plain old JSON"

Or a parser could "make up" a namespace to translate keys into triples, and make them portable, queryable etc.

This can be done using @base too, but the issue with this is that everyone will make up a different base

What would be helpful would be a default namespace at spec level so that different implementers that want this feature would have a consistency of data

It would not even need to be mandated, even something that is slightly hinted at could be the basis of allowing parsers to consume much more data in the wild, as well as data that's not perfectly formed (principle of tolerance). It would be seamlessly backwards compatible

It would just need to be something that consensus could be formed around, in such a way that no one has a hard objection to it. If you dont want to use it, you dont have to.

Example: urn:json:key:foo -- though that might be a bit verbose and the IETF may take issue with "json" not being an organization

I actually really dont mind at all what form it takes, just as long as it's hinted at in the spec, in a primer, or even in a github issue. Then it's possible to write parsers with slightly more peace of mind

I wonder, could this be something for consideration in JSON-LD 1.2?

Edit: putting a hint in the best practices could be a good solution here

[gkellogg]

IIRC, we discussed a default context to set things like this in the WG. It may be a likely entry in the JSON-LD Best Practices document. Otherwise, the group could take it up again when re-active.

In my opinion, using the document base is consistent with practice in Turtle/N3:

@prefix : <#> .

[ :foo "bar" ] .

In JSON-LD, that can be done as follows:

{
  "@context": {
    "@vocab": "#"
  },
  "foo": "bar"
}

This usage is described in Using the Document Base for the Default Vocabulary.

[melvincarvalho]

@gkellogg thanks, that is indeed consistent with turtle etc.

I could live with this

Slight concern might be that the predicates would then be relative to the document themselves, so therefore, no two predicates would in theory match, unless using inferencing

My personal mental model is that a JSON key is "just a name" or "just a string" so bears most similarity to a urn:

Having # as a base might also throw up an edge case with the empty case "" with iirc doesnt play well with qnames, I could be wrong

Certainly it's something that can be defered, but at the same time, if there was rough consensus parsers could take advantage, in the interim, and be able to consume more (perhaps an OOM more) JSON

[pchampin]

Slight concern might be that the predicates would then be relative to the document themselves, so therefore, no two predicates would in theory match, unless using inferencing

I consider this as a feature rather than a bug.

Assuming that two people using the same string actually mean the same thing is dangerously oversimplifying, as we all know. Baking in this naive assumption as a default behavior looks like a terrible ant-ipattern.

[melvincarvalho]

So I thought about this a bit more, and I must say that '#' is growing on me quite a bit

I have a slight concern, though

What if, say, #this is already a JSON-LD object in the document

Now, would that go against the idea that it's 'just a JSON key' because it would now have predicates and objects associated with it?

ie # and json keys are potentially different animals in some contexts, so would there be some advantage to having an alternative fallback default?