Re: Generic Property-Value Proposal for Schema.org

As an early adopter and webmaster myself I would also like to see this
very useful proposal move forward.

Following the various threads of Martin's proposal has been interesting
and informative. From my perspective, the benefits of having available a
generic extension mechanism for properties that helps to overcome current
limitations is very appealing and I can already feel the potential
frustration that Aaron describes should property-value pairs only become
available for Product.

In part this frustration echoes that of some decision makers who discover
they are unable to expose facts about aspects of their business and their
products or services that they have identified as important to them and
their customers. From my seat I see property/value pairs as providing
solutions, opportunities and benefits that can be improved later once the
uptake and usage is quantified.

best,

Kevin


> I like the direction of this proposal very much:  in general this has the
> potential to extend the potential expressiveness of schema.org a leap
> forward with a single step.  A few points on what's been said so far.
>
> As Holger Knublauch said I believe we should not mix up a discussion about
> a data model with the current set of syntaxes, and like Martin I think
> it's
> important this work with microdata.  Forcing webmasters who want to avail
> themselves of this mechanism that have otherwise cast their lot with
> microdata to mix-and-match with RDFa or JSON-LD is an onerous adoption
> killer, and heaping on syntaxes will certainly ensure an increase in code
> errors.
>
> While the genesis of this idea was product description, I see no reason
> whatsoever why this should be restricted to Product, Place or any other
> specific type.  Thad, I believe you first brought this up:  was there
> something in the Freebase experience informs your opinion on this?  Or a
> reason from your end Jason?
>
> It seems to be that one of the chief benefits of a generic property
> declaration mechanism is that its, well, generic.  If this were to roll
> out, webmasters (myself included) will immediately find themselves lacking
> in a very useful property, see a means of adding it, but be frustrated in
> the attempt by the limitation on applicable types.  And the ready
> extensibility provided by this makes it conducive to the generation of
> useful extensions, necessarily lost in the revised proposal limiting
> additionalProperty's use (literally crossed out).  Given the usefulness of
> this, what's the compelling argument to limit its use?
>
> Justin Boyan
>>Can you give some examples of how this style of data could be used by a
> search engine or aggregator to drive interesting features? It seems like
> it's pushing too much work to the consumer side. Every different
> website/producer will come up with their own different terminology for the
> same attributes, which sort of defeats the purpose of a common vocabulary.
>
> My only misgiving is along these lines - that by providing for the ad hoc
> addition of new properties, we're diminishing the value of
> *shared*vocabulary that multiple data consumers understand.  But I
> think valuable
> extensions will end up being broad understood and/or incorporated into the
> core.  And more to the point, data consumers and publishers are already
> extending schema.org with new properties on a regular basis, as with
> Google's financialQuote properties or OCLC's exampleOfWork.  Which I think
> is fine, but are such ad hoc methods of adding properties preferable to
> using this proposed method of exposing property/value pairs?
>
> Jay Myers
>>I'm encouraged to see this proposal move forward -- we have used similar
> techniques on our RDF/ SPARQL platform to expose deep attribute sets, with
> excellent results that enable discovery and exploration of long tail
> products. I can provide further details if people are interested. I would
> imagine that enabling the same functionality in schema.org would open up
> many possibilities to enrich product search and discovery through the
> search engines.
>
> Great to have your input Jay, and yes, I'd love to see further details!
>
>
>
> On Wed, Apr 30, 2014 at 6:47 PM, martin.hepp@ebusiness-unibw.org <
> martin.hepp@ebusiness-unibw.org> wrote:
>
>> Dear Jay:
>> Thanks for your +1!
>> I just updated the proposal and now constrain the core property
>> additionalProperty to Product OR Place.
>>
>> Martin
>>
>> On 01 May 2014, at 03:44, Myers, Jay <Jay.Myers@bestbuy.com> wrote:
>>
>> > All,
>> >
>> > I am still catching up on all the threads in this discussion, but
>> wanted
>> to add my perspective as a publisher of large amount of product data...
>> >
>> > I'm encouraged to see this proposal move forward -- we have used
>> similar
>> techniques on our RDF/ SPARQL platform to expose deep attribute sets,
>> with
>> excellent results that enable discovery and exploration of long tail
>> products. I can provide further details if people are interested. I
>> would
>> imagine that enabling the same functionality in schema.org would open up
>> many possibilities to enrich product search and discovery through the
>> search engines.
>> >
>> > From experience we realized it would take endless numbers of human
>> hours
>> to grok, organize, and standardize properties for every product category
>> --
>> even our relatively small(ish) catalog consisting of 700K products with
>> around 1110 product categories. I can also say that no site owner or
>> developer is going to go through the trouble of mapping their product
>> data
>> to an external set of mappings. However, this data has tremendous value
>> and
>> I believe Martin's proposal can unearth that, allowing consumption by
>> machines which should be able to easily synthesize it if need be.
>> >
>> > +1 Thad's idea of keeping at the Product level.
>> >
>> >
>> > ---
>> > Jay Myers
>> > Product Manager/ Architect
>> > bestbuy.com Product Recommendations, Product Ontology Platforms
>> >
>> >
>> > ________________________________________
>> > From: martin.hepp@ebusiness-unibw.org
>> <martin.hepp@ebusiness-unibw.org>
>> > Sent: Wednesday, April 30, 2014 8:16 PM
>> > To: Mike Bergman
>> > Cc: W3C Web Schemas Task Force
>> > Subject: Re: Generic Property-Value Proposal for Schema.org
>> >
>> >> Are you saying there are legal restrictions to create mapping files
>> between industry standards (some of which may be proprietary) and
>> internal
>> vocabularies? Are there any restrictions to publicly releasing such
>> mappings?
>> >>
>> >> If these are allowable, then "hosting" the native vocabularies is
>> immaterial.
>> >>
>> >> My understanding of the answer to these two questions is NO.  But, I
>> only play a lawyer on TV.
>> >>
>> >
>> >
>> > I was saying that publishing an OWL vocabulary containing at least
>> class
>> and property labels that is directly derived from an existing
>> classification standard requires a license from the owner of the
>> intellectual property. That means that unless you can motivate the
>> standards body to publish a Web ontology version of its classes and
>> properties, it is very difficult to use that standard for structured
>> data
>> on the Web. I am no lawyer and can thus not assess whether collections
>> of
>> identifiers alone are subject to IPR, but in general, this is a
>> non-trivial
>> issue.
>> >
>> > For instance, I have been trying to get legal approval from the UN
>> from
>> 2004 - 2007 to publish my OWL variant of www.unspsc.org on the Web, or
>> for them to host my OWL versions on their server, and eventually gave
>> up.
>> >
>> > For eClass, we developed a proper OWL transformation, but since eClass
>> lives from membership fees for accessing the full standard, they could
>> eventually not agree to publishing the OWL version on the Web after the
>> 5.1
>> version (for which they had given me permission).
>> >
>> > And the story goes on.
>> >
>> > With my proposal, you can immediately use the local identifiers for
>> any
>> of the properties from eClass, GPC, etc. for exposing product feature
>> >
>> >
>> > Best
>> > Martin
>>
>>
>>
>

Received on Friday, 2 May 2014 16:28:37 UTC