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

Re: Nature of change in Schema.org

From: Jindřich Mynarz <mynarzjindrich@gmail.com>
Date: Thu, 1 Aug 2013 11:27:58 +0200
Message-ID: <CAE=8Bu9AkWiee6Nz3ydZQzdRtz_QgRhJ7jazGHHP3aEDmEFSfg@mail.gmail.com>
To: Dan Brickley <danbri@danbri.org>
Cc: public-vocabs@w3.org
Hi Dan,

On Wed, Jul 31, 2013 at 10:47 PM, Dan Brickley <danbri@danbri.org> wrote:
> We don't have very rigid policies. But in general, there's a strong
> bias towards additive changes, since any existing vocabulary that is
> being used is unlikely to completely vanish.

That's what I wanted to know. Understanding that it's highly unlikely that
a backwards-incompatible extension is adopted is crucial for developing
extensions. In the light of this we need to re-think our proposed extension
for the job market, since we don't want to provide conflicting guidance to
vocabulary users (for example, by changing the range of properties).



Jindrich Mynarz

The mechanism described in http://schema.org/docs/extension.html is
> pretty rough and minimal; there are some other techniques that we
> ought to also document. In particular, since schema.org was launched,
> two interesting things have happened:
> 1. W3C RDFa has been simplified as RDFa 1.1 (Lite), and looks a lot
> like Microdata in terms of complexity for publishers. However RDFa's
> data model deals more comfortably with the notion that some entity
> might be usefully described with two or more independently defined
> types. To approximate this within Microdata we added the slightly
> awkward property to schema.org "additionalType", since microdata
> assumes that all the main "itemtype"s for some item come from a common
> vocabulary. These changes improve the options for schema extensions.
> 2. Late last year, driven by the heavy work of integrating most of
> Good Relations into Schema.org, we implemented a new backend workflow
> for the site based on RDFa schema files.  Several of these (draft and
> live) can be found at
> https://dvcs.w3.org/hg/webschema/file/default/schema.org/ext
> This approach means that much of the site is now generated by scripts
> that consult an ordered list of HTML/RDFa/RDFS files. Currently the
> system understands basic notions of type/subClassOf, labels/comments,
> and our rather scruffy/wiki-like notion of range/domain
> ("rangeIncludes", "domainIncludes") associations between types and
> properties. Now that we also have per-property pages on schema.org I
> expect to revisit this machinery to add in a few more useful
> facts-about-properties, including provenance/acknowledgements,
> super-subproperty hierarchies, mappings to other schemas.
> So what does this mean for 'extensions'?
> For schemas that happily have an independent existence, RDFa is a very
> respectable mechanism for deploying them in data that is otherwise
> schema.org-based. This does not mean that all schema.org search engine
> products will necessarily 'understand' the extension, but that is also
> true of some parts of 'core' schema.org too. Being part of schema.org
> indicates that the search engines are broadly supportive of the
> vocabulary; not necessarily that they all have shipping products that
> directly use every type or property.
> An example of RDFa-based extension in instance data here:
> http://lists.w3.org/Archives/Public/public-vocabs/2013Jun/0028.html  :
> <div vocab="http://schema.org/" prefix="x:
> http://example.org/2013/person-extras123#" typeof="Person
> x:Minister">
>  <span property="name">Joan Smith</span>
> </div>
> ... this allows an extension type, "Minister" to be described properly
> in HTML/RDFa/etc, rather than leaving its definition to your
> imagination, as deploying http://schema.org/Person/Minister would do.
> For schemas aimed for inclusion, a similar approach (slightly edited
> schema files) gives configuration files that could ultimately be
> integrated into schema.org directly.
> I hope these quick notes help sketch how the technology picture has
> been evolving. They don't directly address the non-technical need for
> those of us at schema.org to more clearly communication our intentions
> around specific proposals and a workflow for progressing them - we
> will get there too! But I do believe the RDFa design at least allows
> for 'companion vocabularies' to be deployed alongside/within plain
> schema.org descriptions, without requiring everything be integrated
> immediately.
> Dan (allegedly on vacation)
Received on Thursday, 1 August 2013 09:28:47 UTC

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