RE: [API] Resuming API Work : DDRPropertyValue (including enumerations)

> And hopefully the same values will be in the ontology.

Actually, I think it should be the other way around. We first ensure the units we want are in the ontology, then we just reference them (or their abbreviations). Anything missing from the ontology needs to be added. By making the ontology the central definition location, we solve all current and future needs regarding the identification of units. Certainly, if people wish to use abbreviations instead of the full URIs, then fair enough. You gain nothing in terms of performance (except for a few less bytes of storage). You might gain a bit from readability if the programmer is seeing "mm" instead of a longer URI, but then (as Jo pointed out during the F2F), the better practice would be for the API implementation to define constants, like MM (which itself could be either the abbreviation string or the URI string). So I don't really buy the "easier to understand" argument.

Certainly, however, we can do as Jo suggests and start with all the CSS units. If that's what we decide, then we require of UWA to put all these into the ontology. We can decide later if the strings in our API will be the abbreviations (from the ontology) or the actual URIs (of the place in the ontology where you can find the units definition, including abbreviations). If the UWA ontology gives a guarantee that all abbreviations are unique, then it doesn't matter which we use in the API.

---Rotan.

-----Original Message-----
From: Jo Rabin [mailto:jrabin@mtld.mobi] 
Sent: 11 December 2007 13:04
To: Rotan Hanrahan; public-ddwg@w3.org
Subject: RE: [API] Resuming API Work : DDRPropertyValue (including enumerations)

I think that simply put we don't need units for the Core Vocabulary since the properties that are in it are counts (of pixels) strings or enumerations.

For the sake of extensibility I'd like to see us adopt the CSS units - which I think (CSS2) are:

{num}em			{return EMS;}
{num}ex			{return EXS;}
{num}px			{return LENGTH;}
{num}cm			{return LENGTH;}
{num}mm			{return LENGTH;}
{num}in			{return LENGTH;}
{num}pt			{return LENGTH;}
{num}pc			{return LENGTH;}
{num}deg		{return ANGLE;}
{num}rad		{return ANGLE;}
{num}grad		{return ANGLE;}
{num}ms			{return TIME;}
{num}s			{return TIME;}
{num}Hz			{return FREQ;}
{num}kHz		{return FREQ;}
{num}{ident}		{return DIMEN;}
{num}%			{return PERCENTAGE;}
{num}			{return NUMBER;}

I'd like us to keep this as simple as possible and allow people to use other units for properties but leave the standard set as this, with precisely the syntax here. Anyone who wants to render mm as millimetre or whatever should be free to do this, but we shouldn't standardise it or provide facilities in the api to do so.

The conversion factors can be defined I think for these units, where relevant. And hopefully the same values will be in the ontology.

Jo



