- From: Daniel Rubin <rubin@med.stanford.edu>
- Date: Wed, 28 Feb 2007 08:30:32 -0800
- To: Antoine Isaac <aisaac@few.vu.nl>,Jon Phipps <jphipps@madcreek.com>
- Cc: Guus Schreiber <schreiber@cs.vu.nl>,SWD WG <public-swd-wg@w3.org>
At 12:17 AM 2/28/2007, Antoine Isaac wrote: >Hi Jon, > >> >> >>> >>>My proposal is based on the assumption that the >>>vast majority of thesauri will not have label >>>relations, and therefore I wish not to have the >>>burden of terms as classes on them. But I'm happy >>>to be convinced my assumption is wrong. >> >> >>Given the use cases and motivation cited in [2], most of the >>relationships defined in the motivation seem to represent >>relationships between concepts rather than between labels, so in that >>case I'm inclined to agree. > >I'm quite puzzled here. For me things like synonymy and abbreviation >are clearly at the lexical or terminological level, not at the >conceptual one. If I have "car" and "automobile" I would like have >just one concept for them, and not two that I would declare >equivalent afterwards.... True, but there are use cases where it makes sense for terms to be classes, for example, if you want to have relations to those terms. For example, if you wanted to relate "car" and "automobile" to information such as author, date added, etc, and if you wanted to be able to declare one of these the preferred term, it will be very helpful for all terms to be classes (resources). >>The one area where I think label relationships will very frequently be >>required will be multilingual relationships between labels other than >>prefLabel (assuming we let prefLabel keep its singularity). There >>isn't a good way to declare relationships between multiple >>translations of any label-related statement, but especially altLabels, >>whose object is a literal. This might unfortunately also be true of >>notes as well, but probably less of less importance. >> >>One other possible solution might be to recommend (not require) that >>in the sole case of a need to maintain multilingual versions of a >>concept and all of its literal properties, that concept schemes be >>considered single language and provide for this purpose an >>isTranslationOf relationship (or some other form of typed equivalence) >>between concepts? > >This could do the trick, but I'm convinced we have enough multi >lingual cases (and too small a number of explicit label translation >cases) to say this would be counter-productive. All things >considered, I actually would prefer to have to encode the >translation links using whatever complex annotation alternative than >to have to split concept schemes into more-or-less duplicate >versions (and God knows I am not personnally fond of this annotation >solution ;-) > >Cheers, > >Antoine > >> >>I'm also thinking here of my daughter, the soon-to-graduate Spanish >>major, who tells me that there are concepts in Spanish that can't be >>expressed in English but for which there are English equivalents that >>are considered to be effective translations. >> >>Anyway, just a thought. >> >>--Jon >> >>[2] >>http://www.w3.org/2006/07/SWD/wiki/SkosDesign/RelationshipsBetweenLabels >> >> >>--Jon >> >>> > On 2/27/07, Guus Schreiber <schreiber@cs.vu.nl> wrote: >>> >> >>> >> ISSUE-26 [1] >>> >> RelationshipsBetweenLabels >>> >> >>> >> Considering that: >>> >> - representing lexical labels as classes would >>> >> lead to an undesirable complication of SKOS in >>> >> straightforward use cases for the application of SKOS, >>> >> - representing relationships between labels is >>> >> required in some use cases, and therefore an >>> >> escape mechanism should preferably be available >>> >> for such thesauri, >>> >> >>> >> I propose the WG opts for an amended version of >>> >> the second solution proposed in [2]: >>> >> >>> >> RESOLUTION >>> >> >>> >> The WG resolves to add the following classes and >>> >> properties to the SKOS specification [3]: >>> >> >>> >> - the class skos:LabelRelation >>> >> - the properties skos:labelRelationSubject and >>> >> skos:labelRelationObject with domain LabelRelation >>> >> and range rdfs:literal >>> >> >>> >> In addition, the SKOS Guide should describe >>> >> guidelines for SKOS users to define their label >>> >> relations as specializations of LabelRelation and >>> >> gives examples of its intended usage. The SKOS >>> >> specification refrains for now to predefine >>> >> specializations of LabelRelation. >>> >> >>> >> Contrary to the proposal in [2] the class >>> >> LabelRelation is not defined as a subclass of >>> >> skos:Annotation (which is in any case not yet part >>> >> of the spec), as it is not an "annotation", but a >>> >> lexical relationship. >>> >> >>> >> >>> >> [1] http://www.w3.org/2006/07/SWD/track/issues/26 >>> >> [2] >>> >> http://www.w3.org/2006/07/SWD/wiki/SkosDesign/RelationshipsBetweenLabels >>> >> [3] http://www.w3.org/TR/swbp-skos-core-spec/ >>> >> >>> >> -- >>> >> 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/ >>> >> >>> >> >>> > >>> >>>-- >>>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 Wednesday, 28 February 2007 16:47:07 UTC