- From: Guus Schreiber <schreiber@cs.vu.nl>
- Date: Wed, 28 Feb 2007 17:55:54 +0100
- To: Jon Phipps <jphipps@madcreek.com>
- CC: SWD WG <public-swd-wg@w3.org>
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. 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 Wednesday, 28 February 2007 16:56:19 UTC