Re: Generic Property-Value Proposal for Schema.org

> Could we use the existing extension mechanism instead of inventing a new
one?

It's long been acknowledged that the existing extension mechanism is
problematic, so I  think of this less as an additional extension mechanism
than potentially a more workable replacement for the existing extension
mechanism.

Way back in January 2012 [1] Dan had this to say:

> Firstly, we've had feedback over last few months that expresses
skepticism about the "/"-based extension mechanism and the extent to
which it's useful to emphasize it.

I don't think this state of affairs has changed over the past two and a
half years.  And in fact, I can't recall seeing a single extension deployed
that actually conforms to the originally prescribed pattern (can anyone
provide an example?).

So I think using the existing extension mechanism is a non-starter, because
IMO the existing extension itself has proved to be a non-starter.

[1] http://lists.w3.org/Archives/Public/public-vocabs/2012Jan/0002.html -
This is just one of many discussions that have taken place surrounding
schema.org's extension mechanism.  Cf. http://bit.ly/1kwzXcf



On Fri, May 2, 2014 at 10:03 AM, Jason Douglas <jasondouglas@google.com>wrote:

> Could we use the existing extension mechanism instead of inventing a new
> one?  Something like add productSpecification that expects
> QuantitativeValue and then extend it.  So:
>
> {
>   @type: Product
>   productSpecification/screenSize : {
>     value: 46
>     unitCode: "CMT"
>   }
> }
>
>
> On Fri May 02 2014 at 9:30:08 AM, Kevin Polley <
> kevin.polley@mutualadvantage.co.uk> wrote:
>
>> 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
>> >>
>> >>
>> >>
>> >
>>
>>
>>
>>