Feature proposal: JSON key specific default namespaces for values

[digikim]

It would be helpful to be able to define separate default namespaces (@vocab) for the values based on the JSON-key. This would make it easier to hide URIs or namespaces from the data.

For example, when describing a Person, the JSON-LD could look like following pseudo JSON-LD (see "professionalTitle"):

{
  "@context": {
    "name": "http://xmlns.com/foaf/0.1/name",
    "homepage": {
      "@id": "http://xmlns.com/foaf/0.1/homepage",
      "@type": "@id"
    },
    "professionalTitle": {
      "@id":"http://example.org/title",
      "@type":"@id",
      "@vocab":"http://example.org/my-titles/"
    }
  },
  "name": "Manu Sporny",
  "homepage": "http://manu.sporny.org/",
  "professionalTitle": "team-leader"
}

...instead of the current way where we need to define a namespace, such as "titles:team-leader" or using the full URI.

[lanthaler]

You can to that already by type-coercing to @vocab instead of @id:

{
  "@context": {
    "name": "http://xmlns.com/foaf/0.1/name",
    "homepage": {
      "@id": "http://xmlns.com/foaf/0.1/homepage",
      "@type": "@id"
    },
    "professionalTitle": {
      "@id":"http://example.org/title",
      "@type":"@vocab"
    },
    "@vocab": "http://example.org/my-titles/"
  },
  "name": "Manu Sporny",
  "homepage": "http://manu.sporny.org/",
  "professionalTitle": "team-leader"
}

Does this address your use case?

[davidlehn]

This proposal is related to the scoping in #247. The my-titles @vocab is only for "professionalTitle" and putting it up as a global vocab seems incorrect.

[lanthaler]

“Incorrect” is a pretty strong word.. Why do you think it is? The example above allows to serialize the data exactly in the way digikim envisioned it (unless I missed something ofc).

[digikim]

Thanks @lanthaler for your proposal, but I'm afraid that @davidlehn is correct. I tried to describe the idea of local @vocabs, but unfortunately my example did only have one vocabulary so your solution could have worked in that case. Here is an improved example which describes better the problem of having multiple vocabularies:

{
  "@context": {
    "name": "http://xmlns.com/foaf/0.1/name",
    "homepage": {
      "@id": "http://xmlns.com/foaf/0.1/homepage",
      "@type": "@id"
    },
    "professionalTitle": {
      "@id":"http://example.org/title",
      "@type":"@id",
      "@vocab":"http://example.org/my-titles/"   // pseudo
    },
    "hobbies": {
      "@id":"http://example.org/hobbies",
      "@type":"@id",
      "@vocab":"http://example.org/my-hobbies/"   // pseudo
    }
  },
  "name": "Manu Sporny",
  "homepage": "http://manu.sporny.org/",
  "professionalTitle": "team-leader",
  "hobbies":["coding", "travelling", "fishing"]
}

[lanthaler]

Do you have a practical example where you would need that?

[digikim]

I'm currently defining the metadata model for media content (broadcast television & radio, ondemand video and audio, articles) for a national broadcasting company. Our goals in the project are to present the data as ordinary JSON (as far as possible) but to also give the Linked data interpretation for the data using JSON-LD. However, there are tens of attributes for each content type which makes it difficult to put all values to the same namespace (to avoid URIs or namespaces in the values). For example, I have properties such as identifier of an content item, identifier of the collection the item belongs to, identifiers of the publication channels of the item, identifier of the genre of the item, identifiers of the creators and contributors of the item etc... (I'm using Dublin Core as one of the schemas, among others.) This all could be presented as linked data without showing URIs if the local vocabularies would be possible.

[davidlehn]

@lanthaler Maybe "incorrect" is the wrong wording. It seems to me a top-level vocab is not the right solution to the problem of wanting to have a property-scoped vocab as in the comment with the improved example. I think something like that example along with the similar scoped contexts in #247 would be a good way to make the shift from using lots of prefixes to a very simple and readable JSON format. It also helps avoid problems we have now with top level vocab use: multiple vocabs, vocab conflicts, easy misuse of vocab terms for the wrong properties, etc.

[mitar]

Related: #415