Re: Automotive, EXIF, Property-Values

To add a voice to the Bike vs Bicycle debate, I also prefer Bicycle, in
part because it is similar to "MotorizedBicycle".

- Vicki


Vicki Tardif Holland | Ontologist | vtardif@google.com


On Wed, Dec 17, 2014 at 2:55 PM, Aaron Bradley <aaranged@gmail.com> wrote:

> Thanks Martin.
>
> Regarding Bike vs. Bicycle I would also favor the latter because of
> ambiguity issues with the former.  "Bike" is often used colloquially to
> refer to a motorcycle, but no one has ever called a Harley a "bicycle." :)
>
> Regarding the PropertyValue type you say:
>> 3. A type for exposing semi-structured product and place feature
>> information
>>
>> ----------------------------------------------------------------------------
>>     http://sdo-property-value.appspot.com/PropertyValue
>> plus three new properties for this type:
>>     additionalProperty
>>     propertyID
>>     unitText
>
>
> Yet neither of the three properties listed directly above are listed in
> the property list ("Properties from PropertyValue") on...
> http://sdo-property-value.appspot.com/PropertyValue
> ...or have their own URIs, yet all three are used in the examples on that
> page.
>
> Was that simply an oversight, or were those properties intentionally
> omitted from the property listing?
>
>
> On Wed, Dec 17, 2014 at 11:39 AM, mfhepp@gmail.com <mfhepp@gmail.com>
> wrote:
>>
>> Hi Chaals,
>>
>>
>> On 17 Dec 2014, at 20:31, chaals@yandex-team.ru wrote:
>>
>> >
>> >
>> > 17.12.2014, 16:57, "mfhepp@gmail.com" <mfhepp@gmail.com>:
>> >> Hi Chaals, all:
>> >>
>> >> On 17 Dec 2014, at 14:23, chaals@yandex-team.ru wrote:
>> >>>  A few tiny comments…
>> >>>
>> >>>  17.12.2014, 13:03, "mfhepp@gmail.com" <mfhepp@gmail.com>:
>> >>>>  In effect, it adds the following elements:
>> >>>>
>> >>>>  1. Types for common vehicle categories
>> >>>>  --------------------------------------
>> >>>>
>> >>>>      http://sdo-property-value.appspot.com/Bike
>> >>>  I'd really like this to be called "Bicycle".
>> >>
>> >> If this is consensual, I am happy to change it
>> >
>> > Well, so far it is just me…
>>
>> Google's N-Gram viewer shows a slight advantage for Bicycle over Bike in
>> English:
>>
>>
>> https://books.google.com/ngrams/graph?content=a+bike%2Ca+bicycle&year_start=1800&year_end=2014&corpus=15&smoothing=3&share=&direct_url=t1%3B%2Ca%20bike%3B%2Cc0%3B.t1%3B%2Ca%20bicycle%3B%2Cc0
>>
>>
>> So I would be prone to implement this.
>>
>> >
>> >>>>  2. Properties for common, vendor-independent car features
>> >>>>  ---------------------------------------------------------
>> >>>>  For a list, see here:
>> >>>>
>> >>>>      http://www.w3.org/wiki/WebSchemas/Vehicles#New_Properties
>> >>>  transmission, gears, payload, speed, airbags, doors, damages all
>> seem like terms that could *easily* get confused, and should should
>> probably be disambiguated by making them longer and more specific.
>> >>
>> >> We have conflict between ease for use for the main case and potential
>> conflicts due to the "global property notion" in schema.org.
>> >>
>> >> I am fine to prefix them all to
>> >>
>> >> vehicleTransmission
>> >> vehicleGears
>> >> vehicleAirbags etc.
>> >>
>> >> if this is consensual - Dan, Guha what is your take?
>> >>
>> >> From a Web developers perspective, I think the shorter names are more
>> appealing because the typing effort will be much lower, and also an
>> auto-complete feature in an editor will not work as well if 20+ properties
>> have the same prefix.
>> >>
>> >> Due to the examples in three syntaxes, I would like to know the
>> consensual opinion among the sponsors of schema.org prior to
>> implementing the change.
>> >
>> > Fair enough. And you point about this becoming a bigger problem if
>> schema keeps growing is a sensible one. We either end up namespacing by
>> adding words into names and maintain the flat schema, or we do something to
>> structure it and break what we said before. In the former case, we start
>> relying on tools to help out more… which puts an onus on us to help them
>> out more…
>>
>> So in this case, I would suggest to stick with the names in the current
>> proposal. Prefixing all properties with "vehicleXYZ" will
>> - make them cumbersome to use
>> - be in contrast to the naming patterns in use for schema.org and
>> - while it reduces the risks for collisions, it makes it harder to spot
>> similarities and to reuse properties.
>>
>> Also, they are designed to be free from collisions with the existing
>> vocabulary.
>>
>> Can I infer from your mail that your are in general fine with the
>> proposal, despite these two issues?
>>
>> Martin
>>
>> >
>> > cheers
>> >
>> > Chaals
>> >
>> >> Martin
>> >>>  cheers
>> >>>
>> >>>  --
>> >>>  Charles McCathie Nevile - web standards - CTO Office, Yandex
>> >>>  chaals@yandex-team.ru - - - Find more at http://yandex.com
>> >
>> > --
>> > Charles McCathie Nevile - web standards - CTO Office, Yandex
>> > chaals@yandex-team.ru - - - Find more at http://yandex.com
>>
>>
>>