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

On 29 October 2012 08:41, Richard Cyganiak <richard@cyganiak.de> wrote:
>
> Stasinos, is there a concrete proposal to modify DCAT (or some other GLD deliverable) in there?
>
> Thanks,
> Richard

Good morning,

To add a "linguisticallyRelatedTo" property between lingsuistic
systems, although this does not seem to fit GLD's purpose to discuss
linguistics; or (my personal preferece) to ues skos:semanticRelation
[1]. And to restrict the range of the language relation to the union
of:

- http://id.loc.gov/vocabulary/iso639-1/iso639-1_Language.html
- http://id.loc.gov/vocabulary/iso639-2/iso639-2_Language.html
- any LinguisticSystem that has a skos:semanticRelation to the union
of the two classes above.

The rationale behind the latter is explained in [2].

Note that if a formalization besides the one in English language I
just gave above is required, this restriction cannot be expressed in
RDFS but can be very nicely captured in OWL.

s


[1] Note that LoC already uses skos:exactMatch to link 639-1 URIs to
their equivalent 639-2 URIs. skos:exactMatch is a sub-property of
skos:semanticRelation, hence skos:semanticRelation would be a good
candidate for this purpose, whithout delving into the linguistic
intricacies of what it means for two languages to be related.

[2] http://lists.w3.org/Archives/Public/public-gld-wg/2012Mar/0098.html


> On 28 Oct 2012, at 22:43, Stasinos Konstantopoulos wrote:
>
>> 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 Monday, 29 October 2012 07:34:39 UTC