Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Drop @base and @vocab #26

Closed
lanthaler opened this issue Sep 1, 2011 · 22 comments

Comments

@lanthaler
Copy link
Member

commented Sep 1, 2011

In the current spec we have @base and @vocab to change the base IRI for objects and properties (but nothing for subjects). I think that's unnecessarily complicated and inconsistent.

I would thus propose to merge @base and @vocab to @base and make it work as it currently does in HTML and Turtle, i.e., @base would overwrite the base IRI for all relative IRIs in the document.

@msporny

This comment has been minimized.

Copy link
Member

commented Sep 3, 2011

@gkellogg

This comment has been minimized.

Copy link
Member

commented Sep 7, 2011

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

@lanthaler

This comment has been minimized.

Copy link
Member Author

commented Sep 7, 2011

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

@gkellogg

This comment has been minimized.

Copy link
Member

commented Sep 7, 2011

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" reply@reply.github.com 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

This comment has been minimized.

Copy link
Member

commented Sep 11, 2011

The discussion and resolution can be found here:

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

@msporny msporny closed this Sep 11, 2011
@lanthaler

This comment has been minimized.

Copy link
Member Author

commented Sep 11, 2011

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-
2f0b8804f3130720d0ee75e01fff492e8253d1af@reply.github.com]
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 lanthaler reopened this Sep 12, 2011
@lanthaler

This comment has been minimized.

Copy link
Member Author

commented Sep 12, 2011

It seems this should be further discussed.

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

@lanthaler

This comment has been minimized.

Copy link
Member Author

commented Dec 13, 2011

RESOLVED: Drop support for @base.

RESOLVED: Drop support for @vocab.

Minutes of the 2011-12-13 telecon

@gkellogg

This comment has been minimized.

Copy link
Member

commented Dec 13, 2011

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

@gkellogg gkellogg closed this Dec 15, 2011
@gkellogg gkellogg reopened this May 24, 2012
@dlongley

This comment has been minimized.

Copy link
Member

commented May 24, 2012

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

This comment has been minimized.

Copy link
Member

commented May 25, 2012

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

This comment has been minimized.

Copy link
Member

commented May 25, 2012

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

This comment has been minimized.

Copy link
Member

commented May 25, 2012

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

This comment has been minimized.

Copy link

commented May 25, 2012

+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

This comment has been minimized.

Copy link
Member

commented May 25, 2012

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

This comment has been minimized.

Copy link
Member Author

commented May 27, 2012

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

This comment has been minimized.

Copy link
Member Author

commented Jun 5, 2012

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

This comment has been minimized.

Copy link
Member

commented Jun 5, 2012

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

This comment has been minimized.

Copy link
Member Author

commented Jun 12, 2012

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

This comment has been minimized.

Copy link
Contributor

commented Jun 12, 2012

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

This comment has been minimized.

Copy link
Member Author

commented Jun 19, 2012

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

@lanthaler lanthaler closed this in a2b449d Aug 1, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.