From: Markus K. <ma...@se...> - 2011-03-16 08:18:39
|
= Announcement: Changes in unit handling = SMW supports units of measurement for its numerical datatypes. This feature will change in the next major version of SMW (and in SVN before that). Read on if you use units in your wiki. == Current behaviour == For all properties of numerical datatype, SMW considers anything that follows the actual number to be the name of a unit of measurement. This unit *is part of the value* i.e. all values are really pairs of a number and a unit (where the latter can be empty). SMW further supports custom conversion factors that allow linear conversions between input units. This also helps to standardise unit names. == Future behaviour == In the future, SMW will no longer silently accept every text that follows a number as a unit. In many cases, such texts would be input errors anyway. Instead, SMW will only accept units for which some custom conversion has been declared (this can always be done, even if they are the only unit). As a result, units turn into a feature for input pre-processing, and are no longer part of the actual value that is stored. SMW will treat all numerical values as plain numbers, not as pairs of numbers and units. The unit is added visually when displaying this number. == Consequences and required updates == The change will only affect you if (a) you use unit strings in your wiki, but (b) have not declared the units on a custom page. In most cases, this will really be input errors that are simply not noticed due to SMW's silence. If you really want such units to be accepted, you need to declare them on an according type page. For declared units and for numbers without units, no observable change will happen. Advantages: The internal handling of numbers becomes much easier. One column in the respective database table can go away, reducing the memory requirements of query answering. Queries and RDF export become simpler. Disadvantages: You cannot use multiple units with one property without having a linear conversion between them. Rare cases may require a property to be split in two (one for each of the incompatible units) or replaced by a Type:Record based property that encodes a pair of a number and a (unit) string. Moreover, changing the unit declarations will affect the interpretation of data that is stored in the database, but note that such changes lead to update jobs that will repair the input over time. |
From: Markus K. <ma...@se...> - 2011-03-25 14:19:30
|
The change announced below has now been implemented in SVN, along with some minor changes in the API for SMWNumberValue and its subclasses (SMWLinearValue and SMWTemeraturValue). Developers who use objects of these types internally (e.g. to parse numerical user input) might need to make some small changes. In particular, there is now a static method to parse numbers directly, without requiring any datavalue object to be created first. Since the datavalue got more picky about accepting junk after the number ("unit strings") it might actually be necessary to use the parsing method directly instead of going via a DV object. As the next change, the "unit" column will be dropped from all DB tables. This should not affect anybody, but I better mention it. Cheers, Markus On 16/03/11 08:18, Markus Krötzsch wrote: > = Announcement: Changes in unit handling = > > SMW supports units of measurement for its numerical datatypes. This > feature will change in the next major version of SMW (and in SVN before > that). Read on if you use units in your wiki. > > == Current behaviour == > > For all properties of numerical datatype, SMW considers anything that > follows the actual number to be the name of a unit of measurement. This > unit *is part of the value* i.e. all values are really pairs of a number > and a unit (where the latter can be empty). > > SMW further supports custom conversion factors that allow linear > conversions between input units. This also helps to standardise unit names. > > == Future behaviour == > > In the future, SMW will no longer silently accept every text that > follows a number as a unit. In many cases, such texts would be input > errors anyway. Instead, SMW will only accept units for which some custom > conversion has been declared (this can always be done, even if they are > the only unit). > > As a result, units turn into a feature for input pre-processing, and are > no longer part of the actual value that is stored. SMW will treat all > numerical values as plain numbers, not as pairs of numbers and units. > The unit is added visually when displaying this number. > > == Consequences and required updates == > > The change will only affect you if (a) you use unit strings in your > wiki, but (b) have not declared the units on a custom page. In most > cases, this will really be input errors that are simply not noticed due > to SMW's silence. If you really want such units to be accepted, you need > to declare them on an according type page. For declared units and for > numbers without units, no observable change will happen. > > Advantages: The internal handling of numbers becomes much easier. One > column in the respective database table can go away, reducing the memory > requirements of query answering. Queries and RDF export become simpler. > > Disadvantages: You cannot use multiple units with one property without > having a linear conversion between them. Rare cases may require a > property to be split in two (one for each of the incompatible units) or > replaced by a Type:Record based property that encodes a pair of a number > and a (unit) string. Moreover, changing the unit declarations will > affect the interpretation of data that is stored in the database, but > note that such changes lead to update jobs that will repair the input > over time. > > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > |