[Dini-ag-kim-titeldaten] range of dcterms:language

Pascal Christoph christoph at hbz-nrw.de
Don Mar 7 08:50:05 CET 2013


Hallo,

Am 06.03.2013 18:26 schrieb Ruehle, Stefanie :
> ich stelle gerade fest, das wir in der Empfehlung die Verwendung von 
> dcterms:language vorsehen (s. 
> https://wiki.dnb.de/pages/viewpage.action?pageId=68061169#KonzeptuellesMapping%28Inhalt-RDF%29-Sprachangaben). 
> Das bedeutet, dass die Range vorgegeben ist und ein non-literal value 
> sein muss, der eine Instanz der Klasse 
> http://purl.org/dc/terms/LinguisticSystem ist - kurz es muss hier ein 
> URI stehen (s. 
> http://dublincore.org/documents/dcmi-terms/#terms-language). Ich wäre ja 
> sehr dafür, dass an dieser Stelle festzulegen, aber dann sollte unter 
> Inhalt nicht ISO-Sprachencode stehen, sondern Sprachencode-URI, wobei 
> die möglichen Vokabulare hier zu benennen sind, als da sind:
> * http://www.lexvo.org/ für ISO 639-3

nicht (nur) die lexvo-URIs nehmen, siehe auch
http://lists.w3.org/Archives/Public/public-lod/2012Feb/0090.html

> * http://id.loc.gov/vocabulary/iso639-1.html
> * http://id.loc.gov/vocabulary/iso639-2.html
> * http://id.loc.gov/vocabulary/iso639-5.html

ja, die loc-URIs sind gut!

> Wenn wir das nicht wollen und auch die reinen Codes erlaubt sein sollen 
> (ohne URI), dann sollten wir anstelle von dcterms:language lieber 
> dc:language verwenden.

Warum sollten wir keine URIs wollen? Wir wollen sie !
URIs lassen sich aus den vorhandenen Sprachangaben leicht herstellen (auch wenn
in den Katalogen die Sprachangaben zweistellig oder dreistellig oder sonstwie
vorkommen, so lassen sie sich vereinheitlichen. Und diese Vereinheitlichung
sollte sowieso gemacht werden, für die Recherche (Stichwort Facetten usw.)).

viele Grüße,
pascal