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 Friday, 26 October 2007 08:53:12 UTC