Re: Ordering concepts in a Tree display / possibly more than a sort key

Hi,

A bit from classification perspective...The order of foci in an array is 
carefully observed and rigorously maintained in classification schemes.
Ranganathan summarised devices used across classification schemes as follows:
- chronological (evolutionary) e.g. systematic botany, zoology
- geographical (e.g. subdivision of art style by place, subdivision of history 
by place) -  in faceted classifications this is achieved by using facet of place
- subject device (forming a facet in relation to a specific defined property or 
by relation/dependence to a subject e.g. subdivision of visual art by subject, 
subdivision of economics by industries)
- alphabetical
- enumeration

Classification schemes combine all of the above devices. The purpose of these 
rules is to reduce the size of a schedule (avoiding enumeration) and secure 
conformity with respect to canons of consistent sequence, helpful sequence, 
mnemonics, hospitality in array, hospitality in chain. Hence the order of ideas 
is very carefully determined. We fix this order in schemes in two ways that 
always guarantee a logical and systematic (semantic) order mechanically:

(1) through a notational system (as Joe Tennis mentioned earlier), decimal and 
expressive notations using letters, numerals and punctuation signs are designed 
in such a way that classes will always fall in a desired meaningful order. 
Faceted or syntactical expressive notational systems will also handle the 
correct ordering of complex coordinated expressions.
For instance, what should be ordered first?:
a  notation expressing /Italian literature-18th century/ or /Italian 
literature-poetry-18th century/,
or a notation expressing/Italian literature - poetry - in Switzerland -19th 
century/
or /Italian literature - literary criticism/.
There is obviously a sense of hierarchy here and sense of a general to specific 
order that has to be preserved.  Rules for ordering of notations are called  
'filing rules'. These rules are established and interpreted intellectually and 
it is often the case that they cannot be supported by computer programs unless 
additionally coded.

However: We cannot rely 100% on notation to order classes, handle hierarchy or 
parse facets in all classification schemes or indeed use notation for mechanical 
ordering by computer programs - at least not without additional coding. It is 
also important not to confuse classification structure with the type of 
notational system used in a certain system. Reasons:
Faceted classifications do not always have a 'faceted notation'. A typical 
example is Bliss Bibliographic classification (a faceted classification proper) 
- not only does it not have a hierarchically expressive or facet expressive 
notation but this scheme itself may represent classes as coordinated, when these 
are logically subsumed. Bliss notation supports building of complex classes but 
once built notation cannot be parsed (i.e. the system is 'synthetic' but not 
'analytic') - the advantage of this approach is simpler notational device that  
can be ordered mechanically as it does not contain 'syntax symbols'. In 
addition,  classifications with otherwise hierarchically expressive decimal 
notations (e.g. 531.1 is subclass of 531 and 531 is subclass of 53) may also 
occasionally purposefully or entirely accidentally fail to express a concept 
hierarchy (examples of these can be found in Dewey, UDC, Colon Classification, 
Library of Congress Classifications). One can chose either to have simple 
ordering device  i.e. semantically void notation or notation that is expressive 
and holds full information of hierarchy and syntax and can be parsed but 
requires some input to make it work online. Classification designers often try 
to find a middle solution depend of the purpose of the system

(2) in classification management databases for analytico-synthetic systems we 
have to  'translate' sequence and filing order rules into something similar to 
'sortKey' described by Mike Collett below, because of the fact that notational 
expressions using a combination of letters, numerals and punctuation symbols as 
facet indicators cannot be correctly sorted automatically by any of the standard 
character coding tables.
It is up to individual database management tools to solve this. For instance, 
the UDC management system translates notation into special codes that ensure 
both: accurate ordering and parsing of UDC complex numbers by programs. For this 
we use a set of algorithms handling UDC specific ordering rules. In addition to 
this we also maintain a separate hierarchy code which captures BT/NT 
relationships as a single sequence (across 68,000 classes) - this help us manage 
hierarchical relationships independently from notation. With each annual UDC 
update the hierarchy codes are 'refreshed'.
UDC notation 37.015 Special pedagogic sciences - when coded looks as follows 
37.q15.-
[This notation consist of two numbers 37 Education and special auxiliary number 
.015 Special pedagogic science, .0  transformed into .q is a facet indicator 
meaning the the this concept is of a certain kind and can be combined based on a 
certain set of rules.

What may be the main issue is that in exchanging or at the user end 
classifications the place for sorting, filing or hierarchy codes is not envisaged.

Kind regards

Aida


On 14/01/2011 16:09, Mike Collett wrote:
> We use a sortkey
> eg<zthes:termNote label="sortKey">13</zthes:termNote>
>
> We have found that this has been mostly OK as a single key within a concept
> scheme (vocabulary) and we can manage different sortkeys for different
> concept schemes.
>
> By default we display alphabetically by the preferred label of the user's
> preferred language (set by browser or computer settings) if it exists, if
> not then in English if it exists, if not then by the first preferred label.
>
> Some polyhierarchies need to have a concept in a different order in
> different parts of the tree. Then the relationship needs to hold the
> sortkey.
>
> In Zthes type encoding this is easy
> eg
> <relation>
> <relationType>BT</relationType>
> <termId>xyz:1234</termId>
> <termSortkey>13</termSortkey>
> </relation>
>
> Not sure how to do this in SKOS.
>
> The effect could be
> Vehicles
>   NT (sortkey 1) Single wheeled vehicles
>   NT (sortkey 2) Bicycles
>   NT (sortkey 3) Tricycles
>   NT (sortkey 4) Four wheeled vehicles
>   NT (sortkey 5) Vehicles with more than 4 wheels..
>
> Popular vehicles
>   NT (sortkey 1) Cars
>   NT (sortkey 2) Motorbikes
>   NT (sortkey 3) Bicycles
>   NT (sortkey 4) Skateboards
>
> With Bicycles needing two different sortkeys.
>
> Cheers
> Mike 7:-D
> -----------
> Mike Collett
> Vocabulary Management Group
> +44 7798 728 747
> ------------
> www.vocman.com
> mike@vocman.com
>
>
>
>> From: Christophe Dupriez<christophe.dupriez@destin.be>
>> Organization: DESTIN inc. SSEB
>> Date: Fri, 14 Jan 2011 12:56:08 +0100
>> To:<public-esw-thes@w3.org>
>> Subject: Ordering concepts in a Tree display
>> Resent-From:<public-esw-thes@w3.org>
>> Resent-Date: Fri, 14 Jan 2011 11:57:37 +0000
>>
>> Happy New Year to all the Simple Knowledge Organization Systems workers!
>>
>> Does anyone have designed a way to specify concept ordering when
>> displaying a tree of concepts?
>>
>> Usually, alphabetical ordering is the best to display narrower concepts
>> of a given concept.
>> But sometimes (for instance, with historical period), there is "natural"
>> ordering of concepts which is much better.
>> I would like to add a field with the ordering criteria (stronger than
>> the prefLabel in the user language).
>>
>> Anyone has done something for this so I do not reinvent the wheel:
>>
>> Vehicles
>> NT Single wheeled vehicles
>> NT Bicycles
>> NT Tricycles
>> NT Four wheeled vehicles
>> NT Vehicles with more than 4 wheels...
>>
>> Wishing you a very nice w.e. !
>>
>> Christophe
>>
>
>
>