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 Thursday, 25 October 2007 09:49:20 UTC