W3C home > Mailing lists > Public > public-ddwg@w3.org > December 2007

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

From: Jo Rabin <jrabin@mtld.mobi>
Date: Tue, 11 Dec 2007 17:24:59 -0000
Message-ID: <C8FFD98530207F40BD8D2CAD608B50B498ACAE@mtldsvr01.DotMobi.local>
To: "Rhys Lewis" <rhys@volantis.com>, "Rotan Hanrahan" <rotan.hanrahan@mobileaware.com>, <public-ddwg@w3.org>

Rhys

Since we really only need pixels, and then again, we all agreed that pixels isn't really a unit anyway, I guess that would work. I'm not sure we need normative conversion factors, but if we do it would be worth considering them now I think.

Jo

> -----Original Message-----
> From: Rhys Lewis [mailto:rhys@volantis.com]
> Sent: 11 December 2007 14:05
> To: Jo Rabin; 'Rotan Hanrahan'; public-ddwg@w3.org
> Subject: RE: [API] Resuming API Work : DDRPropertyValue (including
> enumerations)
> 
> Hello Jo,
> 
> The ontology currently has:
> 
> absolute physical lenth: cm, mm, pc, pt, m, ft, in
> electric charge: C, mAh
> 
> From your note, it seems as though that is more than enough for
> publication of the FPWD of the vocabulary, so we don't need to hold up
> publication to get another revision of the ontology.
> 
> It seems as though it would be ok for UWA to add the rest of the CSS set
> of units in a revision of the ontology after the FPWD of the ontology.
> 
> Does that sound right?
> 
> 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 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 17:25:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:00:15 UTC