W3C home > Mailing lists > Public > public-esw-thes@w3.org > January 2011

Re: Ordering concepts in a Tree display

From: Christophe Dupriez <christophe.dupriez@destin.be>
Date: Thu, 20 Jan 2011 12:01:00 +0100
Message-ID: <4D3815EC.2050401@destin.be>
To: Alistair Miles <alimanfoo@googlemail.com>
CC: Tom Morris <tfmorris@gmail.com>, Jakob Voss <jakob.voss@gbv.de>, SKOS <public-esw-thes@w3.org>
Hi Alistair!

Saying that SKOS display is not SKOS business sounds strange to me: If I 
want "pure" "unhuman" data, I go toward SQL, XML or OWL.
If I want "human consumable data", I go toward SKOS, HTML (or SGML!). 
Ordering for human consumption is a must.
If you read french: http://www.askosi.org/ULB17.pdf  (slide 8)

Please let an ol'timer say that being able to associate a simple 
numerical value to a Concept to improve sorting in trees (local sort) 
has proven enough in practice for all applications I met.
In theory, it would be better to add this value to the Broader relation 
(Narrowers are generally deducted from broaders).
Going further than a simple value linked to concepts can be justified by 
theoretical examples but probably only very rare examples from 
"production-level" systems.

I propose to go further with the simple solution in a "community 
extension" to SKOS (I wrote you separately about this).
Additional property "sortKey" to Concept. If numerical XSD type, 
numerical sort; if alphabetical: alphabetical sort; if other ordered 
data type: sort along that data type.
    Label in the user language are then used as a second sort key (and 
as a primary one when there is no sortKey for the Concept).
    Idea: the sortKey could also be a reference to an orderedCollection: 
this would mean, if you need to sort this Concept, use its place in this 
orderedCollection (and not another as a Concept can be in many collections)

Have a very nice day!


Le 20/01/2011 11:31, Alistair Miles a écrit :
> So I'm sure everyone's aware of this already, but as a bit of history,
> this discussion bears on the issue:
> http://www.w3.org/2001/sw/wiki/SKOS/Issues/ConstructionOfSystematicDisplaysFromGroupings
> ...which was issue 84 from the SWDWG [1]. I just looked back at the text of
> our resolution at the time, which was:
> """
> 2008-07-01: [rrs] RESOLVED: Postpone ISSUE-84 as (a) constructing such displays
> does not require changes in the SKOS vocabulary, (b) Diego's proposal [2]
> demonstrates that some form of implementation is feasible, and (c) we don't
> have much time to investigate further. (per Antoine's message of 1 July
> [1]. [1] http://lists.w3.org/Archives/Public/public-swd-wg/2008Jul/0001.html
> [2] http://lists.w3.org/Archives/Public/public-swd-wg/2008Jan/0164.html
> """
> I.e., I think we said that defining some orderings that enable you to generate
> a systematic display of a thesaurus or classification scheme was at least
> *possible* using just skos:OrderedCollection, and Diego demonstrated an
> implementation, but we knew this wasn't an ideal solution, and would need
> further work.
> We were also aware that the algorithm needed isn't the simplest thing in the
> world. It gets a bit gnarly if you have nested collections. You also have to
> account for poly-hierarchy in the broader/narrower graph, which can be done,
> but isn't immediately obvious.
> I also remember us somewhere else (sorry, can't find a reference off-hand)
> saying that conveying presentation information - how to lay out a systematic
> display, for example - was not in scope for the original version of SKOS,
> which is why we postponed the issue.
> I think I always imagined that either you'd (1) use skos:OrderedCollection and
> figure out the algorithm that allows this information to be used to augment
> a tree display built directly from the skos:broader/skos:narrower RDF graph,
> or (2) represent your systematic display using some other data format (some
> sort of XML would be ideal, as you get hierarchy and ordering easily), in
> which case you'd have to figure out how to manage your systematic display
> data in addition to your basic broader/narrower graph and make sure the two
> weren't inconsistent, or (3) use some sort of notation coding or sort key
> (which again you'd have to manage and make sure was consistent with your
> broader/narrower graph).
> I'm not an expert on the details of systematic displays, but I could
> imagine you might need to invent a separate XML language to represent all
> the possibilities, and that that might be worth doing separately from SKOS
> (as a sort of companion).
> Cheers,
> Alistair
> [1] http://www.w3.org/2006/07/SWD/track/issues/84
> On Wed, Jan 19, 2011 at 12:37:10PM -0500, Tom Morris wrote:
>> On Wed, Jan 19, 2011 at 8:32 AM, Jakob Voss<jakob.voss@gbv.de>  wrote:
>>> "this SKOS scheme should be sorted alphabetically by
>>> skos:hiddenLabel":
>> Alphabetically according to what collating sequence?  The publisher's?
>>   The consumer's?  Some globally mandated collating sequence?
>> Tom
Received on Thursday, 20 January 2011 11:01:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:46:06 UTC