Last modified: 2012-11-07 16:16:48 UTC
Semantic MediaWiki manual describes a way to declare "ordered" properties: http://semantic-mediawiki.org/wiki/Property:Allows_value#Ordered_properties But this does not work. The property definition page seems good: Property has type [[Has type::Number]]. Allowed values: * [[Allows value::1 - Small]] * [[Allows value::2 - Medium]] * [[Allows value::2 - Big]] But setting property value: [[Ordered::1 - Small]] Gives result: 1 - Small(!) Where (!) is an yellow icon with exclamation sign, clicking on the icon opens a bubble with warning ""-Small" is not declared as a valid unit of measurement for this property." See live example at: http://scratchpad.referata.com/wiki/Property:Ordered http://scratchpad.referata.com/wiki/TestOrdered Scratchpad runs Semantic MediaWiki (Version 1.6.3 alpha) (r98796).
There is a typo in the example: The third allowed value should be "3 - Big", but it does not matter, the problem is reproducible with both 2 and 3.
It seems it is a recent regression, because it worked in SMW 1.6 alpha (sorry do not know SVN revision number).
Hi guys, please respond whether it is a bug in code or in documentation. If it is a bug in code, by fixing return statement in `SMW_DV_Number.php': > protected function convertToMainUnit( $number, $unit ) { > $this->m_dataitem = new SMWDINumber( $number ); > $this->m_unitin = ''; > return ( $unit === '' ); > } to > return ( preg_match( '/^(-$)/', $unit ) ); you will let `Number' ignore pseudo-units starting with dash, as described in the help: > SMW's number datatype ignores the "- description" after the number. This gives > the set of properties a numerical order and lets you make two values > equivalent. If it is a bug in documentation, page http://semantic-mediawiki.org/wiki/Property:Allows_value should be updated.
Yaron, are you familiar w/ this feature?
Ping.
Oh, hi - sorry, I have no idea.
Hm, same here with SMW 1.7alpha. Unfortunately the bugfix in comment 3 does not help for SMW 1.7, because the mentioned function is different. Support would be great - thanks a lot.
> Oh, hi - sorry, I have no idea. Guys please decide. I want either 1. Get a bug in SMW fixed and use the feature at my site, or 2. Get a bug in documentation fixed and think how to avoid using it.
There has definitely been a change in behaviour of the software. Before I start adjusting documentation to fit the behaviour identified with a bug report I would like to know if this change reflects the intended behaviour. I personally have the feeling that this is a valid bug that should be fixed.
The documentation should be updated to remove this tip. This was never meant to work like this. What happened in earlier versions is that SMW would treat values like "1 - Small" to be the number "1" with an unknown unit of measurement "- Small". This no longer works since SMW does not support undeclared units of measurement any more, and since Number is not supporting units anyway. However, even in past versions it should not have worked: comparing 1 "- Small" with "2 - Medium" is like comparing 3 apples with 2 oranges. This was just not checked properly (there used to be a todo about this in the code). Long story short: there was never any support for this, and it should not be documented. We need to rethink the Allows Value support a sometime. I am sure that some better things could be done there, but the current system really just supports fixed values without any ordering other than the one that it would have naturally based on the property type.
Thank you for your insight on this. This might have worked up to SMW 1.5.6 though it would have indeed been a bit hackish. I will rectify the documentation accordingly. Thus closing this as RESOLVED "WONTFIX".
Looking at the old documentation, the advice given for Strings is still correct. It just won't work for numbers. So part of this tip works. But there is no way to have two different Allows value for String be "aliases" for the same value. If you want aliases etc., you need to use a template for entering data.
