Remove the aliases

[BigBlueHat]

Naming things is hard. 😉 Let's not run a fowl of existing data projects by squatting on their namespaces.

We should remove the existing aliases, and possibly move them into a separate aliases context file (for those who know what they're doing and still want them):

json-ld-rc/context.jsonld

Lines 3 to 8 in 5718ac0

	"type": "@type",
	"id": "@id",
	"none": "@none",
	"language": "@language",
	"direction": "@direction",
	"json": "@json",

[iherman]

Discussed on 2014-04-14 and decided to keep one file only, not to overcomplicate things.

[iherman]

Personally, I tend to agree with your @BigBlueHat, I am not fond of the aliases to keywords, but I have the impression that this particular ship has sailed... :-(

[BigBlueHat]

@iherman 2014? 😕

I'd like to un-sail this particular 🚢 😁

Is there a particular reason you feel this is practically unchangable?

[iherman]

@iherman 2014? 😕

Oops... but the link was all right; isn't that the only thing which counts on the Web? The rest is just annotation:-)

Is there a particular reason you feel this is practically unchangable?

(I guess the "you" here is meant to be plural, but I give my opinion): with some of the major JSON-LD deployments out there (e.g., schema.org, or verifiable claims) using that alias, I do not think it is realistic to turn back the tide. Via schema.org the amount of deployed data is just too huge.

As I said, I do agree with you, and I never liked hiding the keywords; it is an unnecessary fig leaf. Yes, aliasing makes pure JSON handling easier in javascript, but, after all, typing object['@id'] instead of object.id is not such a big deal. But I do not think this particular fight is worth fighting...

[BigBlueHat]

I do not think it is realistic to turn back the tide. Via schema.org the amount of deployed data is just too huge.

If they're using the alias, then this one doesn't need to. 😃 It's a choice they've made for their data ecosystem--which is fine! JSON-LD is not such an ecosystem and is meant to enable this sort of "subjectivity" by the mere fact that it has an aliasing mechanism (or really is an aliasing mechanism).

JSON-LD as a format (or even as the group promoting the format) should stay out of the "top-level" naming business and limit it to the @ prefixed stuff and leave the rest to communities.

Encouraging a certain "flavor" of aliasing is dangerous if we want adoption for of any sort of "recommended context."

[pchampin]

I think this really depends who we are targeting with this "recommended" context... As @BigBlueHat points out, JSON-LD will be used by various people, in various ecosystems, and not all will have the same requirements.

If we target beginners, to help them write idiomatic JSON-LD data without the hassle of defining their own context, then aliases make sense, but then a bunch of common properties and types would be useful as well. Schema.org does this quite well... (although maybe we should suggest that they add aliases for more keywords).

If we target context authors, then the core value of the recommended context is to define for them the prefixes that they are likely to use, and leave it to them whether and how they wish to alias keywords (which is much easier to do manually than to remember the IRI of rdf: or xsd:).

[azaroth42]

If we target beginners, to help them write idiomatic JSON-LD data without the hassle of defining their own context, then aliases make sense, [...]

This.

[BigBlueHat]

The target audience I see most interested (for years of experience working with this group and evangelizing linked data among them) is folks with existing JSON projects who see the value gain of things like Schema.org (i.e. shared vocabularies with obvious benefits such as search engine placement or inbox UX enhancements). They are indeed context authors (eventually) as they MUST understand their data and how they want to map it into something more meaningful/global.

It can be hard enough to "sell" the idea of using JSON-LD for this sort of global meaningfulness, but if we then move the target (by renaming so many things--and in ways that conflict with existing data), then I still feel we'll ultimately do ourselves a disservice.

Perhaps it's just a matter of renaming this context from "recommended context" to "starter context" and putting it a document--such as the best practices doc--which explains how one might start from that foundation.

Existing projects such as JSON API, OData, GitHub's API, ${whatever-api-you-just-used} are likely to only be encumbered by these aliases and confused when they read the Syntax document--which won't now match anything they would type in their data documents.

I'd propose we either rename this single context file, or split it into two pieces: prefix context and aliases context. Most communities (Schema.org, IIIF, etc) would benefit from the shared prefix context without the risk of aliases confusions or conflicts.

Those that are starting from scratch may well choose to use the aliases 'cause they think it's prettier. 😄 But those that prefer the @type clarity or may have a need to mix that in alongside type (which is not at all uncommon when working with existing data) can avoid the aliases, and preserve the meaning of their data.

I could support a split (or perhaps a clearer rename), but I'll likely continue my stick-in-the-mud status on aliases...as I see it as dangerous for growing the ecosystem across the existing JSON surface area.

[kyrias]

Seems this ended up being done in a613808. Was the decision reconsidered and this issue should therefore be closed, or was it done unintentionally?