Renaming of the term 'name' at the interaction level in 'label'

[sebastiankb]

JSON-LD 1.1 allows the use of properties, actions, and event names as keys. Therefore, the name term is obsolete at the interaction level. However, key names can not be human-readable (for example, no spaces allowed), the (optional) term label can be used as an alternate interaction name and used, e.g., for UI labels.

[benfrancis]

I think the term "name" is fine for human-readable strings. I like that "name" and "description" can be consistent across properties, actions, events and the top level of the thing. "name" is what we are currently using in Mozilla's implementation.

[sebastiankb]

ok, thanks for this input. We will discuss this in one of the next TD web meeting.

[takuki]

My understanding was that JSON key names can contain special characters such as spaces. This is purely from syntactic viewpoint. Are there any other reasons that we should consider to avoid spaces in names? (e.g. Scripting API)

A name can be considered to be part of a definition, and it can also be considered external to the definition. When it is important to distinguish a "type" from a named use of the "type", it should be considered external so that a definition of the type can be shared among multiple named uses of the "type".

On the other hand, I agree that consistency (e.g. Thing and interaction patters) is also an important factor.

[takuki]

The TD TF discussed the issue today. The Thing level "name" should really be "label", and the TD no longer has "name" field. Thing, Property, Action and Events this way will only have ID and optional "label". The TF discussed at lengths and found it prefers to use "label" for human-readable statement than to use "name".

[benfrancis]

Can you explain the reason this change of terminology is "preferred"?

It seems natural to give web things a human readable "name" and "description", as is also the case for web apps (https://w3c.github.io/manifest/#name-member). This is distinct from a machine readable unique identifier in the form of a URI.

[zolkis]

At top level (Thing) I'd also prefer name.

On interaction level (Property, Action, Event), the interactions are represented as dictionaries, where the keys are the interaction names, the values are the representations. Therefore inside the representation label is used instead of duplicating name. Also, a label can be internationalized.
I guess the reasoning was to harmonize with the convention label is used at interaction level.

My only gripe with label is either that why limiting the number of labels to one, or (in another interpretation) why are we using the term label for something that really is a name.

[mkovatsc]

label emerged because it directly maps to rdfs:label and the new definition conflicted with the previous term name. Whether it is a good choice is not clear to me. One thought was to make it really explicit, that it is just a human-readable label and avoid confusion with the previous usage of name.

I would also be interested in the concrete arguments, pro and con.

An argument for name would be correspondence to HTML and the DOM, where name can appear multiple times (cf. getElementsByName()). The key is the unique ID, cf. getElementById().

[benfrancis]

Rendering a machine-readable name as a human-readable name is arguably better than having no name because the term changed to "label", but backwards compatibility probably isn't a big deal anyway considering the syntax also changed from arrays to objects at the same time.

I definitely think the top level name should be called "name". Names for properties, actions and events could be either "name" or "label", but I don't see any harm in sticking with "name" for consistency.

[benfrancis]

Note that currently the specification is inconsistent.

At the thing level section 5.2.1 specifies "label", but examples 1, 2, 14, 15 use "name" and examples 5 & 6 use "label".

At the interaction level examples 7, 8, 9 use "label".

At the thing level I would definitely suggest "name". I feel less strongly about the interaction level, but "name" would be more consistent.

[sebastiankb]

Thank you for this hint. It seems that there was a c&p mistake in the TD model, as you can see from the description of the label term at the Thing level. I will update this to the name again.

[sebastiankb]

I've just submitted an updated TD version that fix this bug. I will close this issue.