@none for language maps clarification

[azaroth42]

In https://www.w3.org/TR/json-ld11/#language-indexing, it says:

... the special index @none is used for indexing data which does not have a language ...

Is that a string that really has no language (e.g. just a random set of characters) or can it be a string that is not known to have a language, but might in practice?

[gkellogg]

Yes, it should be "for indexing strings with out an associated language", or similar. In RDF, it would be string with datatype xsd:string. Although it may make sense to talk about strings with might have a language, the data model doesn't have any way to represent this.

[iherman]

This issue was discussed in a meeting.

• RESOLVED: close issues 56, 77, and 102 as having been addressed by recent merges

View the transcript

Gregg Kellogg: issue 56 - this was looking for examples to indicate unexpected behavior when type is a vocab
… i think ball was in Ivan’s court whether the examples were sufficient
… we are not closing the issue until after the PR, so question is whether we are ready to close
… we added 2 examples
… next issue is 77, disambiguate uses of @type
… Webex seems to have some problems with this meeting, especially if changing focus on my computer
… we discussed adding @datatype, instead decided to add text around different uses of @type
… are people satisfied with wording?
Gregg Kellogg: use of @none regarding language
… in seeming conflict with requirement that language has to be string, @none didn’t specify
… fixed that wording making clear that @none has to be a string
Benjamin Young: these are tagged proposed closing
… we need to decide if ready to close
Adam Soroka: I wanted to mention the @datatype issue - I’m okay with this, but we may need a gitHub tag for whenever issues about @type comes up
… this will be a way to verify that spec wording update is enough to minimize confusion
Gregg Kellogg: w3c/json-ld-wg#24
Gregg Kellogg: I did raise issue 24 about surfacing the minutes on this topic like we did in Community Group
… could we do this?
… was useful in community group
Ivan Herman: minutes cleanup is done by me, and summarizing each meeting may not be a good idea
Gregg Kellogg: there is a scribe tool that builds summaries and indexes automatically
Benjamin Young: it works on issues and action lists at top/bottom of each meeting minutes
Gregg Kellogg: the good thing is it aggregates all minutes on each issue
Benjamin Young: I will take an action to investigate to see if we can build index of minutes by issue
… I think this is a good idea
Gregg Kellogg: will work with bigbluehat on this since I worked on CG
Benjamin Young: can we close these 3 issues
… 56, 77 and 102 ?
Ivan Herman: can we do a resolution to close these 3 issues?
Proposed resolution: close issues 56, 77, and 102 as having been addressed by recent merges (Benjamin Young)
Ivan Herman: +1
Gregg Kellogg: +1
Tim Cole: +1
Benjamin Young: +1
David Newbury: +1
Pierre-Antoine Champin: +1
Resolution #1: close issues 56, 77, and 102 as having been addressed by recent merges

[BigBlueHat]

By way of connecting dots, this clarification also makes the closing of #91 more obvious.