Re: Resolving ISSUE-26 (range of dcterms:language)

Richard, all,

given the recent popularity that LoC URIs seems to be gaining, I would
like to remind the group of my earlier proposal [1] that, besides
advocating LoC URIs, also addresses situations where no URI exists for
the particular language variant one needs while at the same time
allowing applications that are not aware of/interested in such fine
distinctions to retrieve the LoC URI that most closely fits.



On 28 October 2012 18:26, Richard Cyganiak <> wrote:
> After further off-line discussion with Makx, Dave and Phil, I retract my earlier proposal to use xsd:language-datatyped literals as values for dcterms:language. Here is a new proposal:
> [[
> PROPOSAL: In DCAT-conformant data, values of dcterms:language MUST be members of some subclass, and SHOULD be ISO-639 URIs as defined by the Library of Congress in and . The iso639-1 codes should be preferred, and iso639-2 codes used only when no iso639-1 code is available for a language. This resolves ISSUE-26
> ]]
> The reasons are: 1. The value space of xsd:language is defined as a subset of the lexical space. This means that xsd:language-typed literals denote strings, not languages. 2. The Library of Congress is one of the registration authorities for ISO-639, and this gives them excellent credentials as maintainers of a URI scheme for ISO-639 codes.
> Here are some example statements, for English and Cheyenne:
>     <xxx> dcterms:language <>.
>     <xxx> dcterms:language <>.
> Best,
> Richard

Received on Sunday, 28 October 2012 21:43:59 UTC