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:

http://isegserv.itd.rl.ac.uk/cvs-public/~checkout~/skos/drafts/appextensions.html#hExSpecLabelling

There I use a sub-property pattern, although note how prefLabel and
altLabel are refined to prevent any clash of prefLabels. Here's the
extract:

---
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 and
non-scientists, or for doctors and patients, or for youths and adults.

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

Hth,

Al.

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 preferred
> > terms between all the scientific names ("@en-x-scientific") and the
> > preferred
> > between the common names ("@en-x-common").
> > But combining Antoine solution and Stephen solution (adding a cutom
> > 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" document....
> > 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 info...
> >
> > regards
> > Margherita
> >
> >        -----Original Message-----
> >        From: public-esw-thes-request@w3.org on behalf of Leonard Will
> >        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 (KCEW)"
> >        <Margherita.Sini@fao.org> wrote
> >        >The problem is that I wish not to use altLabels for scientific
> > names,
> >        >because the concept may have actually many more others altLabels...
> > 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 the
> > species).
> >
> >        In a well-structured indexing and retrieval system with a linked
> >        thesaurus, it should be possible to retrieve documents by searching
> > on
> >        preferred _or_ non-preferred (alt) terms. That is the reason for
> > having
> >        altLabels. The "preferred" term is somewhat arbitrarily chosen
> > (though
> >        for this purpose we try to choose the term most likely to be
> > 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 under
> > 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 between
> > common
> >        and scientific names;
> >
> >        (2) listing documents under individual thesaurus terms is not
> > usually
> >        sufficient to produce a useful list. A useful classified display
> >        normally requires the pre-coordination of more than one concept
> > (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
> >        <http://schemas.bs8723.org/2008-06-03/DD8723-5/Model/Model.jpg>
> >        which provides for the equivalence relationship to have a "role"
> >        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
Oxford
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 16:30:46 UTC