Re: Generic Property-Value Proposal for Schema.org

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 <https://www.google.com/+ThadGuidry>
Thad on LinkedIn <http://www.linkedin.com/in/thadguidry/>

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.orgproperty, 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
>
>