- From: Andrea Trasatti <atrasatti@mtld.mobi>
- Date: Fri, 26 Oct 2007 16:26:55 +0100
- To: public-ddwg@w3.org
Right now my position is that we should get the "Vendor" and "Model" in the Core Vocabulary and open an issue for the Structures team and ask them to have an explanation in their document as to how to address devices that might look similar or have similar functionalities, but are, from a marketing point of view different devices. I think we have already agreed that these are important properties, anyway. - Andrea Il giorno 26/ott/07, alle ore 09:52, Rotan Hanrahan ha scritto: > > Taking my Chair's hat off for this message... > > This is one of the dilemmas that MobileAware faced in developing > its own > proprietary repository. Multiple "apparent" devices were in reality > the > same device with different branding. We could have demanded that the > repository has a separate entry for each of these, with a consequent > growth in the total amount of data. Instead, we opted to allow the > repository be compact while still covering a huge number of > devices. Two > or more devices that are the same in every regard except for branding > can match to the same set of data, not necessarily to multiple > independent sets. While branding can (sometimes) be detected (e.g. via > customisations of the UA header), the detection is done separately. > There is no loss of functionality, storage is efficient. And > coverage is > as high as an approach where you count every branded device > separately. > > Obviously, if a branded device is upgraded so that it acquires a new > feature - no matter how subtle - then a separate entry is required > because now we are genuinely dealing with a different device. > > Having thought more about this and how it related to the DDWG work, > I am > now inclined to agree that we need some vocabulary for branding > purposes. This is because the concept will be needed, even if we agree > to use a Structures approach to manage it. > > My concern is really ontological in nature. What I am concerned > about is > that the ontology would bind the branding information to an > instance of > a device description, when I believe that the binding should have more > flexibility (e.g. using a Structures approach). This reflects the > reality in the world, where the binding between names and physical > devices ebbs and flows at the whim of marketing people. > > I think this is a topic we could discuss when we have the joint > meeting > with the UWA in November. > > ---Rotan. > > -----Original Message----- > From: public-ddwg-request@w3.org [mailto:public-ddwg- > request@w3.org] On > Behalf Of Sullivan, Bryan > Sent: 26 October 2007 05:54 > To: public-ddwg@w3.org > Subject: RE: Core Vocabulary round 2 reminder > > > A note on terminology: For mobile phones, vendor is typically the > maker > (OEM) of a device (e.g. Nokia, Motorola). The Operator or retail > outlet > that sells the device is a reseller. Sometimes phones are branded by > other than the OEM, and are known by the branded name, but nonetheless > they can be viewed as unique devices from a content provider view. > > We have used vendor and model as a prefix to User Agent strings for > years, and it has proven to be a very reliable approach to helping our > content partners ensure that they can deterministically identify the > device in use, at least for the devices we purchase from vendors and > resell, which comply to our user agent header formatting requirements: > "The first white space delimited word must be the product name (vendor > and model) with a slash and mandatory firmware version designator > (e.g. > BrandX-G4000/V3.1.a[Build3] or BrandY75-E/1.1). Other attributes > may be > put as separate words following the product and version." > > The potential for ambibuity and non-compliance always exists. But a > successul/scalable approach (we have launched many dozens of phones > using this approach) is not diminished by exceptions. > > I recommend that the device vendor and model be represented as > distinct > attributes in the vocabulary. > > Best regards, > Bryan Sullivan | AT&T | Service Standards > bryan.sullivan@att.com > -----Original Message----- > From: public-ddwg-request@w3.org [mailto:public-ddwg- > request@w3.org] On > Behalf Of Rotan Hanrahan > Sent: Thursday, October 25, 2007 2:49 AM > To: Rhys Lewis; Jo Rabin; public-ddwg@w3.org > Subject: RE: Core Vocabulary round 2 reminder > > > Thanks Jo and Rhys. I suppose the public forum is more appropriate for > this debate. > > I understand your concern regarding the use of the term "vendor", > and I > have great sympathy with this concern. It is true that the vendor > is not > necessarily the same as the maker/manufacturer, and it is also true > that > in many device detection processes it is impossible to distinguish the > vendor from the maker. > > Because of the complexities of the mapping between a > specific/identifiable context and a marketing identifier (name of > manufacturer, name of brand, name of model, name of purchase plan, > regional variations on all of the above...), it seems even more likely > to be a candidate for a structures extension than a feature of the > core > API/vocabulary. > > If this approach was taken, the design-time solution would incorporate > both the structures API and the DDR core API, backed by a > collection of > marketing identifiers and their mapping (via structures) to unique > entries in the DDR. You would then be able to ask two types of > question: > > - For a given brand/model/vendor/maker, what are the corresponding > device(s) and properties? > > - For a given set of properties, what brands/models/vendors/makers > support those properties? > > The Structures extension was originally envisaged to deal with things > like "definition of PDA", because such definitions are not universally > agreed. A structures approach would permit multiple ways of > categorising > the same data from the DDR. It seems to me that assigning > vendors/makers/etc to devices is an equally grey area, and perhaps > structures might solve the problem without polluting the vocabulary > with > ambiguous properties. > > ---Rotan. > > -----Original Message----- > From: public-ddwg-request@w3.org [mailto:public-ddwg- > request@w3.org] On > Behalf Of Rhys Lewis > Sent: 25 October 2007 10:04 > To: 'Jo Rabin'; public-ddwg@w3.org > Subject: RE: Core Vocabulary round 2 reminder > > > 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 Friday, 26 October 2007 15:27:33 UTC