EXIF, Property-Values (was RE: Automotive, EXIF, Property-Values)

Changing the subject to discuss property-value pairs separately.

I am supportive of adding the proposed property-value and EXIF changes into schema.org, but I would like to see them separated out from the other changes so we can approve and incorporate them independently and so that there is a clearer change history for people to follow in GitHub.

Assuming we make this change, however, I think it is essential that we provide guidance on when it is acceptable to use these constructs. In particular, if publishers start to use property-value pairs where there are equivalent schematized properties, it will significantly dilute the value of the vocabulary. Therefore, I think we need to document a requirement that the name in the property-value pairs cannot match a schema.org property (it would therefore be considered invalid markup if the name did match).

I think we should also have an informal agreement as a community that we will make additions to the vocabulary for any properties that turn out to be widely used in property-value pairs so that we can encourage more normalized and consistent representations.

What do others think?

Thanks,
Tom

-----Original Message-----
From: Tom Marsh 
Sent: Friday, January 09, 2015 1:33 PM
To: 'mfhepp@gmail.com'; Thad Guidry
Cc: Vicki Tardif Holland; W3C Web Schemas Task Force
Subject: RE: Automotive, EXIF, Property-Values

Hi, Martin,

I finally had a chance to read through the automotive proposal in detail. Here are my comments:

In general, I think we should review and make changes to schema.org in smaller self-contained units. In this case, that would mean splitting out the changes into:
(1) the value-prop changes, which I will send a separate mail on.
(2) the auto changes
(3) the bicycle changes
(4) the boats changes

For the bicycle and boat changes, I think we should defer the changes for now. In both cases, I did a quick survey of boats/bicycles for sale and manufacturer sites, and I saw little overlap between the main attributes they used to describe the boats/bicycles vs. what is present in the Bicycle, Watercraft, Boat, MotorBoat, and SailingBoat proposals. I think we should revisit this as a separate change once there are more complete and detailed proposals for these types with their own use-cases, etc. (the use cases in the current proposal are all auto-specific).

One small note on Bicycle, when we add it: why does Bicycle allow for “some bicycles have a small combustion or electric engine that assists with pedaling” when there is a separate MotorizedBicycle type for that?

On the auto changes, I think we should incorporate these into schema.org, but I have a bunch of detailed comments. I'll separate my comments into types and properties:

-- Types --
Car vs. Van vs. Truck – Can this be modeled as body styles (now called bodyType) instead? The three example sites seem to do this, and it strikes me as cleaner from a vocabulary point of view, especially as companies continue to blur the lines between these (SUVs, crossovers, etc.).

For EmissionStandardValue, TransmissionTypeValue, EngineTypeValue, and BodyTypeValue, there doesn’t seem to be any distinction in the usage vs. using Text, so why do we need these? If we were to have enumeration values for these, then having separate types would make more sense to me.

For FuelTypeValue, I saw on the US version of Autotrader (one of the examples cited on the wiki) values of Alternative, Diesel, Electric, Gasoline, and Hybrid. These are missing from the enumeration, and I think they should be added. Also, I haven’t seen a reference to TwoStrokeMixture (the only current enum value for this type) from the sorts of sites in the use case list before. Is that for motorcycles? Or if the entire purpose of this type is to add TwoStrokeMixture to the lists already available on DBPedia/Freebase/etc., then I would argue people can just enter text for that, and we can remove the FuelTypeValue in favor of having people directly use QualitativeValue.

For CarUsageType, the name and description don’t imply past usage to me. Should we rename this as something like PastCarUsageType instead? Otherwise, when I first read it, I was expecting this type to be used to describe the current use (i.e., available for rental now, not available for sale to a private owner but previously used as a rental car).


-- Properties --
Can we rename ACRISSCode to acriss and VIN to vin? Other similar properties (isbn, gtin13, gtin14, etc.) follow this naming convention.

Can we rename acceleration to accelerationTime? This would make the usage slightly clearer and also remove the issues in the notes about there not being unit codes for acceleration.

Can we rename colorInterior to interiorColor to be consistent with things like tongueWeight, seatingCapacity, modelDate, etc.?

