Re: Should we adopt SKOS?

Aaron,

Great to hear the practitioners view.

I would suggest a extension to Dan¹s "we prefer [enumerations] to be
maintained 'out there in the Web' by expert communities." line, with: ³...
and recommend they are openly published and marked up using the Schema
vocabulary². Adoption of the SKOS types and properties into Schema would
obviously make that easier to achieve.  Which is the point I started from in
this thread

~Richard.

On 11/01/2013 19:20, "Aaron Bradley" <aaranged@gmail.com> wrote:

> A quick two cents on some of the recent threads from someone that uses
> schema.org <http://schema.org>  in markup pretty much daily.
> 
> I agree with all others that have voiced the sentiment that schema.org
> <http://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 <http://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 <http://schema.org>
> .
> 
> The spectacularly rapid spread (in relative terms) of schema.org
> <http://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 <http://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 <http://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 <http://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 <http://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 <http://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 <http://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 <http://schema.org>  base.
>> 
>> cheers,
>> 
>> Dan
>> 
> 
>