Re: Generic Property-Value Proposal for Schema.org

Hi Dan:

A few points:
- a) works in any syntax, and we need a way that can be used in Microdata as it stands.
- Even if JSON-LD and RDFa simplify the use of external properties, we cannot standardize all product properties for all product types inside of schema.org, nor expect site owners to be able to map their data to a large number of externally given properties. Note that they will otherwise have to manually review all of their local properties for compatibility.
- Even for JSON-LD and RDFa this proposal gives some common structure.
- The proposal preserves a few basic distinctions: Unit of measurement as a code, if available; point values, intervals, open intervals, property names, and property codes like eClass codes.

Let me say it that clear: Either we provide a mechanism like this that allows exposing relatively lightweight property-value pairs for product features in schema.org, or product feature data will not be marked up by Web sites for the next five years to come. It does not have to be exactly this proposal, but it must be something with a similarly low barrier for adopters.

As already said, I can live with limiting the domain of additionalProperty to http://schema.org/Product if that minimizes concerns. And you can and should tell users of schema.org that if there is a dedicated schema.org property, it is better to use that.

But the core question is: Does Google want to access more product feature details or not? I am confident that with 1 - 2 days hacking in SPARQL and Python, I could do very nice things with the expected types of data. So Google/Bing/Yahoo/Yandex should also be able to do the same.

Best wishes 

Martin

On 01 May 2014, at 02:00, Dan Brickley <danbri@google.com> wrote:

> On 30 April 2014 16:35, martin.hepp@ebusiness-unibw.org
> <martin.hepp@ebusiness-unibw.org> wrote:
>> Hi Jason:
>> 
>> I could live with having this at the position of http://schema.org/Product, and maybe gradually expanding the domain of additionalProperty to relevant other types on demand. Personally I think that having a generic extension mechanism at the level of http://schema.org/Thing is a bit more appealing, but I would not have a problem with starting at a deeper branch and then seing how it develops in the wild.
>> 
>> Dan, Guha - do you have any opinion on this?
> 
> I haven't had a chance to have a good look at the new proposals (hello
> from an airport...), but when we discussed this during the original
> good relations integration, it felt too 'black box', and that treating
> propertyy-like-things as properties rather than reifying them might
> work better. On that front I wonder whether using JSON-LD could give
> more syntactic options than Microdata?
> 
> <div itemtype="http://schema.org/Product">
>  <img itemprop="image" src="camera123.jpg" />
>  <span itemprop="name">Digital Camera 123</span>
>  <div itemprop="additionalProperty" itemscope
> itemtype="http://schema.org/PropertyValue">
> <span itemprop="name">Operating Voltage</span>
> <span itemprop="minValue">100</span>-
> <span itemprop="maxValue">250</span>
> <meta itemprop="unitCode" content="VLT">volts
>  </div>
> </div> from https://www.w3.org/wiki/WebSchemas/PropertyValuePairs
> 
> In JSON-LD:
> 
> a)
> { "@context": "http://schema.org",
>  "@type": "Product",
>  "image": "camera123.jpg",
>  "name": "Digital Camera 123",
>  "OperatingVoltage": { "minValue": "100", "maxValue": "250", "unitCode": VLT" }
> }
> 
> vs your
> 
> b)
> { "@context": "http://schema.org",
>  "@type": "Product",
>  "image": "camera123.jpg",
>  "name": "Digital Camera 123",
>  "additionalProperty": { "name": "Operating Voltage", "minValue":
> "100", "maxValue": "250", "unitCode": VLT" }
> }
> 
> Is (a) really so much easier?
> 
> Dan

Received on Thursday, 1 May 2014 00:17:16 UTC