Drop @base and @vocab about json-ld.org

[msporny]

The discussion thread is here:

http://lists.w3.org/Archives/Public/public-linked-json/2011Sep/0008.html

[gkellogg]

RESOLVED in http://json-ld.org/minutes/2011-09-06/#topic-3 keep @base and @vocab as separate concepts within JSON-LD.

[lanthaler]

I couldn't find anything in the minutes. What were the reasons/arguments to keep both, @base and @vocab?

[gkellogg]

Sorry, I guess the discussion wasn't adequately scribed. I'll update the issue.

Basically, the serve two different purposes: @base relates to the document itself, and @vocab to the vocabulary used. Unlike Turtle, the empty prefix doesn't really work in JSON, due to the need to enclose the property in quotes.

Gregg Kellogg

Sent from my iPad

On Sep 7, 2011, at 4:35 AM, "Markus Lanthaler" [email protected] wrote:

I couldn't find anything in the minutes. What were the reasons/arguments to keep both, @base and @vocab?

Reply to this email directly or view it on GitHub:
#26 (comment)

[msporny]

The discussion and resolution can be found here:

http://json-ld.org/minutes/2011-09-06/#topic-3

[lanthaler]

I understand how they are used and what the differences are. But I still think they add unnecessary complexity without any clear advantages. It makes it very difficult to read a JSON-LD document since one have to keep in mind two (three?) base IRIs. Is this really necessary? I wouldn't even be opposed to drop both, @base and @vocab.

-----Original Message-----
From: Manu Sporny [mailto:reply+i-1540845-
[email protected]]
Sent: Sunday, September 11, 2011 10:30 PM
To: Markus Lanthaler
Subject: Re: [json-ld.org] Merging @base and @vocab and change their
behavior (#26)

The discussion and resolution can be found here:

http://json-ld.org/minutes/2011-09-06/#topic-3

Reply to this email directly or view it on GitHub:
#26 (comment)

[lanthaler]

It seems this should be further discussed.

Feeback by Ivan Herman: +1 and, actually, I would not be opposed to drop it either...

[lanthaler]

RESOLVED: Drop support for @base.

RESOLVED: Drop support for @vocab.

Minutes of the 2011-12-13 telecon

[gkellogg]

Add note to describe previous usage pattern and that they may be added back if experience dictates.

[gkellogg]

This was recently brought up again by François Daoust, and should be re-considered, particularly in light of @niklasl's RDFa to JSON-LD serializer, which could use @vocab directly.

http://lists.w3.org/Archives/Public/public-linked-json/2012May/0053.html
http://lists.w3.org/Archives/Public/public-linked-json/2012May/0056.html
http://lists.w3.org/Archives/Public/public-linked-json/2012May/0059.html
http://lists.w3.org/Archives/Public/public-linked-json/2012May/0062.html
http://lists.w3.org/Archives/Public/public-linked-json/2012May/0063.html
http://lists.w3.org/Archives/Public/public-linked-json/2012May/0064.html
http://lists.w3.org/Archives/Public/public-linked-json/2012May/0066.html

[dlongley]

I realize that the discussion is around adding some kind of standard @vocab behavior, however, I'll just point out that we could possibly deal with this issue via compaction optimization options.

[msporny]

Another potential down-side of @vocab is that pure JSON may be mis-interpreted. At most, I think we should reserve the @vocab keyword and state that processors may implement it but you have to pass something like "experimental": ["@vocab"] in the options to the processor to enable processing of @vocab.

@dlongley, please elaborate on what you mean by "compaction optimization options".

[gkellogg]

In talking with Rich Morin about using it for converting native JSON into JSON-LD, having to declare a term in the context for every possible property used in the input document is a burden. There are enough other cases that want to wildcard any object key to use in JSON-LD. @vocab is really the only way to accomplish this.

Note that Manu's made some claims about being able to use plain strings as properties. While this is certainly true in JSON-LD input, this will not survive any of the JSON-LD algorithms, which drop such terms. @vocab provides an easy mechanism to be sure they will not be dropped.

I don't really see what a compaction algorithm can do for this. Perhaps adding something to @context that said to not drop undefined terms during the algorithms, but that's really tantamount to just setting @vocab.

Another use case is when converting from RDFa to JSON-LD. If the RDFa @vocab definition can be used in a JSON-LD manifest, then the terms expressed in @property/@typeof/@rel/@Rev can just be used as such in the output JSON-LD. Otherwise, either a prefix must be minted, or the processor would need to detect each of these terms and create an entry in a local @context. This really sounds like it's creating a large barrier for no good purpose.

The danger of @vocab is that more triples would be generated, not that data would be mis-interpreted. Given that the use of @vocab is entirely within the author's (or user's) control, I really don't see the problem.

