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

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

From: Rhys Lewis <rhys@volantis.com>
Date: Tue, 11 Dec 2007 06:56:49 -0700 (MST)
To: "'Rotan Hanrahan'" <rotan.hanrahan@mobileaware.com>, <public-ddwg@w3.org>
Message-ID: <004301c83bfe$31ef7dd0$8c1e140a@volantisuk>

Hello everyone,

Since the ontology and, AFAICT, CSS use generally accepted abbreviations,
that seems fine to me. I'd be happy to see the API use such abbreviations.


I think that Rotan is correct in saying that the abbreviations and the
conversion factors should be in the ontology. The vocabulary then just has
to reference the ontology as the source of its values.

One good thing about ontologies is that they do provide URIs for
everything. So, if in the fullness of time, DD decided that it wished to
have URIs for its units, the URIs of the classes for units in the UWA
ontology could fulfil that role. That's part of the point of OWL, really.

By the way, in DIWG we did look for ontologies of units that we could use.
It was a little while ago, but we did not find anything that seemed truly
appropriate. However, if such definitions turned up in an appropriate
form, in future, the UWA ontology could be updated to add references. The
classes that represent units could be updated to refer to the new
definitions. The DD vocabulary would get any additional definitional
material for free. It wouldn't affect the APIs or anything else, of
course. That's another neat thing about OWL.

> -----Original Message-----
> From: public-ddwg-request@w3.org
> [mailto:public-ddwg-request@w3.org] On Behalf Of Rotan Hanrahan
> Sent: 11 December 2007 13:18
> To: public-ddwg@w3.org
> Subject: 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:57:06 UTC

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