W3C home > Mailing lists > Public > public-esw-thes@w3.org > November 2003

RE: Design Issue (3) - How to label concepts?

From: Miles, AJ (Alistair) <A.J.Miles@rl.ac.uk>
Date: Thu, 6 Nov 2003 13:14:29 -0000
Message-ID: <350DC7048372D31197F200902773DF4C047479CF@exchange11.rl.ac.uk>
To: Dave Reynolds <der@hplb.hpl.hp.com>
Cc: "'public-esw-thes@w3.org'" <public-esw-thes@w3.org>

Dave I agree.

I was thinking of three properties:


	rdf:label		(domain = Resource, range = Literal)
	  ^
	  |
	soks:prefLabel  	(domain = Resource, range = Literal)

[A label which is the preferred label for a resource]


	rdf:label		(domain = Resource, range = Literal)
	  ^
	  |
	soks:altLabel  	(domain = Resource, range = Literal)
	
[A label which is an alternative but not preferred label for a resource]


	soks:prefLabel  	(domain = Resource, range = Literal)
	  ^
	  |
	soks:descriptor	(domain = Concept, range = Literal)

[A label that uniquely and unambiguously identifies a Concept within a
particular conceptual scheme such as a thesaurus.  For example, 'Java
programming language', 'Island of Java', 'Python programming language',
'Pythons (snakes)' are all good descriptors.]


Why have both a soks:prefLabel and a soks:descriptor?  

The notion of a 'descriptor' is fundamentally defined and understood to be a
lexical identifier for a concept, unique within a conceptual scheme.  This
is what a 'descriptor' is understood to be by thesaurus and KOS people (I'm
hoping!).  

The 'prefLabel' property can then be used more loosely, to indicate just a
label which is preferred above other labels, but with no additional
constraints.

To have had a property called something like 'prefLabel' but with the
function of 'descriptor' I thought would be open to misunderstanding and
unintentional misuse (i.e. people would inevitably use it in the looser
sense).    

Al. 		

-----Original Message-----
From: Dave Reynolds [mailto:der@hplb.hpl.hp.com]
Sent: 04 November 2003 12:56
To: Miles, AJ (Alistair) 
Cc: 'public-esw-thes@w3.org'
Subject: Re: Design Issue (3) - How to label concepts?



It makes sense to me to build on top of rdfs:label so that general RDFS 
processors can pick up the labels.

Thus:
     rdf:label  (domain = Resource, range = Literal)
       ^
       |
     soks:label (domain = soks:Concept)
       ^
       |
     soks:preferredLabel

Keeping the range as Literal is useful since that's the only bit of RDF that

supports xml:lang.

Dave

Miles, AJ (Alistair) wrote:

> I've added this issue to the discussion on the RDF Thesaurus wiki page
> <http://esw.w3.org/topic/RdfThesaurus>
> 
> Here is a summary:-
> 
> Issue 3 - How to label concepts?
> 
> In a thesaurus, every concept has one preferred term (label) and 0 or more
> alternative terms. 
> 
> The obvious way to model this in RDF is to have one property for linking a
> resource to a preferred label (I'll call this soks:prefLabel for now) and
> one property for linking a resource to any alternative labels (I'll call
> this soks:altLabel for now). 
> 
> This raises two design questions:- 
> 
> Question 1: domain restriction? - Do we (a) restrict the domain of these
> properties to soks:Concept or do we (b) allow them to be used with any
> resource? 
> 
> Question 2: resources or literals? - Do we (a) restrict the range of these
> properties to rdfs:Literal, or do we (b) restrict the range to some type
of
> resource? 
> 
> We may be able to re-use and/or extend existing properties, e.g.
rdfs:label,
> but what we choose to re-use depends on the resolution of these questions,
> so I'm saving a discussion of that for later. 
> 
> The choice of solution to question 2 has important implications for
> multilingual data and labelling ...
> 
> ... more at <http://esw.w3.org/topic/RdfThesaurus>
> 
> CCLRC - Rutherford Appleton Laboratory
> Building R1 Room 1.60
> Fermi Avenue
> Chilton
> Didcot
> Oxfordshire OX11 0QX
> United Kingdom
> 
> Email:        a.j.miles@rl.ac.uk
> Telephone: +44 (0)1235 445440
> 
> 
Received on Thursday, 6 November 2003 08:16:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:45:08 UTC