Re: Generic Property-Value Proposal for Schema.org

Fine, but I think there's an aspect of that mechanism that would be a shame
to drop, which is that it had some semantic scoping.

I think it's a bad idea to have a completely generic bailout mechanism like
this.  However, I have no issue with more localized bailouts for things
like product specifications or sports statistics that do have common
characteristics but a lot of variety and uniqueness.  You at least have
some hope of being able to do something useful with that data.  Otherwise,
there's little value over a bag of words.

On Fri May 02 2014 at 10:30:24 AM, Aaron Bradley <aaranged@gmail.com> wrote:

> > 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
>>> >>
>>> >>
>>> >>
>>> >
>>>
>>>
>>>
>>>
>