W3C home > Mailing lists > Public > public-vocabs@w3.org > May 2014

Re: Generic Property-Value Proposal for Schema.org

From: <martin.hepp@ebusiness-unibw.org>
Date: Thu, 1 May 2014 03:31:39 +0200
Cc: Dan Brickley <danbri@google.com>, Jason Douglas <jasondouglas@google.com>, W3C Web Schemas Task Force <public-vocabs@w3.org>
Message-Id: <49CF40DF-B4A4-47E7-B39C-939E37B68AA5@ebusiness-unibw.org>
To: Thad Guidry <thadguidry@gmail.com>
Thad, all:

Thanks for the encouragement.

I have just updated the proposal accordingly:

1. The new domain for additionalProperty is now Product OR Place (we will need it for hotels lateron, so I kept Place).
2. I removed the mentions of using this as a generic extension mechanism for properties.

I hope that this new version is broadly acceptable.

Wiki: https://www.w3.org/wiki/WebSchemas/PropertyValuePairs#Issues
Mercurial: https://bitbucket.org/mfhepp/property-value-pairs-for-schema.org


On 01 May 2014, at 03:11, Thad Guidry <thadguidry@gmail.com> wrote:

> In 2008-ish... Freebase experts and staff had a sort of grand idea of "Feature" to encompass any particular Product "property" as I recall.
> A whole Feature-y phrase could be supported as well... "Left-handed auto drag" bass fishing reel "reel"  vs. "Right-handed open face" fishing reel "reel" ... both are a type of reel ...and everyone can see that within those phrases there are some sub-property candidates... whatever....the point is...
> That grand idea is a fairly close mirror-image of Martin's "additionalProperty".
> In Freebase, we also were a bit wary of pushing this kind of generic system up to our "Topic" or "Thing" level.
> As it stands, the grand idea was never implemented completely, but it still has VERY GOOD merits (and I concur with Martin on this)... but I would only be accepting of it at a Product level to minimize the concerns I have and that we had back in 2008.
> (The "grand concern" was that folks would only use it 50% correctly anyway, and we would probably get our assumptions of their context 25% of the time correct, as well.) 
> +1 for the idea, but keeping it at the Product level, for now.
> -- 
> -Thad
> +ThadGuidry
> Thad on LinkedIn
> On Wed, Apr 30, 2014 at 7:16 PM, martin.hepp@ebusiness-unibw.org <martin.hepp@ebusiness-unibw.org> wrote:
> 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
Received on Thursday, 1 May 2014 01:32:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:29:41 UTC