W3C home > Mailing lists > Public > public-linked-json@w3.org > April 2017

Re: Language maps and undefined language

From: Jakob Voß <jakob.voss@gbv.de>
Date: Tue, 11 Apr 2017 08:13:43 +0200
To: <public-linked-json@w3.org>
Message-ID: <adc9f9b1-78bc-9864-dbe2-6b2359dd5f52@gbv.de>
Hi,

Gregg Kellogg wrote:

> In CSVW, we coined “und” as the undefined/absent language.

"und" is a perfectly legal language tag, defined in the IANA language
tag registry:

Type: language
Subtag: und
Description: Undetermined
Added: 2005-10-16
Scope: special

The other language tags in the "special" Scope are:

zxx: No linguistic content/Not applicable
mis: Uncoded languages
mul: Multiple languages

One might argue that "zxx" is actually equivalent to no language tag.
Anyway "und" is actually used for "unknown language" in contrast to "no
language". If your data
model expects strings to always have languages "und" makes sense but in
this case there should not be literal strings without language tag
anyway (see JSKOS json-ld profile for SKOS for an example).

Robert wrote:

> If compaction would result in an attempt to add a string without an
> associated language into a LanguageMap, then the processor SHOULD
> assign the undefined language code `UND` as the key in the array.

I'd prefer this:

If compaction would result in an attempt to add a string without an
associated language into a LanguageMap, then the processor MUST NOT
include this string. Instead it SHOULD emit a warning to inform that the
data to compact does not fit to the expected data model expressed
by definition of a LanguageMap.

In theory, any kind of RDF data should be expressible with any kind of
JSON-LD context. In practice each JSON-LD context defines a data model
with implicit or explicit assumptions what RDF data to be expressible in
a meaningful way. I prefer meaningful data over hacks to express data
that does not conform to expectations anyway.

What's the actual use case of having non-language strings in language maps?

Jakob
Received on Tuesday, 11 April 2017 06:14:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:49 UTC