Actually, Eberhard brings up a good point. I thought about it more on the way home tonite and I think we are going down a slippery slope by pseudo combining device and OS detection.
So currently, a user agent tells us 3 key things: -device type -OS -browser examples: desktop, ubuntu, chrome desktop, macintosh, safari galaxy 4, android, firefox mobile So those attributes are all technically independent. However, for phones, the OS is an attribute of the device which is probably why we are expecting OS and device to be hand in hand. This is not true, its not true for desktops, and as time goes on, we may see devices running different OSes... maybe... So a desktop is not a device. But we can infer it using the patterns. Direct detection includes detecting the OS (windows nt, macintosh, ubuntu) which tells us its a desktop or just looking for generic desktop browser patterns and the lack of a device pattern. This is why its possible to combine device and OS classification (and browser classification). But I dont think its a good idea. Example, is detecting a device as a genericDesktop correct or incorrect? What value does an appleDesktop have over a genericDesktop? We should be detecting the device type and the OS independently. That means we have a desktop running Macintosh (which is developed by Apple) or we have a desktop running windows, or we have a desktop and its running an unknown OS. Once we breakout OS into its own classification, then appleDesktop (or windowsDesktop) becomes redundant and possibly misleading because our OS attributes are in both the device and OS. I think this sums up Eberhard's point :) Secondly, the patterns are different for both of these classifications. So while its possible to combine the 2 for desktops and most phones, these pattern indexes are better kept separate. This will keep the concerns seperate and allow both patterns to be more direct in "finding their target". Another example of this is classifying a device as genericAndroid... maybe its better to say its an unknown device running the android OS. But here an android OS tells us a lot about the device in a generic way, so its kind of a gray area. Food for thought :) ________________________________ From: Werner Keil <[email protected]> To: "[email protected]" <[email protected]> Sent: Thursday, July 31, 2014 5:14 PM Subject: Re: generic desktops, crawler, and generic android Aspect is not new or unique to OpenDDR but defined by W3C DDR, see: http://www.maddr.org/ddrsimpleapi An aspect allows to group certain properties together, but their semantic meaning. So "vendor" in the Device aspect is just the same as "vendor" in the OS aspect, which is why additional values like "osvendor" or "os_vendor" (that is just a different way of calling it in non-core vocabularies) can be necessary. "Microsoft" works as "osvendor" but especially for a desktop computer the "vendor" should be blank unless you want to specify particular PCs by vendors like "Lenovo", "Acer" or "Dell" Werner On Thu, Jul 31, 2014 at 10:39 PM, eberhard speer jr. <[email protected]> wrote: -----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Color me confused, but wasn't there such a thing as 'Aspect' in the >various standards ? >To whit, the W3C DDR Aspects : Device, Browser, OS. > >So Aspect qualifies Property, as in : Device Vendor, Browser Vendor >and OS vendor... > >If that's the case "os_vendor" is a travesty at best. > >esjr > > > > >On 31/07/2014 23:22, Werner Keil wrote: >> If we want to properly use a a value like "Microsoft", then adding >> "osvendor" instead of "vendor" for that could be a first step. If >> streamlining with OMA or similar standards is in the interest of >> downstream projects, that would be the next step. Either for a >> pending "1.0.1" update of the data artifacts in the near future or >> for one beyond. >> >> Werner >> >> On Thu, Jul 31, 2014 at 9:50 PM, eberhard speer jr. >> <[email protected]> wrote: >> > >> About the 'default', to be clear : >> >> I am referring to any value that is empty, '-', 0 [meaning no >> value] and any property/value that represents a 'default' value. >> Not only the properties that are 'meaningless' like nokia_version >> for a desktop. >> >> Adding these generic 'defaults' may look impressive but the data >> is meaningless fluff. If the value for property xyz is not present, >> not known or is some known default [you can spot them], it should >> not be included in the response. >> >> That's an 'honest' response, in that the end-user now knows that >> any property not present can default to something meaningful in >> their current context, instead of having them 'run' with nonsense >> 'default' data. >> >> That's an honest and much shorter response : all signal. >> >> esjr >>> >> > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v2.0.22 (MingW32) >Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > >iQEcBAEBAgAGBQJT2ql+AAoJEOxywXcFLKYcOfYIAKqkGN2kvF4kx+zMKhvbslvu >errQq9qqoxX1cXcpIvPwokv8NqDVS9iL4ufFzN25SnLflR6DuZHtlfwPp4bO2Krg >8JfD1kFS6jr3yAizxdwr2jWrN+SVaEpFOZalpTuECE+YSQErmO4WTJ3ieBq4hrEA >AhyAkQmNskObvsk564kqLatGo4Tw8FZhi4loLlGKpSk/XnnEPHNRceVzhtIoX8sQ >xWMyDk9p/X7/msIQZGrRLk16d2Yc8oraMbUrZqZxUGx9D2sGoi3Rt5WFG2UBL2M4 >EdnQAGoMJ6aUIKBDejD3B9YALwUaLudGL/CLuW25wTIgkkwQZjGVhVsb/Qz4Twc= >=eEaS >-----END PGP SIGNATURE----- >
