Re: dct:language range WAS: ISSUE-2 (olyerickson): dct:language should be added to DCAT [Best Practices for Publishing Linked Data]

Hi Stasinos,

On 9 Dec 2011, at 03:12, Stasinos Konstantopoulos wrote:
> There are various alternatives that the group might want to consider,
> depending on how specific we want to be and how badly (if at all) we
> strive to define dct:language semantics in RDFS or a natural language
> definition is also acceptable.

I think that a crisp human-readable definition is actually more important than a crisp RDFS definition.

Another, even more important, concern is that the property has to be able to express the data that is actually available in source catalogues. If all catalogues we care about already use ISO language codes to indicate languages, then it's fine to require the use of these codes in the RDF expression. But if a fair share of catalogues use other means of indicating the language (e.g., a free-text field that may not cleanly map to ISO language codes), then our chosen property has to support that too and can't require something based on ISO language codes.

As a general principle, requiring a data representation that is more strict, more formal or more fine-grained than what the data providers have available at the moment would limit re-use.


> Some ideas:
> 1. Specify explicitly that dct:language rdfs:range
> . This would be, IMHO, ideal if
> this vocabulary were maintained by ISO themselves but that is not the
> case. There are other alternatives, such as ISO 639 RDF [1] and SIL
> [2], but I think lexvo is most appropriate.
> 2. Specify only that dct:language rdfs:range
> , which is less restrictive
> and would allow one to immediatelly switch to whatever supercedes
> lexvo but leaves a software agent not much wiser about what to expect
> as a value of dct:language.
> 3. Specify, in natural language, that the range can be any vocabulary
> with a direct and obvious mapping to ISO 639. Very flexible, but again
> not very informative for software agents; unless there is a way to
> provide this mapping in a machine-friendly notation like a regular
> expression.
> 4. Specify our own vocabulary in W3C space, combining the advantages
> of (1) and persistent URIs. W3C has started this discussion some years
> back [3] but there seems to be no concrete outcome; please shout if I
> have overlooked something.
> Some further thoughts on combining (3) and (4): ISO 639 is actively
> maintained, and the RDF vocabulary needs to be updated every time a
> language is added. Since (again, please shout if I am wrong) ISO do
> not publish an RDF version of ISO 639, it seems to me that it makes
> more sense for this group to define a persistent languages namespace
> within W3C and a regular expression that maps from that namespace to
> ISO 639 and never need to change anything in order to be up to date
> with ISO 639.
> Stasinos
> [1]
> [2] This is very rich LOD
> but lacks an RDF formalization, so there is no language class defined
> or anything, but there is a semi-structured mapping of macrolanguages
> such as "Arabic" to their constituents
> ( and there are also
> cross-links between 639-2 and 639-3 codes (cf, eg,
> and
> and the
> Ethonologue database
> (
> [3]

Received on Friday, 9 December 2011 18:34:59 UTC