RE: how to: ordered collection of a Concept

For MeSH, an example of one concept within one family is 'Seaweed':  
http://www.nlm.nih.gov/cgi/mesh/2014/MB_cgi?mode=&term=Seaweed 

An example that one concept belongs to multiple immediate families hence has multiple notations is "West Nile Virus"
http://www.nlm.nih.gov/cgi/mesh/2014/MB_cgi?mode=&index=14285

The notation system took a long time and millions of considerations to build. 
Marcia
________________________________________
From: Stella Dextre Clarke [stella@lukehouse.org]
Sent: Monday, November 18, 2013 1:24 PM
To: vladimir.alexiev@ontotext.com
Cc: public-esw-thes@w3.org; L.Will@willpowerinfo.co.uk; ZENG, MARCIA
Subject: Re: how to: ordered collection of a Concept

Hi Vladimir,
It's good to know Johan's changes are helping you sort things out
(although I did not find an attachment with the diagram you mentioned).

Sorry about the duff URL. If you still want to see the National Library
of Medicine's MeSH tree of arrays without node labels, try going to
<http://www.nlm.nih.gov/mesh/MBrowser.html> and then select the
"Navigate from tree top" button. (In general, handling node labels
demands extra sophistication in the software required; hence few
thesaurus editors embark on it unless they have strong incentives and a
healthy budget.)

All the best with the project,
Stella
-------------------


