- From: Aida Slavic <aida@acorweb.net>
- Date: Mon, 07 Feb 2011 14:29:29 +0000
- To: Skos <public-esw-thes@w3.org>
- Message-ID: <4D5001C9.2080706@acorweb.net>
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 >> ***************************************************** >
Received on Monday, 7 February 2011 14:29:03 UTC