W3C home > Mailing lists > Public > public-esw-thes@w3.org > October 2008

RE: RE : Scientific and common names in SKOS

From: Sini, Margherita (KCEW) <Margherita.Sini@fao.org>
Date: Thu, 02 Oct 2008 20:28:21 +0200
To: Alistair Miles <alistair.miles@zoo.ox.ac.uk>, Antoine Isaac <Antoine.Isaac@KB.nl>
Cc: Alan Ruttenberg <alanruttenberg@gmail.com>, Leonard Will <L.Will@willpowerinfo.co.uk>, public-esw-thes@w3.org
Message-id: <BA453B6B6B217B4D95AF12DBA0BFB669029DB58F@hqgiex01.fao.org>
not bad... I like this extension... the only problem is at the level of
how i tell the indexing system that this is a scientific paper (and so i
should retrieve it when i search using the scientific label) or is a
non-scientific paper (and so i should retrieve it when i search using
but i suppose is at the level of metadata associated to the documents... not
a problem at the representation of my KOS.

	-----Original Message----- 
	From: Alistair Miles [mailto:alistair.miles@zoo.ox.ac.uk] 
	Sent: Thu 10/2/2008 18:30 
	To: Antoine Isaac 
	Cc: Alan Ruttenberg; Sini, Margherita (KCEW); Leonard Will;
	Subject: Re: RE : Scientific and common names in SKOS

	FWIW I wrote up some text on extending SKOS a while ago, using
	scientific names as an example:

	There I use a sub-property pattern, although note how prefLabel and
	altLabel are refined to prevent any clash of prefLabels. Here's the
	Example: Specialised Labelling Properties
	The SKOS Core Vocabulary has declared three properties for assigning
	lexical labels to concepts: skos:prefLabel, skos:altLabel and
	skos:hiddenLabel. These properties allow you to assign preferred,
	alternative, and hidden lexical labels to concepts. However, you may
	have more specialised requirements. You may need to have different
	preferred and alternative lexical labels for different users. For
	example, you may to want to supply different labels for scientists
	non-scientists, or for doctors and patients, or for youths and
	To do this, you may extend SKOS Core by declaring refinements of the
	skos:prefLabel and skos:altLabel properties. E.g.:
	eg:prefScientificLabel a rdf:Property;
	  rdfs:label 'preferred scientific label';
	  skos:definition 'The preferred lexical label for scientists.';
	  rdfs:subPropertyOf skos:prefLabel;
	eg:altScientificLabel a rdf:Property;
	  rdfs:label 'alternative scientific label';
	  skos:definition 'An alternative lexical label for scientists.';
	  rdfs:subPropertyOf skos:altLabel;
	eg:prefNonScientificLabel a rdf:Property;
	  rdfs:label 'preferred non-scientific label';
	  skos:definition 'The preferred lexical label for non-scientists.';
	  rdfs:subPropertyOf skos:altLabel;
	eg:altNonScientificLabel a rdf:Property;
	  rdfs:label 'alternative non-scientific label';
	  skos:definition 'An alternative lexical label for non-scientists.';
	  rdfs:subPropertyOf skos:altLabel;
	The crucial bit of the above is the use of rdfs:subPropertyOf - each
	of the above properties has been declared as a sub-property of a SKOS
	Core property. This is the formal mechanism by which you declare a
	property refinement.
	Now let's use these extensions:
	eg:concept001 a skos:Concept;
	  eg:prefScientificLabel 'Clamydera maculata';
	  eg:prefNonScientificLabel 'Spotted bowerbird';
	eg:concept002 a skos:Concept;
	  eg:prefScientificLabel 'acetylsalicylic acid';
	  eg:altScientificLabel '2-acetoxybenzoic acid';
	  eg:prefNonScientificLabel 'aspirin';
	The important feature of extension by refinement is that RDFS
	inference can be used to obtain a 'dumbed-down' SKOS Core description
	of the concepts you declare. The above example, by RDFS inference,
	implies the following:
	eg:concept001 a skos:Concept;
	  skos:prefLabel 'Clamydera maculata';
	  skos:altLabel 'Spotted bowerbird';
	eg:concept002 a skos:Concept;
	  skos:prefLabel 'acetylsalicylic acid';
	  skos:altLabel '2-acetoxybenzoic acid';
	  skos:altLabel 'aspirin';
	Note also that, in the above example, only the eg:prefScientificLabel
	property was made a sub-property of skos:prefLabel; the three others
	were declared as sub-properties of skos:altLabel. This is to avoid
	violating the constraint on skos:prefLabel after 'dumbing-down' via
	RDFS inference that a concept may only have one preferred lexical
	label per language. I.e. you should only refine skos:prefLabel once,
	although you may refine skos:altLabel any number of times. Which of
	your specialised labelling properties you choose to make a refinement
	of skos:prefLabel depends on how you want your scheme to appear by
	default, under a dumbed-down representation.
	On Thu, Oct 02, 2008 at 04:23:50PM +0200, Antoine Isaac wrote:
	> Alan,
	> I guess you're right technically speaking. But as far as I could
understand Margherita's case, it would have been dangerous to gather all
these different labels under a unique "English" profile. If there is a need
for standard "en" literals, I would think it is better to have an explicit
representation built during the conversion process (e.g. duplicating all the
"x-en-common" literals into "en" ones) rather than having tool making
interpretations that may not correspond to the subtle usage differences
Margherita has in mind (also maybe resulting in several prefLabels, one
derived from common English and the other from the scientific English). But
well that's just my two cents.
	> Antoine
	> -------- Message d'origine--------
	> De: public-esw-thes-request@w3.org de la part de Alan Ruttenberg
	> Date: jeu. 02/10/2008 12:16
	> À: Sini, Margherita (KCEW)
	> Cc: Leonard Will; public-esw-thes@w3.org
	> Objet : Re: Scientific and common names in SKOS
	> FWIW, I'm a little dubious about the language tag encoding. I
suspect that
	> there are many tools that expect one of the standard language tags
and will
	> not be aware that there is an english tag at all.
	> -Alan
	> On Wed, Oct 1, 2008 at 4:04 PM, Sini, Margherita (KCEW) <
	> Margherita.Sini@fao.org> wrote:
	> > Thanks Leonard and to all for the reply.
	> >
	> > I think Antoine solution would be better, as i can specify the
	> > terms between all the scientific names ("@en-x-scientific") and
	> > preferred
	> > between the common names ("@en-x-common").
	> > But combining Antoine solution and Stephen solution (adding a
	> > attribute
	> > such as fao:type="common") would be event better.
	> >
	> > I also like the possibility of creating relationships between
terms (such
	> > as
	> > expressed with SKOS eXtension for Labels XL) but this seems to me
do not
	> > solve the problem for indexing or retrieving pertinent info...
	> >
	> > This is very important, because while indexing or retrieving
document we
	> > can/should somehow establish the context for the use of the same
concept: I
	> > may decide to tag a scientific document with the URI + a tag
specifying it
	> > is
	> > a scientific document or tag a document about a receipt of a
potato with
	> > the
	> > same URI + a tag specifying this is a "general audience"
	> > I do not want to go back to term indexing, but seems to me that
URI for
	> > indexing may not be enough: we may need to attach some other
	> >
	> > regards
	> > Margherita
	> >
	> >        -----Original Message-----
	> >        From: public-esw-thes-request@w3.org on behalf of Leonard
	> >        Sent: Tue 9/30/2008 13:43
	> >        To: public-esw-thes@w3.org
	> >         Cc:
	> >        Subject: Re: Scientific and common names in SKOS
	> >
	> >
	> >
	> >
	> >         On Tue, 30 Sep 2008 at 08:00:35, "Sini, Margherita
	> >        <Margherita.Sini@fao.org> wrote
	> >        >The problem is that I wish not to use altLabels for
	> > names,
	> >        >because the concept may have actually many more others
	> > In
	> >        >fact i wish that people while indexing or searching
documents, they
	> >        >could use a common name OR a scientific name based in
their needs
	> > (a
	> >        >document on a receipt of potato or a scientific treaty on
	> > species).
	> >
	> >        In a well-structured indexing and retrieval system with a
	> >        thesaurus, it should be possible to retrieve documents by
	> > on
	> >        preferred _or_ non-preferred (alt) terms. That is the
reason for
	> > having
	> >        altLabels. The "preferred" term is somewhat arbitrarily
	> > (though
	> >        for this purpose we try to choose the term most likely to
	> > sought),
	> > to
	> >        act as a label for the concept and to link it with
documents being
	> >        indexed.
	> >
	> >        If an indexer seeks to use an altLabel when linking a
concept to a
	> >        document, the system should automatically use the
prefLabel in
	> >        constructing the link. It may or may not tell the indexer
that it
	> > has
	> >        done this. (It may in fact use a concept number or other
code rather
	> >        than either of the labels.)
	> >
	> >        If a searcher searches with an altLabel, the system should
	> > automatically
	> >        substitute the prefLabel in constructing a search
statement. It may
	> > or
	> >        may not tell the searcher that it has done this.
	> >
	> >        Two other issues arise:
	> >
	> >        A. If the need is to display lists of documents grouped
	> > subject
	> >        labels, optionally using either common or scientific
names, then you
	> >        will have to give the labels a type attribute, as has been
	> > suggested,
	> > so
	> >        that the correct one can be chosen in each case. This may
not be
	> >        practicable, however, because:
	> >
	> >        (1) many organisms do not have common names, or have
several common
	> >        names, and there is often not a one-to-one relationship
	> > common
	> >        and scientific names;
	> >
	> >        (2) listing documents under individual thesaurus terms is
	> > usually
	> >        sufficient to produce a useful list. A useful classified
	> >        normally requires the pre-coordination of more than one
	> > (e.g.
	> >        "potatoes : diseases" or "potatoes : prices") and SKOS
does not yet
	> >        provide for pre-coordination.
	> >
	> >        B. The "SKOS eXtension for Labels (XL)" provides at
	> >        <http://www.w3.org/TR/skos-reference/#xl-label-relations>
	> >        for the expression of relationships between different
label types.
	> > We
	> >        have done the same thing in the British Standard DD8723-5
data model
	> > at
	> >
	> >        which provides for the equivalence relationship to have a
	> >        attribute.
	> >        Example 91 given in the SKOS-XL document shows how one
label can be
	> >        shown to be an acronym of another, but the relationship
could be
	> >        specified as "common name / scientific name".
	> >
	> >        Leonard Will
	> >        --
	> >        Willpower Information       (Partners: Dr Leonard D Will,
Sheena E
	> > Will)
	> >        Information Management Consultants              Tel: +44
(0)20 8372
	> > 0092
	> >        27 Calshot Way, Enfield, Middlesex EN2 7BQ, UK. Fax: +44
(0)870 051
	> > 7276
	> >        L.Will@Willpowerinfo.co.uk
	> > Sheena.Will@Willpowerinfo.co.uk
	> >        ---------------- <URL:http://www.willpowerinfo.co.uk/>
	> > -----------------
	> >
	> >
	> >
	> >
	> >
	Alistair Miles
	Senior Computing Officer
	Image Bioinformatics Research Group
	Department of Zoology
	The Tinbergen Building
	University of Oxford
	South Parks Road
	OX1 3PS
	United Kingdom
	Web: http://purl.org/net/aliman
	Email: alistair.miles@zoo.ox.ac.uk
	Tel: +44 (0)1865 281993

Received on Thursday, 2 October 2008 18:29:06 UTC

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