- From: Stasinos Konstantopoulos <konstant@iit.demokritos.gr>
- Date: Sun, 28 Oct 2012 23:43:24 +0200
- To: Richard Cyganiak <richard@cyganiak.de>
- Cc: public-gld-wg@w3.org
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. Best, Stasinos [1] http://lists.w3.org/Archives/Public/public-gld-wg/2012Mar/0098.html On 28 October 2012 18:26, Richard Cyganiak <richard@cyganiak.de> 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 http://id.loc.gov/vocabulary/iso639-1.html and http://id.loc.gov/vocabulary/iso639-2.html . 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 <http://id.loc.gov/vocabulary/iso639-1/en>. > > <xxx> dcterms:language <http://id.loc.gov/vocabulary/iso639-2/chy>. > > Best, > Richard
Received on Sunday, 28 October 2012 21:43:59 UTC