- From: Antoine Isaac <aisaac@few.vu.nl>
- Date: Tue, 27 Feb 2007 14:09:22 +0100
- To: Guus Schreiber <schreiber@cs.vu.nl>
- CC: public-swd-wg@w3.org
Hi Guus, I'm not really convinced by this argument, for two reasons: - relevance to domain practice: even if a motivation for the constraint in ISO and other thesaurus modelling approaches (especially term-based ones, which are still encountered in many situations) was this reference uniqueness, there are also strong normalization issues underway. People managing thesauri are often spending a lot of time distilling *the* term that embodies the concept in the best way. And while standard database have been allowing for unique keys for decades, they still keep to this constraint on the labels. - coherence of the model: if we remove all the cardinality constraints, what would be the indended meaning of a preferred label? This might sound a rather stupid argument, but I really cannot see what makes a label 'preferred' if its associated concept has two such labels. Cheers, Antoine > > > > Guus Schreiber wrote: > >> >> While trying to write down a resolution for the relationship between >> labels I found: >> >> in the Core Guide, section on Multilingual La belling [1] >> >> [[ >> It is recommended that no two concepts in the same concept scheme >> be given the same >> preferred lexical label in any given language. >> ]] >> >> in the Core Specification, table of prefLabel [2] >> >> [[ >> No two concepts in the same concept scheme may have the same value >> for skos:prefLabel >> in a given language. >> ]] > > > I see no need for placing a constraint on the uniqueness of > skos:prefLabel. While some/many vocabularies will actually abide to > this, the URI of the concept the label is related already ensures > uniqueness of the concept being identified (which I assume was the > reason for including this constraint in the ISO spec). I also suggest > that there is no need to place cardinality constraints on skos:prefLabel. > > The underlying rationale is that we should refrain from overcommiting > the SKOS specification when there is no clear need. > > I want to raise this as an issue and propose the above as a resolution. > >> >> The weaker constraint in the Guide makes sense to me. I will most >> likely propose an even weaker version in my resolution. >> >> Guus >> >> >> >> [1] http://www.w3.org/TR/2005/WD-swbp-skos-core-guide-20051102/#secmulti >> [2] http://www.w3.org/TR/swbp-skos-core-spec/#prefLabel > >
Received on Tuesday, 27 February 2007 13:09:27 UTC