How should a publisher specify the condition (new/used/etc.)? It seems like we could reuse the existing itemCondition property (with updated description) for this.

configurationName seems to be duplicating a bunch of other properties (transmission, enginePower, bodyType, etc.). If people are going to do this, IMO, they should just use the name property. There is a concept of trim level that the US version of AutoTrader uses, which I think is missing and would be useful. That would capture probably just the “ST 2.5” part of the example. For a Subaru Legacy, on the US AutoTrader site, for example, you’ll see values such as “2.5GT Limited”, “2.5i”, “3.6R Limited”, etc. 

The engine properties (displacement, name, power, and type) should probably be separated out into their own type, especially if we want to model multiple engines per vehicle (as some of the descriptions suggest). Otherwise, it will not be explicit which property sets go together.

For enginePower, should we also list the unit code for horsepower (BHP?)?

For fuelConsumption and fuelEfficiency, it would be good to have examples of these in addition to the existing notes. Also, I am not sure it makes sense to put the “wrong” units in the unitCode property. Why not guide people to use unitText instead? I thought that unitText was introduced for just this situation; i.e., when there is no standard code to refer to.

fuelType is on Vehicle, but fuelConsumption and fuelEfficiency are only on the more specific types. I think the placement of these three properties should be consistent, and I like putting them on the more specific types.

For gears, the description says forward and reverse gears, but I think it is customary to only list the forward gears. The example for Car also seems to list only the forward gears. Should we update the description?

For interiorType, if this is intended to describe just the material, should we rename it to interiorMaterial?

It looks like numberOfOwners was renamed to previousOwners. It would be nice to have the wiki updated if so.

What is the use case for productionDate? I’m not sure we need this property, but if we do, can we reuse the existing dateCreated property instead? It sounds like it would have the same meaning.

Can we rename purchasingDate to purchaseDate and firstRegistration to firstRegisteredDate? Our date property naming in schema.org isn’t very self-consistent, but I think these suggestions will be more consistent.

transmission mentions sending power to propellers, but this property is on MotorizedRoadVehicle. Should it instead be on Vehicle? Or should the description be updated? 

There are some typos:
In the description for fuelCapacity: staorage => storage In the description for unitText: “Useful if you cannot provide a standard unit code for” what?
In the descriptions for payload and weightTotal: permited -> permitted


Thanks,
Tom

-----Original Message-----
From: mfhepp@gmail.com [mailto:mfhepp@gmail.com]
Sent: Monday, December 22, 2014 11:47 AM
To: Thad Guidry
Cc: Vicki Tardif Holland; W3C Web Schemas Task Force
Subject: Re: Automotive, EXIF, Property-Values

Hi Thad,
Good point! It should be straightforward to add such clarification to the schema:QuantitativeValue entity via schema:valueReference.

The textual definition of all or most of the properties already tries to address such issues:

E.g.

http://sdo-property-value-and-cars.appspot.com/tongueWeight


says:

The permited vertical load (TWR) of a trailer attached to the vehicle. Also referred to as Tongue Load Rating (TLR) or Vertical Load Rating (VLR).
Typical unit code(s): KGM for kilogram, LBR for pound Note 1: You can indicate additional information in the name of the QuantitativeValue node.
Note 2: You may also link to a QualitativeValue node that provides additional information using valueReference.
Note 3: Note that you can use minValue and maxValue to indicate ranges.

So you can either use an existing URI to indicate a reference to the respective standard, as in

<div id="product" property="itemOffered" typeof="Car">
  <strong property="name">2009 Volkswagen Golf V GTI MY09 Direct-Shift Gearbox</strong>
  <p property="description">2009 Volkswagen Golf V GTI MY09 Direct-Shift  (...)
  </p>
  <p><strong>Tongue Weight: </strong>
    <span property="tongueWeight" typeof="QuantitativeValue">
      <span property="value">250</span> 
      <meta property="unitCode" content="KGM">kg
      (according to <a property="valueReference" href="http://standards.sae.org/wip/j2807/">SAE J 2807 Performance Requirements for Determining Tow-Vehicle Gross Combination Weight Rating and Trailer Weight Rating)</a>
      </span>
    </span>
  </p>
