- From: Antoine Isaac <aisaac@few.vu.nl>
- Date: Thu, 01 Mar 2007 14:01:34 +0100
- To: Daniel Rubin <rubin@med.stanford.edu>
- CC: Guus Schreiber <schreiber@cs.vu.nl>, Jon Phipps <jphipps@madcreek.com>, SWD WG <public-swd-wg@w3.org>
Hi, Just a small question. Is this alternative solution you are discussing similar to the third solution I had put in [1]? Antoine [1] http://www.w3.org/2006/07/SWD/wiki/SkosDesign/RelationshipsBetweenLabels > > At 08:55 AM 2/28/2007, Guus Schreiber wrote: > > > >> Jon Phipps wrote: >> >>> Guus, >>> It seems like a good case can be made for requiring labels to be >>> resources and an equally good case can be made for keeping the SKOS >>> spec as simple as possible. >>> I have always been impressed by the practical utility of the Dublin >>> Core approach to balancing the competing needs of complexity of design >>> and simplicity of application by providing for a "dumber" expression >>> of metadata as well as a more complex expression in the same format >>> when needed. >>> Is there any way to adopt _both_ the literal and resource approach to >>> labels and say that... if your application requires relationships >>> between labels then they may be expressed as resources and otherwise >>> they may/should be expressed as literals? And then provide a normative >>> way of expressing labels as resources that is 'compatible' with labels >>> expressed as simple literals. >>> Several weeks ago Alistair suggested dropping the notion of separate >>> SKOS and SKOS-CORE brands, since there was no longer a distinction >>> between the two. I'm wondering if perhaps this discussion presents a >>> case for a simpler SKOS-CORE and a more complex but compatible SKOS >>> specification. But then maybe this is no longer an option or has even >>> worse side effects. >> >> >> Well, I guess we could go down this road. It would mean that we do >> not define ranges for skos:prefLabel and skos:altLabel. We can still >> define a class skos:Term but do not require it to be the range of the >> label properties. The Guide could then indicate the two patterns for >> specifying terms. But it would also mean that we have to indicate how >> people should manage interoperability between vocabularies using a >> different pattern. >> >> The more I think of it, the more it seems like a good resolution. It >> follows the principle of minimal commitment. Whether it should lead >> to an distinction between a Core part and Full part (possible several >> Full parts) is another question. I would not like to go down the OWL >> road, introducing several dialects. I prefer just showing usage >> patterns in the Guide. > > > This is a possible solution, but then when you open the door to > alternate practices, the next question arieses as to "best practice." > And it also makes interoperability among different skos terminologies > difficult. > My feeling is that should only be a last resort if our community is > irreconcilably divided. > >> Guus >> >>> Just tossing some ideas around... >>> --Jon >>> On 2/28/07, Guus Schreiber <schreiber@cs.vu.nl> wrote: >>> >>>> >>>> >>>> >>>> Jan Henke wrote: >>>> > Dear all, >>>> > >>>> > I'd like to add some arguments for the labels as classes approach: >>>> > >>>> >>From an OO-point of view, the subject and object of Guus' >>>> Labelrelation can >>>> > be seen as instances. If the same labels are used in different >>>> contexts, we >>>> > duplicate them, i.e. introduce an unessacary redundance. >>>> > >>>> > I think Guus' approach also violates the OO design heuristic >>>> "Keep related >>>> > data and behaviour in one place" [1], because it externalizes >>>> some data >>>> > although it is never used without the externalizing object (done >>>> by the >>>> > inverseFunctional statement). In other words, you create a >>>> relation object >>>> > which can only be used together with one concept c, and I think >>>> in such a >>>> > case it is better to put the dependent part into c and create a >>>> reusable >>>> > object out of the rest (i.e. the label object). >>>> > >>>> > Guus' approach is basically an application of the "Introducing a >>>> new class >>>> > for a relation" pattern [2] which I always regarded as somehow >>>> working but >>>> > not really as a (nice) solution. >>>> >>>> I'm apparently not making myself clear. Of course, >>>> this proposal will >>>> not win a beauty contest. Theoretically speaking, the >>>> term-as-class approach is much cleaner and nicer; >>>> we probably all >>>> agree on that. I pointed in another message [1] to >>>> the WordNet example >>>> where we followed precisely this approach. >>>> >>>> However, the decision should not purely be based >>>> on beauty, but also >>>> on usability. Let's take an Art & Architecture >>>> Thesaurus example [2]: >>>> >>>> with terms as literals: >>>> >>>> aat:300021503 rdf:type skos:Concept. >>>> aat:300021503 skos:prefLabel "Impressionist". >>>> aat:300021503 skos:altLabel "Impressionism". >>>> >>>> with terms as classes >>>> >>>> aat:300021503 rdf:type skos:Concept. >>>> aat:300021503 skos:prefLabel aat:termURI_1. >>>> aat:300021503 skos:altLabel aat:termURI_2. >>>> aat:termURI_1 rdf:type skos:Term. >>>> aat:termURI_1 rdfs:label "Impressionist". >>>> aat:termURI_2 rdf:type skos:Term. >>>> aat:termURI_2 rdfs:label "Impressionism". >>>> >>>> [omitted datatypes and language labels] >>>> >>>> The price you pay for terms-as-classes is >>>> potentially three-fold: >>>> >>>> - more triples >>>> - less intuitive representation for naive user >>>> (thesaurus builder) >>>> through the level of indirection >>>> - the need to define a scheme for generating >>>> URIs for all terms >>>> >>>> Dependent on your viewpoint this price may be low >>>> or high and we have >>>> to balance this with the frequency of needing to >>>> represent term >>>> relations and properties in the target >>>> vocabularies for SKOS. >>>> >>>> So, I would like to hear arguments wrt this >>>> balancing issue. >>>> >>>> Guus >>>> >>>> [1] >>>> http://lists.w3.org/Archives/Public/public-swd-wg/2007Feb/0210.html >>>> [2] >>>> http://www.getty.edu/research/conducting_research/vocabularies/aat/ >>>> >>>> > Best regards >>>> > Jan >>>> > >>>> > [1] http://lcm.csa.iisc.ernet.in/soft_arch/OO_Design_Heuristic.htm >>>> > [2] http://www.w3.org/TR/swbp-n-aryRelations/#pattern1 >>>> > >>>> > >>>> > >>>> > >>>> >> -----Ursprüngliche Nachricht----- >>>> >> Von: public-swd-wg-request@w3.org >>>> >> [mailto:public-swd-wg-request@w3.org] Im Auftrag von Daniel Rubin >>>> >> Gesendet: Mittwoch, 28. Februar 2007 00:58 >>>> >> An: Guus Schreiber; SWD WG >>>> >> Betreff: Re: [SKOS] Proposed Resolution for ISSUE 26: >>>> >> RelationshipBetweenLabels >>>> >> >>>> >> >>>> >> At 03:42 AM 2/27/2007, Guus Schreiber 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, >>>> >> As I mentioned on the tcon today, I think that lexical labels >>>> >> should be represented as classes, precisely because they need >>>> >> to be able to participate in relations with other classes. I >>>> >> do not see doing this an undesirable complication of >>>> >> SKOS--this is an issue of what representation is needed in >>>> >> order to express the necessary relations. >>>> >> >>>> >>> - 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 >>>> >> To me, this approach adds undesirable complexity to SKOS. >>>> >> >>>> >> >>>> >>> 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/RelationshipsBet >>>> >> weenLabels >>>> >>> [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/ >>>> >> >> -- >> 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 Thursday, 1 March 2007 13:02:03 UTC