RE: Default units of a property (mandatory for DDRs)

The example you choose is not right, but the general idea is correct. Let me clarify...

You cannot mix "pixels" and "millimetres", even if we use the word "width" as a measurement. Pixels is a count of how many coloured cells there are in a straight line from one edge to another. As the physical size of an individual pixel is not specified, this count cannot be a measurement of length (distance).

However, we have a habit of only being interested in how many pixels are across the screen, and we call this "width". This is not a correct use of the word "width", because width requires a measurement of length (distance).

So I clarified this a little in my previous explanation by inventing new words for the vocabulary: pixelsAcross and physicalWidth.

The pixelsAcross property can only return a number. If you like, the units can be described as "pixels", but we know that pixels is not really a unit of measure. It is merely the thing that we are counting.

However, physicalWidth is a property that can be measured in units, and there are several well-known units that could apply. For example, mm and cm and m and km and miles and (to keep Jo happy) parsecs.

So I concentrate on the problem for the physicalWidth property, because you cannot understand its numeric value unless you also know the units that the number relates to.

What units should apply? I suggested that perhaps the units that were use originally to measure the property should be recorded in the repository. In that way, I can query for both the units of measure and also the numeric value. By putting the two together, I can better understand what the number means.

Alternatively, we force people to store the values in some default units as specified by the vocabulary or ontology. However, if we do this then (for example) forcing the physicalWidth to be stored in centimetres will be accurate enough as an Integer for the people who make screens for football stadia, but will particularly annoy those who make displays for portable phones. So I think we need to be careful about the idea of a default.

I also pointed out that programmers who write adaptation code for run-time use will probably already know what units matter to them, and it would make things clear if the units were included as parameters. Any translation from the units requested and the units as stored in the repository would be dealt with as a matter of implementation and we don't have to deal with it in the API itself.

I think that including the units as a parameter is a good idea. It removes ambiguity and can produce code that is easier to follow. It also does not need to be prone to error (e.g. if the units are passed as a string and that string doesn't correspond to known units) because the designer of an implementation can move those strings to a pre-defined set of constants, or alternatively we can define a class that captures the idea of units.

Hopefully this clears things up a little more.

---Rotan.

-----Original Message-----
From: jmcf@tid.es [mailto:jmcf@tid.es] 
Sent: 23 November 2007 15:04
To: Rotan Hanrahan
Cc: public-ddwg@w3.org
Subject: Re: Default units of a property (mandatory for DDRs)

Hi,

If I have understood properly you are for having the both methods (with 
units and without units). But the method without units would return, the 
value in the units as-is, i.e. the value in the units that the DDR 
initially stored it

So, for example if the value of the property screenWidth for a device 
was stored initially in pixels, the value returned by the 
widthValue.getInteger() will be returned in pixels.

And if another DDR for the same device, the screenWidth was stored as 
milimeters, a call to widthValue.getInteger() will return the 
screenWidth in milimeters

. Am I right?

Best Regards

 widthPropertyValue.getInteger()



Rotan Hanrahan escribió:
> There are several ways of looking at this.
>
> 1. The vocabulary entry for a property refers to the ontology to define that property. The ontology might be the place to determine the units in which the property would be defined. This would mean that the default for any vocabulary that uses the same ontology would be consistent.
>
> 2. The vocabulary entry for a property could include a reference to the default units for the property. This would mean that the default could be chosen to be most appropriate to the users of the vocabulary.
>
> 3. We could have no default units, and insist that the "get" methods include a units parameter.
>
> Different instances of components could be at different scales (e.g. the physical width of a display could be just a few mm for a portable device, while it could be several metres for a display device as used at a sports ground). The providers of data in these instances would probably prefer to use units that are within the same scale. (I believe we discussed this matter in the early days of the group.) So perhaps the recorded data should also include the units in which it was recorded. Consequently, perhaps there is necessity for a getUnitsInWhichPropertyWasMeasured() method. This could then be the input for a generic getIntegerValueInSpecifiedUnits(u) method, and perhaps a getFloatValueInSpecifiedUnits(u) too.
>
> I'm not so sure that I would like to see a whole collection of getValueAsX() methods, though I can see how one could make a special case for getValueAsInteger(), because this is likely to be the most useful of them all.
>
> So, let's think about how a programmer would view this. Typically, the data from the property would be compared against something. For example, comparing the width in pixels against some threshold to determine if a tabular display is appropriate. In this case the units are implied in the comparison (i.e. "pixels"). Furthermore, the vocabulary should make clear that the pixelsAcross property is actually a count of the pixles (not the millimetres or parsecs or any other unit of length) and one cannot readily convert pixels to a typical length unit because "pixel" is not really a unit if length.
>
> Where an actual convertible unit is involved (e.g. physicalWidth) then once again the programmer is likely to be using the value in a comparison, so will already have some units in mind. It would therefore not be too much to ask that the programmer indicate these units as a parameter.
>
>     // Check if the screen is wide enough for the subtext in the image to be seen.
>     // We believe that a screen wider than 25mm should be wide enough.
>     if (widthPropertyValue.getInteger("mm") > 25) {
>       ...
>     }
>
> That doesn't look too tricky to me. It certainly makes the code easier to read. If I was relying on defaults from the vocabulary/ontology, then the code would not be making the units explicit, so to understand it I would have to also read the vocabulary/ontology. For example, suppose the default was actually cm and not mm? In which of the following sample lines of code would you most easily spot the mistake?:
>
>     // Check if the screen is wide enough for the subtext in the image to be seen.
>     // We believe that a screen wider than 25mm should be wide enough.
>     if (widthPropertyValue.getInteger() > 25) {
>       ...
>     }
>
>     // Check if the screen is wide enough for the subtext in the image to be seen.
>     // We believe that a screen wider than 25mm should be wide enough.
>     if (widthPropertyValue.getInteger("cm") > 25) {
>       ...
>     }
>
> Yes, the second one. Because in the first you are relying on an external definition (outside the code) to determine the units, whereas the error is quite obvious in the second, where you are required to be explicit about the units. In this case, the fact that the programmer used "cm" highlights where the problem occurred.
>
> If I was generating a report, as opposed to using the property data in expressions, I could then dig deeper into the property value. In this case, defaults or stored units would be useful. Here's more sample code:
>
>     // Display the width of the device
>     print("The screen is "
>       + widthPropertyValue.getInteger()
>       + " "
>       + widthPropertyValue.getUnits().getString()
>       + " wide");
>
>
> This is an approach to the PropertyValue interface that I would favour, as it gives sufficient flexibility for the primary use cases, and from a programmer's perspective it looks simple enough to use without making obscure mistakes.
>
> Thoughts anyone?
>
> ---Rotan.
>
>
> -----Original Message-----
> From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] On Behalf Of José Manuel Cantera Fonseca
> Sent: 23 November 2007 10:23
> To: public-ddwg@w3.org
> Subject: Default units of a property (mandatory for DDRs)
>
>
> Hi,
>
> While drafting the DDRPropertyValue methods I have realized that perhaps 
> we need to specifiy clearly in the vocabulary what are the default units 
> of a property. The reason is the following:
>
> We are going to have getValueAsDouble(), getValueAsFloat(), etc. methods 
> that are going to return the value in the default units of ... what?
> a) of the property
> b) or the default (and maybe only) units that a DDR knows for that 
> property?
>
> I think that default units should be bound to the property and not to 
> the value, so I think we need a default unit for each property in a 
> vocab. That will encourage interoperability between DDRs
>
> What others think about this?
>
> Best Regards
>
>
>

Received on Friday, 23 November 2007 15:27:55 UTC