RE: RE : Scientific and common names in SKOS

not bad... I like this extension... the only problem is at the level of
indexing....
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
common-names)...
 
but i suppose is at the level of metadata associated to the documents... not
a problem at the representation of my KOS.
 
thanks
Margherita
 

 -----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;
public-esw-thes@w3.org 
 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:
 
 
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 18:29:06 UTC