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

RE: Core Vocabulary round 2 reminder

From: Rhys Lewis <rhys@volantis.com>
Date: Thu, 25 Oct 2007 03:04:27 -0600 (MDT)
To: "'Jo Rabin'" <jrabin@mtld.mobi>, <public-ddwg@w3.org>
Message-ID: <00a501c816e6$7b6ded30$0801a8c0@volantisuk>

Hi Jo, 

Good point. Actually, that might be why OMA picked vendor rather than
manufacturer as the term for UAProf.

I guess the question is whether or not every aspect of the delivery
context is identical, apart from the name. If there is any other
variation, then it's not the same delivery context, and the problem goes
away. DDR needs to have separate entries for both.

However, if the delivery context is identical, it suggests that the actual
name/model of the device cannot be determined uniquely from, for example,
the HTTP headers, so the value of the property is questionable anyway.
This is certainly the case for Windows Mobile devices. 

Maybe we can avoid the need to worry about synonyms by having a way to
signal that the value of a property cannot be uniquely determined?
Alternatively, a 'generic' value could be returned.

Then again, this doesn't solve the issue of queries to the DDR at design
time to retrieve properies for a particular device by name. In that use
case, it would be much better for a user to be able to ask for the
properties of a device by its usual known name, rather than having to know
the name of the OEM manufacturer who actually put it together.

Complicated isnt't it?

Cheers
Rhys

> -----Original Message-----
> From: public-ddwg-request@w3.org 
> [mailto:public-ddwg-request@w3.org] On Behalf Of Jo Rabin
> Sent: 25 October 2007 09:16
> To: public-ddwg@w3.org
> Subject: RE: Core Vocabulary round 2 reminder
> 
> 
> 
> Pre-Preface: Dragging this onto the public list ...
> 
> Preface: I don't feel strongly about this but ...
> 
> It's been observed that the name of the device is 
> problematic, because it can be sold with different names in 
> different circumstances. No doubt outside the core vocabulary 
> there is scope for synonym support. However, inside the core 
> vocabulary we probably want to provide the opportunity to be 
> as precise as is possible in the circumstances. To that end, 
> I'd suggest that neither "Brand" nor "Vendor" really gets you 
> there, whereas "Maker" might get closer. This is especially 
> true of OEM phones however in simple cases it's a distinction 
> that may be worth making, for example, the vendor of my phone 
> is Vodafone. Its maker is Nokia. 
> 
> Of course it all depends what you mean by Vendor and Brand, 
> but does Maker allow for less ambiguity?
> 
> Jo
> 
> Incidentally, while on nomenclature and apologies if this has 
> been covered on this list before but ... I'm curious as to 
> why the ontology uses operatingSystemVendor and deviceVendor 
> when the meaning of "Vendor"
> is the same in both cases and the usage is qualified by the 
> path in the ontology. These names make perfect sense for 
> disambiguation when used in the absence of the path, but when 
> used with the path isn't a vendor a "vendor"?
> 
> > -----Original Message-----
> > From: member-ddwg-request@w3.org [mailto:member-ddwg-request@w3.org]
> On
> > Behalf Of Rhys Lewis
> > Sent: 25 October 2007 08:41
> > To: 'Rotan Hanrahan'; 'DDWG'
> > Subject: RE: Core Vocabulary round 2 reminder
> > 
> > 
> > I'd just like to note that in the ontology[1], the device vendor and
> model
> > appear as
> > 
> > /device/deviceName/deviceVendor and /device/deviceName/deviceModel
> > 
> > It's probably more structure than DD wants, but I thought 
> I'd point it
> out
> > anyway. Similar structures are used for the vendors of web browsers
> and
> > operating systems, for example
> > 
> >
> /device/deviceSoftware/webBrowserSupport/activeWebBrowser/webB
> rowserVend
> or
> > and
> >
> /device/deviceSoftware/operatingSystemSupport/activeOperatingS
> ystem/oper
> at
> > ingSystemVendor
> > 
> > One thing worth noting is that in general lots of vendors may be
> involved
> > in the components of a device, and it might be worth considering 
> > deviceVendor and deviceModel as the names used in the DDR 
> vocabulary, 
> > particularly as I believe that the intent is to have a 
> relatively flat 
> > name space.
> > 
> > Best wishes
> > Rhys
> > 
> > 
> > [1]
> >
> http://www.w3.org/2007/uwa/editors-drafts/DeliveryContextOntol
> ogy/2007-1
> 0-
> > 31/DCOntology.html
> > 
> > 
> > > -----Original Message-----
> > > From: member-ddwg-request@w3.org
> > > [mailto:member-ddwg-request@w3.org] On Behalf Of Rotan Hanrahan
> > > Sent: 24 October 2007 17:19
> > > To: DDWG
> > > Subject: RE: Core Vocabulary round 2 reminder
> > >
> > >
> > > I agree with Andrea's list, though I have a feeling that if the 
> > > Structures work progresses properly then we might have a 
> better way 
> > > to deal with Brand and Model using Structures rather than 
> vocabulary 
> > > properties. But anyway, I'm happy enough to go with these 
> during the 
> > > moratorium period, and see what we learn about them as we work on 
> > > the API.
> > >
> > > ---Rotan.
> > >
> > > -----Original Message-----
> > > From: member-ddwg-request@w3.org
> > > [mailto:member-ddwg-request@w3.org] On Behalf Of Andrea Trasatti
> > > Sent: 24 October 2007 17:03
> > > To: DDWG
> > > Subject: Core Vocabulary round 2 reminder
> > >
> > >
> > > Next Monday (Nov, 29) we're voting the last properties 
> that will fit 
> > > the Core Vocabulary.
> > >
> > > I'm taking up Rotan's "form" to vote. Here are the 
> properties left:
> > >
> > > CORE	Form Text Input Mode
> > > CORE	Cookie
> > > CORE	Has a Pointing Device
> > > CORE	Device Brand
> > > CORE	Device Model
> > > NOT CORE	Shows page title by default
> > > NOT CORE	Best Background Colors
> > > NOT CORE	Text Rows on Screen
> > > NOT CORE	Maximum Image Height on Screen
> > > NOT CORE	Maximum Image Width on Screen
> > > NOT CORE	File Upload
> > > NOT CORE	Preferred Image Format
> > > NOT CORE	Preferred Mark-up
> > > NOT CORE	Font Faces
> > > NOT CORE	Preferred layout method
> > > NOT CORE	Preferred font
> > > NOT CORE	Tel URI Schema
> > > NOT CORE	SMS URI Schema
> > > NOT CORE	Marquee
> > > NOT CORE	Maximum Download Size
> > > NOT CORE	CSS White Space nowrap
> > > NOT CORE	Select Control Rendering
> > > NOT CORE	Page markup memory limit
> > > NOT CORE	Embedded media memory limit
> > > NOT CORE	Media download memory limit
> > >
> > >
> > > I haven't worked on property names to make them 
> consistent with what 
> > > we already have, if you have suggestions, please make on step 
> > > forward otherwise you'll be bound to my decision (and the names 
> > > could be in Italian).
> > >
> > > - Andrea
> > >
> > >
> > >
> > >
> > 
> 
> 
> 
Received on Thursday, 25 October 2007 09:04:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 6 December 2009 12:13:51 GMT