JSON-LD 1.1 Feature Request: New @label keyword

[jasnell]

In the spirit of "Labeling Everything" (http://patterns.dataincubator.org/book/label-everything.html) ... it would be worthwhile, IMO, for JSON-LD to provide a basic @Label keyword for use both in @context and nodes. It's largely syntactic sugar but would be useful.

For example:

{
  "@context": {
    "@label": "An Example Context",
    "displayName": "@label",
  },
  "displayName": "A Simple Label"
}

Which would expand to:

_:c14n0 <http://www.w3.org/2000/01/rdf-schema#label> "A Simple Label" .

[lanthaler]

Hmm… how would that be different from explicitly mapping @Label to rdfs:label in the context? Is this simply a matter of saving a couple of characters?
Could you please elaborate a bit on what "@Label": "An Example Context" in the context should do or how it is supposed to be interpreted?

[jasnell]

@Label in the @context is documentation.

In general, this would be syntactic sugar... saving characters for a common use case and promotion of best practice..

[davidlehn]

Contexts themselves are not a part of the RDF data model so it seems kind of strange to start applying particular RDF properties, or things that look like RDF properties, to them. I fear getting too meta with this discussion without solid use cases. But if @contexts are to become resources, there may be better ways to do this sort of thing. For instance, add a more flexible special @about property in the @context that would be processed with the main context and would let you add properties for the context itself such as @id, @type, and any other properties like label, description, etc. This really needs more discussion to determine if the added complexity is needed.

{
  "@context": {
    "@about": {
      "id": "a-magic-context",
      "type": ["MyMagicContext", "jsonld:Context"],
      "label": "My Super Magic Context",
      ...
    },
    "@base": "https://www.example.com/ns/stuff#",
    "id": "@id",
    "type": "@type",
    "jsonld": "http://www.w3.org/ns/json-ld#",
    "label": "http://www.w3.org/2000/01/rdf-schema#label"
    ...
  },
  ...
}

[cappelaere]

Could @Label be used for localization of properties themselves?
I have this issue where I need to define many properties and values for an API. It is easy to localize the property value as defined in the JSON-LD spec (example 31 for instance). But if the property tags are used for visualization, they need to be localized as well. Best place would seem to be in @context using @Label or expand each property with a hash containing @Label and @value.
Anybody with some experience in that area?
Thanks.
Pat.

[gkellogg]

I don't see much value to this, there are a number of things which might deserve keywords, and where do we draw the line. IMO, it's just as easy to define the following:

{
  "@context": {
    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
    "displayName": "rdfs:label",
  },
  "displayName": "A Simple Label"
}

[dlongley]

@cappelaere,

Could @Label be used for localization of properties themselves?

Best place would seem to be in @context using @Label or expand each property with a hash containing @Label and @value.

I disagree. The best place for information about a property should be at its URL. You should be able to go to the URL of the property and get more information about it -- which may include a "display label" of some kind. This probably shouldn't be context-specific, it would be the same regardless of the term the property (URL) gets mapped to, and therefore shouldn't be in a @context. Rather, it's part of the vocab.

[davidlehn]

There are two parts to the original issue, one is @label sugar, the other is adding properties about a @context as if it were also a resource. I agree with @gkellogg that @label is unnecessary, but treating @contexts as resources is very meta and maybe worth at least considering.

[lanthaler]

What use cases can be realized with treating embedded @contexts as resources that can’t be realized by expressing that data in the body of the document? Please note that external contexts are already resources that are identified with a URL and can thus be described as any other thing in JSON-LD.

[kevinSuttle]

See also: #369 (comment)