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

RE : Scientific and common names in SKOS

From: Antoine Isaac <Antoine.Isaac@KB.nl>
Date: Thu, 2 Oct 2008 16:23:50 +0200
Message-ID: <68C22185DB90CA41A5ACBD8E834C5ECD04953E39@goofy.wpakb.kb.nl>
To: "Alan Ruttenberg" <alanruttenberg@gmail.com>, "Sini, Margherita \(KCEW\)" <Margherita.Sini@fao.org>
Cc: "Leonard Will" <L.Will@willpowerinfo.co.uk>, <public-esw-thes@w3.org>


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.


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

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/>
> -----------------
Received on Thursday, 2 October 2008 14:24:32 UTC

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