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

Hi Christophe,

 

This may go beyond the extension of SKOS and ISO 25964-1 is indeed more complete in modeling
thesauri.

 

However, I think of 2 possible ways to make extensions to SKOS.

 

For SKOS, reification may be used or OWL2 annotations

- Define your annotation property/ies (e.g. my-annotation:siblingKey)

- Assign the key (together with potential other annotations) to the relation using:

owl:Axiom [

   owl:annotatedSource <concept_a> ;

   owl:annotatedTarget <concept_b> ;

   owl:annotatedProperty <skos:broader> ;

   my-annotation:siblingKey “key-value” .

  ]

 

skos:OrderedCollection may be another way to get items ordered.

In this case you also need some extensions

1- to determine when to use a particular collection.

  e.g. for sorting the narrower terms of concept <a>,  a

       <collection-x> example:sortNarrowerFrom <a> .

        could be used.

2- identify the sorting algorithm used.

  e.g. collections could be typed or use other properties (example:sortAlgorithm).

Such a property may be added to the collection

 

 

Kind Regards,

 

Johan De Smedt 

Chief Technology Officer

 

mail:  <mailto:johan.de-smedt@tenforce.com> johan.de-smedt@tenforce.com

mobile: +32 477 475934

home page:  <http://www.tenforce.com/> http://www.tenforce.com

 

mail-TenForce

 

From: public-esw-thes-request@w3.org [mailto:public-esw-thes-request@w3.org] On Behalf Of Christophe
Dupriez
Sent: Monday, 07 February, 2011 09:35
To: Aida Slavic
Cc: Skos
Subject: 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  <mailto:christophe.dupriez@destin.be> <christophe.dupriez@destin.be>
Organization: DESTIN inc. SSEB
Date: Fri, 14 Jan 2011 12:56:08 +0100
To:  <mailto:public-esw-thes@w3.org> <public-esw-thes@w3.org>
Subject: Ordering concepts in a Tree display
Resent-From:  <mailto:public-esw-thes@w3.org> <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