> -----Original Message-----
> From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] On
> Behalf Of Rotan Hanrahan
> Sent: 11 December 2007 12:40
> To: public-ddwg@w3.org
> Subject: RE: [API] Resuming API Work : DDRPropertyValue (including
> enumerations)
> 
> 
> I'm sure we could pull together a set of units, based on the first draft
> of the vocabulary that we intend to publish in a few days.
> 
> Using URIs to identify units is a nice interoperable and unambiguous way
> to proceed, though at the back of my mind I have some concerns about
> implementation efficiency. However, URIs are opaque strings, so all we
> will be doing is string comparison (for equality testing), which is very
> efficient if you insist on there only being one instance of each URI
> string. The equality test is then merely a memory address comparison.
> Ensuring there are only single instances of the URI strings can be
> enforced via factory approaches.
> 
> As for conversions between units, this is quite a complex issue. As Rhys
> knows, I've raised this many times in the past in the Device Independence
> WG. I'll review my notes on the issue and have something more detailed to
> say on the matter in a day or so.
> 
> ---Rotan.
> 
> -----Original Message-----
> From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] On
> Behalf Of Rhys Lewis
> Sent: 11 December 2007 11:55
> To: 'Jo Rabin'; public-ddwg@w3.org
> Subject: RE: [API] Resuming API Work : DDRPropertyValue (including
> enumerations)
> 
> 
> Hello Jo,
> 
> I'm sure that I don't have all the CSS ones in the ontology. However,
> adding whatever you'd like to see there is pretty straightforward. Some of
> the ones that are there are based on CSS.
> 
> To satisfy the good (and I'm hoping less mobility-challenged) Dr.
> Hanrahan, it would be nice to get agreement on conversion factors too,
> where appropriate. I'll confess to having used the Google calculator up
> until now.
> 
> Is there a list of units that DD needs anywhere yet?
> 
> Best wishes
> Rhys
> 
> > -----Original Message-----
> > From: public-ddwg-request@w3.org
> > [mailto:public-ddwg-request@w3.org] On Behalf Of Jo Rabin
> > Sent: 11 December 2007 11:40
> > To: public-ddwg@w3.org
> > Subject: RE: [API] Resuming API Work : DDRPropertyValue
> > (including enumerations)
> >
> >
> > CSS defines a number of units, are they sufficient for our
> > purposes, and are they included in the ontology?
> >
> > Jo
> >
> >
> > > -----Original Message-----
> > > From: public-ddwg-request@w3.org
> > [mailto:public-ddwg-request@w3.org]
> > > On Behalf Of Rhys Lewis
> > > Sent: 11 December 2007 11:36
> > > To: 'Rotan Hanrahan'; 'José Manuel Cantera Fonseca';
> > > public-ddwg@w3.org
> > > Subject: RE: [API] Resuming API Work : DDRPropertyValue (including
> > > enumerations)
> > >
> > >
> > > Hello Rotan,
> > >
> > > The ontology currently captures an abbreviation for each
> > unit and a name.
> > > Both are effectively US English currently.
> > >
> > > Internationalization of those properties would be
> > accomodated in the
> > > ontology. I think your suggestion of delegating this kind
> > of issue to
> > > the ontology is a really good one. It illustrates one of
> > the reasons
> > > for creating the ontology.
> > >
> > > > -----Original Message-----
> > > > From: public-ddwg-request@w3.org
> > > > [mailto:public-ddwg-request@w3.org] On Behalf Of Rotan Hanrahan
> > > > Sent: 11 December 2007 11:16
> > > > To: José Manuel Cantera Fonseca; public-ddwg@w3.org
> > > > Subject: RE: [API] Resuming API Work : DDRPropertyValue
> > (including
> > > > enumerations)
> > > >
> > > >
> > > > Regarding [1], I notice the getUnits() method returns a
> > String. This
> > > > means that all units will have to have a normative textual
> > > > identifier. This could be a URI or an agreed short name.
> > If we use a
> > > > short name, we could run into trouble because some common
> > units have
> > > > variations in their names. Consider the millimetre, which has an
> > > > American spelling of millimeter, and a common abbreviation of mm.
> > > > Then there's pixel, which has the same short name in all
> > > > English-speaking regions but has a variety of
> > abbreviations like p,
> > > > px, pix. Even if we choose to use URIs, not all units
> > have an agreed
> > > > URI. Perhaps these are things that the UWA ontology
> > should capture,
> > > > and the DD units can simply point to the right place in the
> > > > ontology?
> > > >
> > > > ---Rotan
> > > >
> > > > -----Original Message-----
> > > > From: public-ddwg-request@w3.org
> > > > [mailto:public-ddwg-request@w3.org] On Behalf Of José
> > Manuel Cantera
> > > > Fonseca
> > > > Sent: 10 December 2007 13:39
> > > > To: public-ddwg@w3.org
> > > > Subject: [API] Resuming API Work : DDRPropertyValue (including
> > > > enumerations)
> > > >
> > > >
> > > > Hi,
> > > >
> > > > The discussion now need to turn on the DDRPropertyValue
> > object and
> > > > its methods.
> > > >
> > > > Please take a look at the current version of this class
> > in [1]. The
> > > > DDRPropertyValue class is a subclass of DDRValue [2]
> > which actually
> > > > has all the methods needed to retrieve a property value. It is
> > > > important to note that a DDRPropertyValue references the aspect /
> > > > component to which the property value applies, which is useful in
> > > > those cases where multiple DDRPropertyValues are obtained
> > > >
> > > > Also it is important to have a look at the way that enumerated
> > > > values are treated and how this would be used to query
> > about thinks
> > > > like image
> > > > formats:
> > > >
> > > > DDRPropertyValue value =
> > > > ddr.getPropertyValue("supported_image_formats",key);
> > > >
> > > > DDREnumeration enumeration = value.getEnumeration();
> > > >
> > > > if(enumeration.contains("cv:gif")) {
> > > >     System.out.println("GIF format is supported for images"); }
> > > >
> > > >
> > > > Please have a look at this proposal and send comments, it is very
> > > > important to make progress in the API
> > > >
> > > > Best Regards
> > > >
> > > > [1]
> > > > http://www.w3.org/2005/MWI/DDWG/drafts/api/java/DDR-API-Minima
> > > l/doc/org/w3c/ddr/DDRPropertyValue.html
> > > > [2]
> > > > http://www.w3.org/2005/MWI/DDWG/drafts/api/java/DDR-API-Minima
> > > > l/doc/org/w3c/ddr/DDRValue.html
> > > >
> > > >
> > > >
> > >
> >
> >
> >
> 
>

Received on Tuesday, 11 December 2007 13:17:55 UTC