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

Hi!

If SKOS community wants to go further than one concept attribute for 
what I would propose to call a "siblingKey" (a value used to sort 
sibling concepts), an attribute to the broader relation is therefore needed.
This would be easy in XML (ISO 25954 but I do not see any ordering 
information in the HierarchicalRelationship element) or with TopicMaps 
but it requests reification of the RDF relation in SKOS.

Knowing other problems (data about approval work-flow for relations for 
instance), may I suggest starting the definition of SKOS-XR (eXtended 
Relations) to open the design space to this kind of enhancement ?
Who has the "authority" (interest!) to manage such a project?

Have a nice day!

Christophe

Le 6/02/2011 20:21, Aida Slavic a écrit :
> 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
>>>
>>
>>