W3C home > Mailing lists > Public > public-vocabs@w3.org > July 2013

Nature of change in Schema.org

From: Jindřich Mynarz <mynarzjindrich@gmail.com>
Date: Wed, 31 Jul 2013 15:19:17 +0200
Message-ID: <CAE=8Bu-kdnVsWE5CrFttRjiMoOhPY_73zVD_GOhv53_+D3ifjw@mail.gmail.com>
To: public-vocabs@w3.org
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:29:28 UTC