[niklasl]

I definitely agree that @vocab saves a lot of work (and space) in making contexts more compact and coherent. It's been the case in all scenarios I've used it in. And as Gregg has mentioned, this is extremely apparent when extracting JSON-LD from RDFa. So I am certainly (still) in favour of reinstating it.

If there is real danger that a @vocab defined in an indirectly imported @context would cause unpredictable behaviour, we should define @vocab as intransitive. Thus it will only have effect in the current document (i.e. if it's embedded or directly linked to). That way, @vocab can never indirectly influence anything (thus giving the author or user of JSON-LD content full control).

Come to think of it, we already have the same danger with @language! I.e. if someone defines @language in an external @context which is indirectly imported, it will turn every plain string value into a language literal. So it's just as important, if not more so, to declare @language as intransitive in the exact same manner.

(Of course, even if we don't do this, one can always turn off the current @vocab (or @language) by setting it to null in the closest @context. But I very much recommend the intransitive approach.)

[jmandel]

+1 for bringing @vocab back.

For my use case, I rely on a script that extracts properties from an ontology and explicitly outputs every one to produce a default context -- when all I really need would be
{'@vocab': 'http://smartplatforms.org/terms#'}

[dlongley]

I'd be fine with bringing back @vocab, I believe. If I recall correctly, supporting it requires minimal changes to implementations... though I haven't thought about the implications of niklas' intransitive suggestion.

[lanthaler]

I would be OK with re-introducing @vocab - but not @base.

Just to make sure we are on the same page: @vocab would be used as the base for all properties that don't contain a colon and are not defined in the context. Furthermore it applies to terms (again not containing a colon) used as value of @type. It will not be used anywhere else (e.g. @id in the context).

In compaction, @vocab would be used to transform an absolute IRI in a realtive one if no term or compact IRI is defined for that IRI.

[lanthaler]

I think we should also reconsider the usage of the colon as the prefix/suffix separator in compact IRIs. We are in-line with what RDF, XML, etc. do but for JSON-LD we might wanna use something else which would allow you to use a compact IRI directly in your programming language without encapsulating it into a string. I filed issue #132 for this. Alternatives could be

Schema$Person
Schema_Person
Schema__Person

[gkellogg]

I think this would only add more confusion, as CURIEs, PNames, QNames have a fairly long history. We already have a mechanism to allow unquoted use: use terms.

[lanthaler]

After having spoken with three Web developers (they don't have any RDF background) - I think we should spend a bit more time on this. Having two distinct base IRIs confused all of them. Furthermore the term @vocab in itself is apparently confusing. They thought they can import a vocabulary, i.e., a context, with it and without further explanations they didn't understand why it is just setting a base IRI for properties and why that's useful.

I understand that use case (and agreed to this last week) but after those discussions I'm not sure whether we should really do this. The motivation for this change is that prefixes can't be used without escaping them (because there's the colon in it) so maybe we should address the root of this issue instead (see also issue #132).

[tidoust]

I agree with Gregg, I think.

I would not mention base IRIs. What @vocab brings to the developer:

• it allows to import a core vocabulary
• it lets the developer use that vocabulary without further explanations or definitions in the most straightforward way possible, i.e. without any need to prefix property names.

No matter how easy prefixes may become, developers will prefer to stick to pure terms whenever possible.

[lanthaler]

RESOLVED: Support the @vocab keyword for setting a default vocabulary URL for a JSON-LD document.