RE: Core Vocabulary round 2 reminder

Hello Rotan, 

Right now, the ontology sees 'vendor' and 'model' as a property of a
device. Based on Bryan's description of the term 'vendor' as the OEM, that
suggests that there won't be any entries in the ontology based on 'brand'.

In the ontology, we could directly model the relationships between
devices, that differ only in brand. I haven't thought this through
properly, but it seems as though an approach could be to relate one device
entry to another, where they are the same. OWL even has primitives that
reflect this relationship. There is an open question about the scope of
the things that are the same (Device, DeviceHardware, DeliveryContext...).
Pragmatically, that probably depends on how the 'things that are the same'
are identified in practice by the software that cares about this.

Best wishes
Rhys

  

> -----Original Message-----
> From: public-ddwg-request@w3.org 
> [mailto:public-ddwg-request@w3.org] On Behalf Of Rotan Hanrahan
> Sent: 26 October 2007 09:53
> To: Sullivan, Bryan; public-ddwg@w3.org
> Subject: RE: Core Vocabulary round 2 reminder
> 
> 
> 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 Monday, 29 October 2007 07:30:05 UTC