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

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 12:50:08 UTC