- From: Jon Phipps <jphipps@madcreek.com>
- Date: Tue, 27 Feb 2007 09:59:18 -0500
- To: "Antoine Isaac" <aisaac@few.vu.nl>
- Cc: "Guus Schreiber" <schreiber@cs.vu.nl>, public-swd-wg@w3.org
re: "...there will be problems if we have several concept schemes > introducing distinct concepts with same labels, which is likely to > happen on the web :-( This is already happening in the context of the Metadata Registry [1], with only a dozen or so schemes registered, and I expect it to be even more frequent as the registry grows, [1] http://metadataregistry.org/vocabulary/list.html --Jon On 2/27/07, Antoine Isaac <aisaac@few.vu.nl> wrote: > > Guus Schreiber a écrit : > > > > > Antoine Isaac wrote: > > > >> 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. > > > > > > And nothing prevents them from keeping on doing so. My point is that I > > see no reason to make this customary practice a hard constraint for > > all users of SKOS. Why would we want to prevent some thesaurus > > builder,who wants to have multiple preferred labels in the same > > language, to use SKOS? > > Let's be honnest: while I see the motivation for having the constraint, > I don't see really what modelling gains could be obtained by multiple > preferred labels. But of course if Alan has a case I will re-consider my > position. > > > > > Anyway. the is no way to express this cardinality constraint in > > RDF/OWL while taking the multi-lingual aspect into account . > > True for the cardinality constraint. But for the uniqueness one, we > could still use inverseFunctionalProperty, couldn't we? It goes into OWL > Full for datatype properties, but does the trick it seems. Hmm, well, > ok, there will be problems if we have several concept schemes > introducing distinct concepts with same labels, which is likely to > happen on the web :-( > > 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 14:59:30 UTC