..
</div>

or define a schema:QualitativeValue or schema:StructuredValue to provide this link:

<div id="product" property="itemOffered" typeof="Car">
  <strong property="name">2009 Volkswagen Golf V GTI MY09 Direct-Shift Gearbox</strong>
  <p property="description">2009 Volkswagen Golf V GTI MY09 Direct-Shift  (...)
  </p>
  <p><strong>Tongue Weight: </strong>
    <span property="tongueWeight" typeof="QuantitativeValue">
      <span property="value">250</span> 
      <meta property="unitCode" content="KGM">kg
      (according to <span property="valueReference" typeof="QualitativeValue">
        <meta property="name" content="J2807"> 
  <span property="description">SAE J 2807 Performance Requirements for Determining Tow-Vehicle Gross Combination Weight Rating and Trailer Weight Rating"</span>
  <link property="url" href="http://standards.sae.org/wip/j2807/" />
      </span>
    </span>
  </p>
..
</div>

Of course, we can also use WikiData URIs for referencing standard procedures for measuring certain characteristcs.

Does that cover your requirements?

Martin

-----------------------------------
martin hepp  http://www.heppnetz.de

mhepp@computer.org          @mfhepp







On 22 Dec 2014, at 20:05, Thad Guidry <thadguidry@gmail.com> wrote:

> RED FLAG - I have some deep concerns in one area regarding the description of weights throughout this schema proposal.
> 
> We need to be much more clear about the use of the word "permitted" in the description of weights within this Schema for the safety and protection of consumers and human life.
> 
> Of particular concern for me and consumers is the adherence of industry standards and those that are not followed closely or not at all by manufacturers.
> Manufacturer claims are sometimes not the same claim as an industry 
> standard, such as SAE J2807  http://standards.sae.org/wip/j2807/

> 
> Here is an example of some of the issues involved: 
> http://www.autonews.com/article/20130211/OEM03/302119913/pickup-truck-

> towing-standard-isnt-standard
> 
> I would like the schema to be very clear on the designation of "permitted" ... by whom ?  A manufacturer or government regulation or industry regulation ?
> 
> I would like to make this clear perhaps by having an enum to capture the "permitted by whom" while not taking sides with either the manufacturer claims or the government / industry claims.
> 
> Thoughts ?
> 
> 
> Thad
> +ThadGuidry
> 
> On Mon, Dec 22, 2014 at 10:40 AM, mfhepp@gmail.com <mfhepp@gmail.com> wrote:
> Hi Vicky:
> 
> Thanks! See inline comments.
> Martin
> -----------------------------------
> martin hepp  http://www.heppnetz.de

> mhepp@computer.org          @mfhepp
> 
> 
> On 22 Dec 2014, at 17:30, Vicki Tardif Holland <vtardif@google.com> wrote:
> 
> > Hi Martin,
> >
> > I have a couple quick questions about the new Vehicle schema.
> >
> > 1. What is the difference between tongueWeight and trailerWeight?
> 
> tongueWeight is the maximum weight your trailer hitch can handle of the downward force exerted on it by the trailer's tongue (the arm that extends from the trailer that couples with the tow vehicle's receiver) (snippet taken from http://auto.howstuffworks.com/auto-parts/towing/vehicle-towing/maneuvers/dead-weight-towed-weight1.htm). In essence, how much your trailer can push down the pulling car without lifting its wheels.
> 
> trailerWeight is the maximum weight is of a fully loaded trailer, so in essence how much the pulling vehicle + trailer hitch can pull in driving direction.
> 
> 
> > 2. Vehicle has an interiorColor property. Would you advise using the "color" property for the exterior color?
> Yes.
> 
> > 3. There is a lot of detail here. Do you have examples that can be published on schema.org to help guide users?
> 
> Yes, they are already included in
> 
> http://sdo-property-value-and-cars.appspot.com/Car

> 
> Please scroll down to examples or see here
> 
>     
> https://github.com/mfhepp/schemaorg/blob/property-value-and-cars/data/

> sdo-automobile-examples.txt
> 
> Again, thanks for looking at the proposal. Please do not hesitate to contact me if you have further questions.
> 
> Martin
> 
> 
> >
> > Cheers,
> > Vicki
> >
> >
> > Vicki Tardif Holland | Ontologist | vtardif@google.com
> >
> >
> > On Wed, Dec 17, 2014 at 5:01 AM, mfhepp@gmail.com <mfhepp@gmail.com> wrote:
> > Dear all:
> >
> > Based on many bilateral discussions, I have updated the proposal for cars and other vehicles [1] and the property-values mechanism for product feature data [2].
> >
> > A live demo is up and running at
> >
> >     http://sdo-property-value.appspot.com/

> >
> > The proposal updates schema:Car (new:http://sdo-property-value.appspot.com/Car) and schema:Vehicle (new: http://sdo-property-value.appspot.com/Vehicle). It incorporates and is aligned with the Yandex proposal for cars [3] (Yuliya and I analyzed the overlap).
> >
> > A Github fork based on sdo-venkman is available at
> >
> >     https://github.com/mfhepp/schemaorg/tree/property-value-and-cars

> >
> > I have already created a respective pull-request to https://github.com/danbri/schemaorg/tree/sdo-venkman.

> >
> > In effect, it adds the following elements:
> >
> > 1. Types for common vehicle categories
> > --------------------------------------
> >
> >     http://sdo-property-value.appspot.com/MotorizedRoadVehicle

> >     http://sdo-property-value.appspot.com/Truck

> >     http://sdo-property-value.appspot.com/Van

> >     http://sdo-property-value.appspot.com/MotorizedBicycle

> >     http://sdo-property-value.appspot.com/BusOrCoach

> >     http://sdo-property-value.appspot.com/Motorcycle

> >     http://sdo-property-value.appspot.com/Bike

> >     http://sdo-property-value.appspot.com/Watercraft

> >     http://sdo-property-value.appspot.com/Boat

> >     http://sdo-property-value.appspot.com/MotorBoat

> >     http://sdo-property-value.appspot.com/SailingBoat

> >
> > plus a few utility types for quantitative values.
> >
> > 2. Properties for common, vendor-independent car features
> > ---------------------------------------------------------
> > For a list, see here:
> >
> >     http://www.w3.org/wiki/WebSchemas/Vehicles#New_Properties

> >
> > 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
> >
> > plus slight modifications to unitCode, minValue, maxValue, value, and valueReference:
> >
> >     
> > https://www.w3.org/wiki/WebSchemas/PropertyValuePairs#Changes_to_Exi

> > sting_Elements
> >
> > 4. A mechanism for exposing standardized and vendor-specific EXIF 
> > image meta-data to schema:ImageObject
> > --------------------------------------------------------------------
> > -----------------------------------
> >
> > This happens by simply including schema:PropertyValue to the range 
> > of schema:exifData, see
> >
> >      http://sdo-property-value.appspot.com/ImageObject

> >
> > Examples for the use for EXIF meta-data are here:
> >
> >     
> > https://www.w3.org/wiki/WebSchemas/PropertyValuePairs#ImageObject:_E

> > XIF_Meta-data
> >
> > See also
> >     
> > https://www.w3.org/wiki/WebSchemas/PropertyValuePairs#EXIF_Image_Met

> > a-data
> >
> >
> > The proposal comes with a full set of examples in Microdata, RDFA, and JSON-LD; only the property-value examples are currently given in Microdata only. I can add them on other syntaxes if needed.
> >
> > I hope that this final specification addresses all issues from the previous discussions and can be agreed upon.
> >
> > Best wishes
> > Martin Hepp
> >
> >
> > [1] https://www.w3.org/wiki/WebSchemas/Vehicles

> > [2] https://www.w3.org/wiki/WebSchemas/PropertyValuePairs

> > [3] http://help.yandex.ru/webmaster/supported-schemas/review-car.xml

> >
> > -----------------------------------
> > martin hepp  http://www.heppnetz.de

> > mhepp@computer.org          @mfhepp
> >
> >
> >
> >
> >
> >
> >
> >
> >
> 
> 
>

Received on Friday, 9 January 2015 21:51:01 UTC