AW: [SKOS] Proposed Resolution for ISSUE 26: RelationshipBetweenLabels

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.

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/
> 
> 
>

Received on Wednesday, 28 February 2007 10:14:02 UTC