Re: SKOS and MeSH qualifiers

In large measure I agree with Leonard's assessment of my analysis.
A few comments follow.

On Tue, 12 Jul 2005, Leonard Will wrote:
>
> In message <Pine.CYG.4.58.0507120554440.41764@johndrake> on Tue, 12 Jul
> 2005, Robert Watkins <rwatkins@foo-bar.org> wrote
> >
> >Taking one of Leonard's examples,
> >
> >       Leukemia -- Animal models -- Congresses.
> >
> >would it be appropriate to find a document so indexed if searching for
> >"Leukemia -- Animal models", or would that be considered a different
> >pre-coordinated term?
>
> It should be an option at the time of search to specify whether an exact
> match is required or whether the search string is to be treated as
> ending with a wildcard.
>
The use of a wildcard to end the search string is significant because
the implication is that a search (if not for an exact match of the entire
pre-coordinated string) would always be for a term (or a term with,
to continue to use my questionable terminology, one or more refinements)
that is necessarily further refined. This would point to an important
difference in the way searches could be performed for MeSH and LCSH.
Using:

	term T -- refinement A

and assuming that this has been normalised (see point 1., below) then
a search for "term T" (no wildcard) on a document so indexed with MeSH
would return a hit while the same search on a document so indexed with
LCSH would not. If indeed MeSH and LCSH need to be treated differently
in this respect, then perhaps a common solution is not warranted. A
search for "term T -- *" would return a hit in both MeSH and LCSH.

> 1. It would be possible to simplify the structure if the MeSH version
> were normalised to give the entries:
>
> term T -- refinement A
> term T -- refinement B
> etc.
>
This seems entirely logical.

> 2. For those MeSH concepts that can be used both as a main term
> (descriptor) and as a qualifier, we should have only a single entry in
> the controlled vocabulary, with a note (a sub-property ?) specifying the
> ways in which that concept can be used. For those terms that can be used
> only as qualifiers, there needs to be a note specifying this.
>
This is what I was getting at in an earlier email, with:

@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix mesh: <http://www.nlm.nig.gov/mesh/schema#> .
@prefix md: <http://www.nlm.nig.gov/mesh/descriptors#> .
@prefix mq: <http://www.nlm.nig.gov/mesh/qualifiers#> .

mesh:descriptor a rdf:Class;
	rdfs:subClassOf skos:Concept;

mesh:qualifier a rdf:Class;
	rdfs:subClassOf skos:Concept;

md:economics a skos:Concept;
	rdf:type mesh:descriptor;
	rdf:type mesh:qualifier;

mq:"adverse effects" a skos:Concept;
	rdf:type mesh:qualifier;

> I still wonder whether introducing the complication of handling strings
> and qualifiers is worthwhile or appropriate at this stage. I would
> prefer to see the SKOS specification for dealing with single concepts
> being accepted and adopted, and user-oriented software being made
> available soon, rather than risking delays by introducing these other
> issues at this stage. MeSH and LCSH are important, but they were not
> developed in accordance with the current standards for thesauri, and it
> will clearly be a non-trivial job to accommodate their distinct
> structures.
>
I certainly don't want to hold up the SKOS specification! My intent was
simply to discover how best to represent MeSH qualifiers with SKOS.

-- Robert

--------------------
Robert Watkins
rwatkins@foo-bar.org
--------------------

Received on Tuesday, 12 July 2005 16:25:58 UTC