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

Hi,
Hierarchy code and sort key should be viewed as different. My message probably 
did not stress this sufficiently, sorry for that. This has also to do with what 
we need in our local system
and what of that need to be exchanged through standards such as SKOS.

In classification management hierarchy code and sorting key work together and 
fulfil different functions: we need a sort key to be able to sort entities on 
the same hierarchy, we need hierarchy code to be able to manipulate hierarchy 
levels on the interface or in exports. Everything in classification is a result 
of a subdivision and hence everything belong to some facet and this facet 
belongs to another facet -  collapsing or expanding of hierarchy on the screen 
is paramount while the statement 'this is an array' or 'this is a facet' has 
little meaning. This would be so for all complex system that contains numerous 
coordinated and nested arrays facets and subfacets and subfacets of subfacets etc.

Last year at this list Antoine Isaac suggested that a readily extracted 
hierarchy code which we may have in our management tools need not to be passed 
through exchange of vocabulary as it can be easily generated from the existing
BT data - which is a valid point. Hence a hierarchy code should remain an issue 
for system on a local level and can be exported as sql table for those needing 
or implementing and cannot be bothered to generate their own hierarchy code.

On the other hand I have no doubt, that sortkey is important to export with SKOS 
data and that people will create an extension for this.

regards

Aida


On 07/02/2011 09:54, Christophe Dupriez wrote:
> Hi Stella!
>
> Thank you for the precision and excuse me for overlooking the ISO 25954 
> ThesaurusArray.
> The problem I see is the same than with SKOS when displaying a tree:
> * Is the concept in any skos:orderedCollection / iso:ThesaurusArray?
> * If in multiple ones, which one applies?
> * If only one, does it applies here?
> I feel that mechanism as heavy and difficult for everybody (the programmer and 
> the thesaurus maintainers)
>
> My proposal to your objection would be to have also a siblingKey attribute in 
> SKOS relation "isTopConceptOf" (which would then have to reified in RDF like 
> broader...)
> (and in ISO 25954 element TopLevelRelationship)
>
> Have a nice day!
>
> Christophe
>
> Le 7/02/2011 10:33, Stella Dextre Clarke a écrit :
>> On 07/02/2011 08:34, Christophe Dupriez wrote:
>>> 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)
>> Hi Christophe,
>> Just a small clarification in case it is not clear. The ISO 25964-1 data 
>> model *does* provide for ordering of the sibling concepts in 
>> "ThesaurusArray". The ability to sort siblings into a systematic order is not 
>> seen as part of the hierarchical relationship per se, since even a flat list, 
>> or the top level of a vocabulary, might need to be ordered.
>>
>>  But the nature of the sorting mechanism to use is left open.
>> Stella
>>
>> -- 
>> *****************************************************
>> Stella Dextre Clarke
>> Information Consultant
>> Luke House, West Hendred, Wantage, OX12 8RR, UK
>> Tel: 01235-833-298
>> Fax: 01235-863-298
>> stella@lukehouse.org
>> *****************************************************
>