Re: Generic Property-Value Proposal for Schema.org

I am generally supportive of the proposal, as it is emerging, as a way of introducing enriched descriptions of resources from already available structure/properties before [if ever] they could be introduced into the Schema.org<http://Schema.org> vocabulary.

Although I understand the conservative approach of only initially applying it to a sub-set of Types (e.g.. Product), I believe that we would soon wish that we had done it fully (on Thing) as we are hit with a flurry of requests to usefully add it to CreativeWork, MedicalEntity, Organization, Person, etc.

So as I say I am generally in favour, howeverI feel it could also be a bit of a double edged sword.

Currently, without the ability to add generic properties, in a defined but broadly ad hoc way, proposers have to convince this group of the benefits of new properties.  They also need to gain consensus as to their naming, domain and range so as not to cause confusion, misunderstanding and problems for others.  This adds some rigour to our decisions, at the expense of some inertia, but with hopefully benefits as to the generic benefit of many groups sharing the same vocabulary.

I fear with the adoption of this proposal, it will be all to easy for groups to add [their domain specific] generic properties to their descriptions to solve localised problems.  From my experience with the SchemaBibEx group, I can think of some occasions where we would have added some generic properties, if we had the option, and missed some of the broader benefits to Schema that I believe flow from from some of our proposals.

At its extreme this could replace the cacophony of multiple vocabulary choices (to which Schema is becoming an effective antidote) with one of generic property types/values from well known and/or obscure sources.  Pragmatically, generic solutions have limits for delivering consistency across disparate domains before starting to constrain innovation.  Maybe the need behind this proposal is a heads up we are nearing that.

So in summary:
Proposal +1
Product only -0.5

Plus a warning to folks not to run beyond the initial intention and use it as an easy way of bypassing the effort need for beneficial enhancement of the Schema vocabulary itself.


~Richard

On 2 May 2014, at 12:30, Aaron Bradley <aaranged@gmail.com<mailto: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<http://schema.org/>'s extension mechanism.  Cf. http://bit.ly/1kwzXcf



On Fri, May 2, 2014 at 10:03 AM, Jason Douglas <jasondouglas@google.com<mailto: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<mailto: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<http://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<http://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<http://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<mailto:martin.hepp@ebusiness-unibw.org> <
> martin.hepp@ebusiness-unibw.org<mailto: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<mailto: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<http://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<http://bestbuy.com/> Product Recommendations, Product Ontology Platforms
>> >
>> >
>> > ________________________________________
>> > From: martin.hepp@ebusiness-unibw.org<mailto:martin.hepp@ebusiness-unibw.org>
>> <martin.hepp@ebusiness-unibw.org<mailto: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<http://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<http://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
>>
>>
>>
>