- From: Johan De Smedt <johan.de-smedt@tenforce.com>
- Date: Mon, 7 Feb 2011 10:59:43 +0100
- To: "'Christophe Dupriez'" <christophe.dupriez@destin.be>, "'Aida Slavic'" <aida@acorweb.net>
- Cc: "'Skos'" <public-esw-thes@w3.org>
- Message-ID: <4d4fc299.cc850e0a.0889.ffff9c17@mx.google.com>
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
Attachments
- image/jpeg attachment: image001.jpg
Received on Monday, 7 February 2011 10:00:30 UTC