Re: Generic Property-Value Proposal for Schema.org

Hi Richard:

On 02 May 2014, at 19:41, Wallis,Richard <Richard.Wallis@oclc.org> wrote:

> 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 vocabulary.
> 
Thanks!

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

This is possible, but I think it is overly conservative to say we cannot have it for Products and Places, were there is a pretty strong case that we need it, just because we do not want other branches to request it, too.

The sponsors of schema.org can decide for any branch / type individually whether the benefit outweights the cost. I do not think there is any hard-wired road from having this in Product and Place to having it all over.

Also note that Google et al. have a very strong mechanism for culling back abuse of this generic mechanism: They can at anytime make a certain more structured variant a mandatory requirement for a certain effect (e.g. rich snippet). So if someone at Google, Yahoo, Bing, Yandex want to encourage a less ambigous representation for ease of consumption, he or she can always promote a dedicated property and make this a formal requirement for a certain effect.

One can also look at this from the opposite direction: The proposed pattern will foster a demand- and data-driven evolution of properties, i.e. only such properties have to be standardized in schema.org that are needed from the main consumers. Currently, we as vocabulary developers often have to guess which properties make sense and find sweet spots between data structures that are useful and data structures that are easy to populate. 

Actually, the initial reasons for me to develop the proposal were the following:

1. My team and I are maintaining or advising the maintainers of numerous extension modules for shop application, with in total more than 40,000 installations. We always wanted the users to also expose product feature data, but as most of the software is set up, it is very hard to map the data to any given property, since the properties are typically locally defined in the shop. This means that site-owners have to manually set up the mapping between their properties and the standardized ones. So they simply do not use these features. With the new proposal, we could make it a default.

2. There are lots of standards that define product properties and/or classes, like eClass, GPC, UNSPSC, ETIM, CPV. Historically, we have tried to transcribe them to OWL ontologies so that people could use them to annotate data. But this is a lot of effort, and we have not been able to convince people at scale to use those ontologies. The main reason is that for most shops and manufacturers' sites, it is difficult to publish respective data. Even if they have the local codes for a property in their database, publishing the resulting URI is often prohibitively difficult for them.

It is good that GS1 is going the linked data way now, but we need a way of using standard identifiers without first publishing OWL ontologies derived from a standard.

By the way, note that the most popular way of exposing "True" and "False" in schema.org is the respective string, not http://schema.org/True and http://schema.org/False.



> 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

Again: I think it will be up to the sponsors of schema.org to foster the development of properly detailed schemas. The proposal just ads a mechansim for preserving data structure and data semantics if a richer representation is not feasible.

> 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.
+ 1

Martin

Received on Friday, 2 May 2014 20:57:17 UTC