- From: Antoine Isaac <aisaac@few.vu.nl>
- Date: Fri, 02 Mar 2007 11:47:16 +0100
- To: "Miles, AJ \(Alistair\)" <A.J.Miles@rl.ac.uk>
- CC: public-swd-wg@w3.org, public-esw-thes@w3.org
Hi Alistair Thanks for the long mail. I think I got the idea, but the naming of the issues is confusing (perhaps because of the many different interpretation of "semantics"), and the use of examples too. To me the 'content' of the conditions mentioned in issue 1 should be discussed in issue 2, while (correct me if I'm wrong) issue 1 is just about the question of formally encoding these axioms in a specific language or not, and decide (or not) to use them as a basis for quality checking procedures. Shortly, I want to make three remarks on what in my eyes should be in issue 2, that is the 'content' of the conditions >The first of these is that, intuitively, only one label (per language >per script) can be "preferred". In other words, it does not make sense >for two things to both be "preferred". > >The second of these is that, intuitively, it does not make sense for a >label to be both "preferred" and "alternative"; or both "preferred" and >"hidden"; or both "alternative" and "hidden". > > I completely agree with the beginning, less with the conditions on "hidden". What if a typo on a term for a concept (which could be encoded as hidden, if I understood well this property) corresponds to the preferred term of another concept? I agree this is borderline, but if someone has met this situation it is time to say it before we register the condition as valid! > >In some types of controlled vocabulary, it may be entirely reasonable >for two concepts in the same scheme to have the same preferred lexical >label (in some language/script). This is the case, for example, in some >classification schemes (where two "classes" may have the same "caption") >and corporate taxonomies (where two "nodes" may have the same "label"), >in which case either the notation or the context is used to disambiguate >meaning. > > True. It might also be the case in multilingual thesauri having one 'reference' language, in which the prefLabels are unambiguous, and 'translations' which are less constrained. Notice then that it does not remove completely the constraint, which should read like "there is at least one language in which the prefLabel is unambiguous" (which is btw the case is many classification schemes, in which the 'artificial' notation language plays this role) ><snip> For this reason, I agree with Guus that these two sentences be dropped >from all future SKOS specifications, and that no formal conditions >should be placed on the use of the SKOS lexical labeling properties in >conjunction with the SKOS concept scheme constructs (currently >skos:inScheme and skos:ConceptScheme). > >However, for a SKOS concept scheme to be *usable* as a thesaurus (i.e. >compatible with software following the ISO2788 standard) some >restrictions must be observed on the use of these properties in >conjunction. > > > >Because of the importance of being able to identify compatibility with >existing thesaurus software and standards, I would like to argue that we >specify, informally, a set of restrictions which may be *optionally* >applied in order to detect thesaurus incompatibility. I.e. these >restrictions *would not* be part of the formal semantics of SKOS. > > I agree with the fact that even my "adapted" condition above could be restricted so such a 'best practice for thesauri' informal and optional approach. I would however say that I think this condition apply to a very wide range of concept schemes, if not an overwhelming majority. The only one I can think of at the moment are perhaps the web taxonomies such as Yahoo. And I think none of the use cases gathered for SKOS has this ambiguity case. Once again, this is a call for (counter-)examples! >These restrictions can be stated informally, with examples of SPARQL >queries that could be used to detect incompatibilities. Expressing these >restrictions formally is complicated and unnecessary. > > Of course if no constraint is kept in the end (that is, Guus' proposal) I fully agree with this policy. Cheers, Antoine > > >>-----Original Message----- >>From: public-swd-wg-request@w3.org >> >> >[mailto:public-swd-wg-request@w3.org] > > >>On Behalf Of Guus Schreiber >>Sent: 27 February 2007 12:01 >>To: public-swd-wg@w3.org >>Cc: SWD WG >>Subject: [SKOS] Possible issue: Uniqueness of skos:prefLabel [was Re: >>[SKOS] inconsistency between Guide and Specification >> >> >> >> >>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 >>> >>> >>-- >>Vrije Universiteit Amsterdam, Computer Science >>De Boelelaan 1081a, 1081 HV Amsterdam, The Netherlands >>T: +31 20 598 7739/7718; F: +31 84 712 1446 >>Home page: http://www.cs.vu.nl/~guus/ >> >> > > > > >
Received on Friday, 2 March 2007 10:51:10 UTC