Re: YourSports vocabulary extension

+100 for the direction Gregg is taking this proposal.

Personally I'd prefer the use of enumerations over specific sub-classes
because I feel if we were to take the subclasses direction we'll be opening
up Pandora's box. Take Organization and all of it's subclasses for example.
This class is well on its way to becoming a never ending expanding list
because someone somewhere one day decided it would be a good idea to add
specific subclasses to it. Sub-classes which don't offer any new properties
and IMHO only are starting to pollute the overall schema. And because of
that decision also has little counter arguments to any request for a new
subclass. To quote Aaron Bradley: "in for a penny, in for a pound", seems a
valid statement in this context.

I fear that if we don't take the enumeration route the entire Sports
proposal will only turn out to be one giant headache as well.


In the original thread Jason Douglas wrote: "Whether implementors choose to
use Freebase, DBpedia, ESPN or any other source for those enumeration
references is a separate question and one that I'm not convinced even needs
to be answered by" (

This is a statement I can't agree with. Maybe for 'insiders' it's clear
when certain enumerations are better than others but the general web
developer has absolutely no clue. And to be completely honest half the time
I don't either and I've been reading every thread on this list for the last
year. Also just look at all the confusion 'sameAs' and 'additionalType' are
generating outside of this mailing list, and these properties are brand
new. Imagine the chaos we'll get if an even broader audience starts to
implement it. The issues that are arising with the Sports proposal
apparently are beyond the scope of the proposal itself.

Without a clear statement/explination from the sponsors of about
how to choose the 'right' enumeration(s) and even more importantly, why one
would even bother to go to all that trouble to find and implement them
(because it IS very time consuming for the every day webdeveloper) I don't
see a very big future for any form of enumeration or external reference.
Not for 'sameAs' and 'additionalType' nor for Classes which possibly can be
served greatly by pointing to external sources. Especially from the
sponsors point of view, after all it helps them understand the data so they
can serve their customers better.

So some sort of a 'ROI' or an idea about how the sponsors intend to
process/use this type of data IS needed. For website owners to be able to
make an informed decision on whether they should make the time, resources
and money available to go so far with their markup. There has to be some
sort of prospect what's in it for them. Or the vast majority of the world
will never bother and keep on seeing see it as a waist of their time
because they don't see the added value (and yes, that's my everyday
experience when advising as an SEO Consultant). Just look at the percentage
of markup there is in the search for Rich snippets and compare that to the
percentage of that is used for extensive markup purposes. It's
out of balance

So please let's not overlook this side of and let's not say this
isn't the right platform to discuss this, since there is no other platform
to discuss this. itself is driven by commercial organizations.
Let's therefor also stop to think about the (financial) implications of
what we all do/propose here at the public vocabs, for those who have to
pick up the bill for implementing it. Let's do stop to think and discuss
about how to get the rest of the world to consider marking their data up
extensively or else who are we doing this all for?

I therefor also agree with Gregg when he said: "this may be the right time
to have a discussion on how extensible is meant to be." (

I would happily participate in a general discussion about this (as I know
others would as well). And it would be of incredible worth if the sponsors
of could make any sort of statement in regards to the return
value of marking up outside of nice snippets and undergoing the hassle of
adding external enumerations and references. Which I'm sure will also
greatly help the discussion about the Sports proposal.

On Wed, Feb 19, 2014 at 10:55 PM, Gregg Kellogg <>wrote:

> To provide some more specific contrast to the previous Sports Vocabulary
> Proposal [1], I've posted information on the type hierarchy I've been
> developing for [2] (also on the WebSchemas/Sports wiki page
> [3]).
> Although much of the vocabulary supports YourSports' specific business
> model, the class hierarchy is broadly similar to that in the previous
> proposal. Where it really breaks with it, though, is in the use of
> enumerations when describing a SportsTeam, in contrast to specific
> sub-classes for each sports discipline, and in the use of a Contribution
> class (type of schema:Action) to describe the roles played by individuals
> in an organization or event. This is in keeping with previous comments I've
> made to that proposal.
> This is offered to help forward the dialog towards the creation a
> collaborative Sports Vocabulary proposal, is not intended for straight
> adoption. There have been a number of comments by myself, as well as
> others, on the problems with over-relying on subclassing when extending
>, or any other vocabulary, particularly when it comes to adding
> information that is better expressed as enumerations in a common namespace
> (e.g., DBpedia). In this proposal, it goes for specific definitions of
> different types of sports teams, the roles played by individuals on that
> team, and the organization of that team using a hierarchy of events
> (seasons, games, etc.) as well as the membership of that team within some
> other organizational hierarchy (league, division, ...).
> More specifically, I would be happy if these principles were used in a
> future version of [1].
> Gregg Kellogg
> P.S., contributions are my own, and I have a consulting relationship with
> YourSports. YourSports is a social network built on the relationship people
> have with sports teams, and each other, although it's in a closed beta at
> this point. Ask me if you'd like an invite.
> [1]
> [2]
> [3]

Received on Saturday, 22 February 2014 02:21:19 UTC