Can't we just order enumerated values alphabetically (like other strings)?

I guess you think of use cases like "good", "medium", and "bad" (in that order),
but is this needed so desperately that we should do so much work (and inclusion
of special code in SMW) to get it? Currently no storage access ensures any
ordering (other than the ones that sort according to the "natural" order of the
results), and changing this (even if we could implement it somehow) for selected
special properties seems problematic. The only clean way (API-wise) would be to
support n-ary special properties, which allow an optional sort key in addition
to the text.

But even in the above case, one could always use "1 (good)", "2 (medium)", and
"3 (bad)" or something similar to get the deisred order from the alphabet.

info wrote:

An alphabetical sort wouldn't let you query for [[quality:=>2 (medium)]].

It was cool that ordered enumeration worked in my prototype implementation, but
I agree user needs should drive. We could ask for feedback, meanwhile I marked
this bug low-priority.

Ittay Dror on semediawiki-user asked for it:

"i want then to be able to list all components for a given version (something

like [[product_version:=<1.3]]). version names can be anything (e.g. 'xp')."

but he (she?) rolled his own code anyway,
http://www.mail-archive.com/semediawiki-user@lists.sourceforge.net/msg00144.html
He put an explicit sequence number in the special property to ensure ordering:

[[Allows value:=Blocker=7]]

This feature could be added to current code (or could be a second
Type:OrderedEnum implementation, but I think you're not keen on a multitude of
types -- no type boolean ;-) ).

I had a few other "near misses" where a guaranteed special property order would
have been useful; IIRC gluing two string properties together to avoid string
length limitations, and picking the first unit conversion factor as the primary
one. The needs went away during implementation.

An alphabetical sort wouldn't let you query for [[quality:=>2 (medium)]].

I think it should. If it does not work this way, I can fix this without much
work. As long as alphabetical order is OK this should be the expected behaviour.
The problem is just to attach additional ordering information to data values
(which currently are just values, API-wise). The API-bottelneck is: when reading
special properties from the store, how do I get the order (in addition to the
values).

Your solution was to store all possible values as an ordered, comma-seperated
list as one entry. But this also has some drawbacks (e.g. the combined length of
all values is restricted). Maybe we could use some hack to store value AND
sortkey in one field (e.g. using syntax "2::Medium" where the value is "Medium"
and the key is "2"). I suppose I could live with that, though some special
processing will be needed as part of the Factbox and when reading possible
values in SMWDatatype.

Another question is: if the order emerges implicitly from the input order of
facts, will the users be confused by this order? Maybe they actually expect
alphabetical order as a default.

alan.trick wrote:

My personally opinion is that in many cases were order could be significant,
it's not alphabetical (i.e. High, Normal, Low). In the cases where it is
alphabetical, they could be placed in alphabetical order manually, or there
could be another data type. Ordering it alphabetically would restrict the
possibilities. Sticking numerical indexes in front works, but it's ugly and adds
useless junk.

That said, I think either way is better than the current method (or lack of).
Any clue as to when this is getting worked on. I don't know too much about about
SMW, but I might try checking out the svn code and working on it myself. It
would help if I could get some guidance though, is there an IRC channel for SMW?

I tried using Ittay's code, and I got part of it working (there was some old API
stuff in there), but it wouldn't insert the values into the smw_attributes table
(although they displayed properly on the page).

There is currently no more Type:Enumeration, but instead "allows value" works for all types (and Enumeration is just a String then). Since types already have their built-in order, this bug is no longer a bug. It is, however, a feature request for having a new type which allows you to define a list of possible answers plus some extra features as wished for in the mentioned special use cases. I imagine that these would be:

• It must be possible to define the order of the possible values.
• It should be possible to define aliases for each value.
• It would be nice to associate an "icon" (image) to each value that can be used e.g. in query generated tables.

This might rather be a new kind of simple custom datatype definition, than a set of special properties for some property. We will keep this in mind.

@mkroetzsch, this is one of the oldest tasks assigned to someone. Are you planning to work on it, and is its current priority correct?

No, I don't think I will work on this anytime soon. Thanks for cleaning up :-)

As a workaround for people who need this, I would suggest the use of type wikipage (not string), so that you have a page for "High", "Normal" and "Low" (maybe you want to call it "High pressure" or something like this to be more specific). Then you can define a MediaWiki sortkey for these pages to control ordering in query results.

Ok, assignee and priority reset accordingly.

In T11750#1039569, @mkroetzsch wrote:

No, I don't think I will work on this anytime soon. Thanks for cleaning up :-)

You can heal cleaning up too. :) Currently you have 68 tasks assigned to you, the majority of them with "Normal" priority, which looks unrealistic. Our recommendation is that you should have a task assigned to yourself only when you are prepared to work on it.