Re: Automotive, EXIF, Property-Values

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
>
>
>