Re: Should we adopt SKOS?

A quick two cents on some of the recent threads from someone that uses
schema.org in markup pretty much daily.

I agree with all others that have voiced the sentiment that
schema.org(with the exceptions already noted, such as expressing a
date in
machine-readable format) should focus on "semantic mark-up of visible text."

But within those parameters, I for one - from a practical standpoint -
generally welcome the inclusion of external enumerations and controlled
values into schema.org.  The "practical standpoint" reason for this is that
non-specialist developers and non-technical stakeholders (like me) are far
more likely to use semantic markup where it is supported by a centralized
and well-documented vocabulary like schema.org.

The spectacularly rapid spread (in relative terms) of schema.org has been
driven chiefly by individuals and organizations that have been provided
with a clear value proposition for employing it:  that is, improved
visibility in the search results in the form of rich snippets, inclusion of
resources in specialty vertical engines (e.g. Google Recipe Search),
improved social snippets (e.g. Google+) and - increasingly - the promise of
some sort of presence in the Google Knowledge Graph, Bing Snapshots and
other semantically-fueled verticals.

The breadth of adoption that we've witnessed so far simply wouldn't have
possible without: 1) the clear value of using the vocabulary; 2) the
schema.org site, with its clear tables of classes and properties and
extensive examples; and, critically 3) a vocabulary that is broad and
detailed enough to be actually useful in marking up a wide range of web
resources.

All of this to say that while, in numerous situations, one may very
rightfully say that "this is best handled by employing an external
enumeration," or "this is a better candidate for an specialist extension
than incorporation into the core vocabulary," the richer the vocabulary
that is made available to practitioners like myself via schema.org, the
greater the likelihood that it will be employed.

That is why I and so many of my colleagues were thrilled to see things like
rNews and GoodRelations integration.  An Offer property from GoodRelations
like eligibleDuration is immensely useful for many working in ecommerce,
but the likelihood that an ecommerce site that had successfully figured out
to employ schema.org/Offer would additionally add GoodRelations markup to
use that property would be virtually nil.  The addition of GoodRelations
properties to this class made it more useful, and so more likely to be used.

Dan makes perfect sense when he says "we prefer [enumerations] to be
maintained 'out there in the Web' by expert communities."  And Karen is
doubtlessly correct when she says: "I have not seen in this discussion an
example of a value for which a schema.org-specific identifier would provide
capabilities that cannot be provided by an external list."  But consider
that the work of those expert communities and the benefits of the lists
they've created will never see their full potential if the work is
little-known and the lists little-used.

Schema of everything?  Bring it on!  I jest, but truly - from this
practitioner's point of view - more is generally better when it comes to
schema.org.

On Fri, Jan 11, 2013 at 9:45 AM, Dan Brickley <danbri@danbri.org> wrote:

> On the point from Karen, re " full metadata standard including control
> of the value space."
>
> Excuse me quoting myself, but we tried to set things out in
> http://blog.schema.org/2012/05/schemaorg-markup-for-external-lists.html
>
> a) controlled value spaces are a good thing and to be encouraged
> b) although we have a few modestly sized enumerations within
> schema.org, we prefer them to be maintained "out there in the Web" by
> expert communities
>
> >From the blog post,
>
> "The world is too rich, complex and interesting for a single schema to
> describe fully on its own. Withschema.org we aim to find a balance, by
> providing a core schema that covers lots of situations, alongside
> extension mechanisms for extra detail. There are many situations where
> the use of existing controlled vocabularies, standards and datasets
> would improve schema.org markup."
>
> The combination of a SKOS-lite model, alongside
> Wikipedia-Wikidata-DBPedia, Freebase hopefully allows for
> decentralised value space management, within a reasonably simple
> schema.org base.
>
> cheers,
>
> Dan
>
>