On 17/11/2013 21:08, Vladimir Alexiev wrote:
> Hi Stella!
>
>> In earlier correspondence I think you said there is a commitment
>> to apply the ISO 25964 model to the AAT?
>
> As much as possible. Let me give an example: - Johan has agreed to
> use xl:prefLabel for the label of an Array (because rdfs:label is not
> supposed to point to xl:Label) - AAT has a few secondary labels for a
> few of the Arrays. We'll use xl:altLabel to represent them, unless
> Getty totally gives up such labels. This is a very minor deviation
> from the standard, which is an extension (i.e if someone doesn't want
> such labels, they can just ignore them)
>
>> would not mix up guide terms with concepts, but would find a way of
>> ensuring that hierarchical relationships are established *only*
>> between concepts
>
> Getty has *one* polyhierarchy that uses different "subject types":
> Facets, Hierarchies, Guide Terms, and Concepts. My intention is to:
> 1. represent all of Getty's Facets, Hierarchies and Guide Terms as
> iso:ThesaurusArray. 2. represent concepts as skos:Concept 3.
> represent the hierarchical relations using different properties:
> skos:Concept -skos:narrower-> skos:Concept -iso:subordinateArray->
> iso:ThesaurusArray iso:ThesaurusArray -skos:member-> skos:Concept
> iso:ThesaurusArray -skos:member-> iso:ThesaurusArray 4. "shortcut"
> skos:narrower properties to "go through Arrays". You can see an
> example in the attached diagram: the relation containers
> -skos:narrower-> vessels spans 2 levels in the original AAT
> hierarchy.
>
> Would you suggest something else?
>
>> the expression "parent"
>
> I mean the node above a given node in the hierarchy, be that a
> concept or array or whatever. (3 shows the different properties
> used)
>
>>> Consider these two cases that actually appear in AAT: 1. C1 <
>>> C2,C3: C1 (a concept) is parent of C2,C3 which are ordered 2. C1
>>> < GT1 < C2,C3: C1 is parent of GT1 (a guide term), which in turn
>>> is parent of C2,C3 which are ordered
>
> You give good examples in your doc. Here they are, I've added the
> things in *...*
>
> Case 1 cycles *inferior array with no node label* monocycles
> bicycles tricycles
>
> Case 2 milk <milk by fat content> : *Guide Term represented as Array
> with node label* skimmed milk semi-skimmed milk full fat milk
>
>>> case1: it's an *inferior* array: it does not exist separately
>>> from C1, it is the *same* as C1. I agree with Leonard's
>>> suggestion to use an Array without node label
>
> *Anonymous* is the word I use to describe an Array with no node
> label. *Inferior* is the word I use to describe an Array that sprung
> into existence only to cause a Concept's children to be ordered.
>
>> Whenever a thesaurus concept has more than one narrower concept at
>> one level down, those narrower concepts form a subordinate array.
>> (But I would not judge the subordinate array to be "the same as"
>> its broader concept.)
>
> In the Getty database there are 2  "subject records" for case2:
> "milk" and <milk by fat content>.
>
> But there is only 1 "subject record" for case1: the concept
> "cycles". So by *same* I mean 1 record in the Getty database.
>
> In the RDF representation I'll have 2 nodes in both cases (there's no
> other way since Concept and Array are disjoint), but in case1 they'll
> share the ID in their URL, e.g.: aat:300123456    # concept "cycles"
> aat:300123456/array    # inferior/anonymous array used to order the
> children of "cycles"
>
>> Case 1 in the attachment shows an array with no node label. What's
>> the problem?
>
> The display is ok: it shows no blank line (no level) for the array
> with no label.
>
>> Most of the thesauri I encounter do not have any node labels
>
> As soon as people don't display anonymous arrays as a level in the
> hierarchy, I'm happy.
>
>> AAT guide terms that are not really node labels (because they are
>> intended to show intermediate concepts in the hierarchy that are
>> not recommended for use in indexing. e.g. "<emergency vessels>" ID
>> 300232863)
>
> None of the AAT Facets, Hierarchies, or Guide Terms are intended for
> indexing (but Getty's converting some Guide Terms to true Concepts).
>
>>> This will work fine for AAT, but if someone makes a whole tree of
>>> Arrays without labels, what would that mean? Oh well, that's for
>>> thesaurus consumers to worry about :-)
>> Take a look at the  MeSH Browser and you will find very extensive
>> trees of concepts without node labels.
>> <http://www.nlm.nih.gov/cgi/mesh/2013/MB_cgi>
>
> This URL doesn’t work.
>
>> (a) in cases like the one of "emergency vessels" cited above, the
>> concepts were recognised as such
>
> If Getty decides to turn the Guide Term <emergency vessels> into a
> true Concept, it will get mapped to skos:Concept. Else it'll be
> mapped to iso:ThesaurusArray.
>
> Would you suggest something else?
>
>> As I see it part of your challenge arises from wanting to display
>> guide terms as though they were concepts, and thus eligible for
>> participating in hierarchical relationships. One workaround might
>> be to ignore all those angle brackets and treat all the guide terms
>> as true concepts. But if  a hierarchy like that is used for
>> automatic inferencing, as in the Semantic Web, it would generate
>> some peculiar inferences, such as: ' "watercraft by specific type"
>> is a type of watercraft')
>
> Exactly! Everything mapped to skos:Concept is fair game for
> indexing, and skos:narrower can be used in query expansion. So
> treating Guide Terms as skos:Concepts is not an option.
>
> --
>
>>> If ISO does not pose constraints on notations, how did you judge
>>> that "300106739" is not a notation?
>> The first clue is that it looks typical of the sort of string
>> commonly used for thesaurus identifiers. Confirmation comes from
>> the label "ID" shown on the AAT online.
>
> My point is the same as Marcia's: if ISO does not want "random" IDs
> to be used as notation, it should say so. You quoted from ISO
> definitions and I didn’t see such restriction. It's in examples: but
> I think it should also be in the definitions. But that's a very minor
> point: I'm happy to use dc:identifier if Marcia says so.
>
> Cheers! Vladimir
>


--
*****************************************************
Stella Dextre Clarke
Information Consultant
Luke House, West Hendred, Wantage, OX12 8RR, UK
Tel: 01235-833-298
Fax: 01235-863-298
stella@lukehouse.org
*****************************************************

Received on Monday, 18 November 2013 19:32:40 UTC