W3C home > Mailing lists > Public > public-esw-thes@w3.org > January 2014

RE: identity of SKOSXL labels

From: Vladimir Alexiev <vladimir.alexiev@ontotext.com>
Date: Thu, 9 Jan 2014 21:12:46 +0200
To: "'Armando Stellato'" <stellato@info.uniroma2.it>
Cc: <public-esw-thes@w3.org>
Message-ID: <011a01cf0d6e$c7c90f40$575b2dc0$@alexiev@ontotext.com>
Hi Armando!

> there is no enforcement by SKOSXL and it's a modeler's choice.

Yes, and I can see legitimate uses for both models:
- shared Label: only when there's a logical and permanent reason why the two labels are the same.
  Then the maintenance of this shared label can be easier, because it needs to be done only once.
- own (copied) Label: this is the usual case. Use when the literals are *incidentally* the same but may become different in the future
  It also makes the referential management of labels more difficult: if you delete a concept, you need to refcount before you can delete its labels.

SKOS editors should enforce neither model. But could they support both?
- When creating a new label, I think it's a stretch to ask the user "reuse a shared label?": just create an own one
- RDF-native editors (like VocBench) may receive a SKOS file with shared labels... In that case I think keeping them shared is best.


I am not aware of any actual SKOS thesaurus using shared labels.

But here's a related example:
Getty has a peculiar internal organization:
literals are shared between *languages*

Lookie at the first 3 "Terms" here:
the string "rhyta" is actually shared between the languages en (English), el-Latn (Greek transliterated) and es (Spanish) in their database

But of course when mapped to skos-xl, we had to unshare. Lookie here:
Those 3 terms are mapped to different skosxl:Label nodes:
  skosxl:prefLabel aat_term:1000198841-en, aat_term:1000198841-el-Latn;
  skosxl:altLabel aat_term:1000198841-es


PS: this is still under development, we know there are omissions and buggies.
Eg skosxl:prefLabel  are dumbed down to skos:prefLabel but skosxl:altLabel aren't
Received on Thursday, 9 January 2014 19:13:10 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 13:32:19 UTC