- From: Jindřich Mynarz <mynarzjindrich@gmail.com>
- Date: Wed, 31 Jul 2013 15:19:17 +0200
- To: public-vocabs@w3.org
- Message-ID: <CAE=8Bu-kdnVsWE5CrFttRjiMoOhPY_73zVD_GOhv53_+D3ifjw@mail.gmail.com>
Hi, I want to ask a few questions related to the nature of change in Schema.org. The major question is if there were any backwards-incompatible changes in Schema.org besides fixes of obvious errors? I thought about this when I was pondering the prospects of our proposed Schema.org extension [1] to be pulled into the core Schema.org. Having looked through the archive of this mailing list I found several emails that suggested very similar changes to the ones that we do in the extension for the job market. For example, both [2] and [3] mention changing the schema:hiringOrganization property into more general schema:employer property that could be used not only with schema:Organization, but with schema:Person as well. [2], [3] and [4] note that there should be a way to express when schema:JobPosting ceases to be valid (by adding schema:dateClosing or schema:dateExpires, for example), which is also the case for our proposal. On this note, Martin Hepp suggests using gr:validThrough [5]. The emails mentioned also discuss other things overlapping with our proposal, such as remote jobs or salary range (min, max). The discussion about these modelling decisions dates back to 2011, since when the original schema:JobPosting remained fairly stable. This leaves me wondering whether there is in fact any chance of incorporating such changes in Schema.org. I think it would be beneficial if Schema.org maintainers were upfront about accepting backwards-incompatible change proposals. If no backwards-incompatible changes are pulled into Schema.org, that's fine, but it should be documented. Is the Schema.org policy regarding such changes available online? Having this issue resolved would then help Schema.org users to decide on the trade-off whether they should settle for the core Schema.org (perhaps enhanced with incremental extensions) or if they are willing to depart from the Schema.org either by creating a backwards-incompatible extension or a standalone vocabulary (possibly mapped to Schema.org). On a related note, I want to ask a more concrete question. The Schema.org extension mechanism [6] provides guidance on minting new sub-properties of existing properties. How you, however, create super-properties? Are extension proposals allowed to add super-properties? For instance, our proposal for the domain of job market adds the property schema:employer, which is defined as a super-property to schema:hiringOrganization. Best, Jindrich [1] http://www.w3.org/wiki/WebSchemas/JobMarket [2] http://lists.w3.org/Archives/Public/public-vocabs/2011Oct/0066.html [3] http://lists.w3.org/Archives/Public/public-vocabs/2011Dec/0014.html [4] http://lists.w3.org/Archives/Public/public-vocabs/2012Oct/0042.html [5] http://lists.w3.org/Archives/Public/public-vocabs/2012Oct/0044.html [6] http://schema.org/docs/extension.html -- Jindrich Mynarz http://mynarz.net/#jindrich
Received on Wednesday, 31 July 2013 13:20:06 UTC