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

I think that screenWidth and screenHeight same as colorDepth are counts, and hence dimensionless. So at least as far as the core vocabulary is concerned none of the properties has a unit. That being the case I think I'd like to see the "default" unit for a property being a local matter to the DDR that can be recovered through the API. Though, that said, the vocabulary in which the units are expressed itself becomes an issue, which I propose we don't address, and leave as a local matter for the DDR.
 
I note the need in some vocabulary for the physical dimesion of the screen, rather than its pixel count, but think that is a different property to screenWidth.

Jo

> -----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 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:31:32 UTC