Discussions on Sports

The problem is that the schema works only for something organised like one of the "Big 4" American sports. At the moment, Sports Association is the only way anything vaguely organisation like gets linked in from the sport topic itself (which is why we have things like the PGA Tour), and also the only thing which contains a list of teams (which is why we have things like Serie A). This works for (eg) the NFL, where the organising body is the same as the league, but doesn't for most other things.

IMO, the schema needs some serious rethinking applied to it, but I haven't yet even tried to come up with a solution...

I'm against it being typed as an organization, and would like to see the type removed. In a number of sports, the governing body/organization is very different from the, sometimes many, leagues it organizes and oversees.

In the soccer commons the governing body is modelled as distinct from the league.

I suggest this type is split into two:

1. The governing body of a sports league. (a sports governing body - includes the organisation type)
2. A collection of teams who play games in an organised manner. (a sports league). This has a property linking it to a sports governing body

@zeusi yes, that's the correct definition. Thanks for finding the link.

@pak21 thanks for the support on this. I've been typing a lot of leagues as sport associations over the past few days, but it's annoying me that they are all being typed as organizations as well - which for the most part is incorrect.

@jeff I think it would be suitable to temporarily name the topic "governing body of league x" until the actual data is found.

Also type-able as Football League Season. I've just been going through some of those topics and typing them as such.

Unfortunately there are 900+ team participation topics which fit the pattern for delete.

To repeat my normal complaint here: sports exist outside North America, and this is very much a North American thing. What's the abbreviation for (say) Hampshire Cricket Club?

However, that doesn't mean this is a bad idea. Are you proposing a /type/text or a /type/rawtext, and what's the property documentation going to say?

They don't completely disregard abbreviations outside of the US, do they? A cricket website gave me the following abbreviations:

Hampshire Cricket Club = Hants; Nottinghamshire = Notts; Middlesex = Midd; etc. And Wikipedia led me to believe those abbreviations were fairly standard. I could be entirely wrong.

Not sure about /text versus /rawtext. Do you have a recommendation?

All you've got there are the standard postal abbreviations for the counties. It's nothing to do with the cricket club per se. Look at (eg) Cricinfo's recent results page and note the complete lack of abbreviations.

As for text versus rawtext, what are your use cases?

I think abbreviations are a pretty international concept.

Have you considered just adding them as a name alias? This would allow them to be found in many more contexts, at the expense of possibly not being able to distinguish them easily from other aliases (e.g. a team nickname).

If we do add them as a new property, I think the type should be /text. We should also consider whether teams are likely have multiple abbreviations used by different reporting services which need to be distinguished.

I was looking at Cricinfo's Hampshire page and they use the abbreviations in the top headlines (e.g. "Hants v Notts scorecard").

We are creating some NFL widgets and we need to be able to pull the teams abbreviations so we have something like this. So we'll need to be able to distinguish them.

This was Mike's original suggestion (but I thought that abbreviations were universal so suggested otherwise): "We should definitely store the team abbreviation in freebase somewhere. I think it's germane to NFL teams so, we should either create a NFL base with nfl_team as a type, or add a new type called nfl_team, with an INCLUDED type of /american_football/football team."

I'm almost certain NFL, MLB, and NBA abbreviations are standard across all [North American] platforms (I've never seen any differences in my maniacal fan history). I think that NCAA teams might vary a little bit more.

About the documentation I can only say that about "Sports Association" it says that the type "represents a collection of teams". Recently a few topics of sports federations with a single national team has been added, I know that the use of that type is an argument already discussed, but is a proper use?

I hope that someone will respond, and you can define the boundaries of the use of Sports League Championship, Sports Association and other related types.

You need to deal with a few different types of "points" units: 1) gymnastics (points out of 10.0), 2) diving (base score multiplied by degree of difficulty, and 3) decathalon, etc (points accumulated across multiple disciplines in the event).

I think short course swimming is often 25 *yards*, so be careful not to confuse them with 25 meter pool records.

It strikes me that the bulk of the record information is common with a sports event performance.  The only unique part to the record is the type of record and the sanctioning body (and the time aspect which will decay over time making it no longer a record eventually).

Here's a particularly tricky one: best bowling in a test match. The record is held by Jim Laker, for his 19-90 bowling against Australia in 1956. To explain that, it's getting 19 men out while giving away 90 runs - the record is sorted by number of wickets increasing, then by number of runs decreasing. (Any other cricket bowling records are going to have the same issue).

Not sure I can think of anything other records which need two numbers to model.

Is this type just intended for a single sports event?

Otherwise Football (soccer) would be another multiple-criteria record, in which league points is the first criteria followed by goal difference.

Given the hundreds of possible ways to measure sports performance, it's best to go for the float/dimension approach, otherwise we'd end up with loads of properties on the type to cover every different case.

The double criteria problem could be solved by making the float/dimension property non-unique, but you would end up with a CVT inside of a CVT and break the client.

For divisions, a division property would be easiest but end up creating a CVT within a CVT - which would not work in the client.

Lots to think about here. 

1. Turns out there are a lot of sports/events that use points (archery, shooting, heptathlon, etc.), so points clearly needs to be supported, although I don't think that the type of points particularly matters (float vs. int) is the only possible distinction I can see, which would complicate point 2, below.

2. I'm going to change the model to have only two properties for the record value: float and unit (where unit will be able to include points). 

3. @tfmorris -- you're right that most of these properties are related to a performance. This rather complicates the matter, but it might be worth exploring a performance model. One thing to note about performances and records is that a record can sometimes be set as a subset of a performance -- e.g. swimming records can actually be set during a leg of a relay, or even (I think) at the first split.

4. @sprocket: I'm not quite sure what the right terminology for the set of events that I had imagined this record type to represent is -- something like where the result of the event itself (i.e., that which determines the rankings) is the record itself -- so points in archery, time in swimming, distance in javelin, etc., rather than records that pertain to different aspects of a sport or performances therein. (Or, to tie this back to tfmorris's point, records that could anyway be recorded as part of a performance.) So I was figuring to exclude things like league points, number of tournaments won, number of home runs, number of consecutive pole positions, etc.  Not that the latter set wouldn't be good to model; I just think it's a different kind of record.

I'd like to be able to use sports records for all, not just current, records, which would enable all kinds of fun things (assuming we had the data for it), like plotting record values over time. But I see your point about not being able to tell whether a record is current from the athlete's topic. I don't see a good solution to that off-had; hopefully someone will have an idea!  (There's always the Boolean option, I suppose: a "current" property on the CVT.)

Area and Series are good suggestions -- that saves us from the annoying problem of having to create topics like "United States record". Also "country"; "age division" is a good suggestion, too -- are there other types of divisions that can be accounted for in records (other than sex?). I had been thinking about the Boston Marathon's wheelchair division, but then I realized that of course wheelchair marathon is really an event (well, two -- men's and women's wheelchair marathon).

I feel your pain about the seconds on the marathon results. It's several orders of magnitude less bizarre than isotopic half-lives being measured in seconds, though! :)

I think the only reason that gender is not included on the Olympic Event type is that nobody suggested it when we were designing the schema. (Although I could be wrong -- it was some time ago; I don't recall any discussion of it, though.)  We could certainly consider adding it as a property to the Olympics Event type, though.

In terms of generic or specific, it often depends on whether the schema is generic or specific. Because the Olympics schema is specific to one series of competitions, the Olympic Medal type can reciprocate "medal winners", and users will know with certainty that the athletes linked to it are Olympic athletes.  If the schema were for a general "Multi-sport Competition" model, there would need to be a general Medal type, and users would need to look at additional properties to know which particular competition the medals were for. So I guess for your purposes, an "Athletics Medal" (or something) would be necessary -- less specific than Olympics, but more specific than "Sports Medal". Although all would probably still use the same Gold, Silver, Bronze topics.

Having written that last paragraph, I wonder if a general Multi-sport Competition schema wouldn't be a useful thing to have. Otherwise I can see us trying to replicate the Olympics schema repeatedly for the Paralympics, Panamerican Games, etc., etc.

Yes, it would be nice to have a spot to put medal winners and competitors in championship type events, like World Track and Field Championship, or USATF Nationals.

It would also be great to have a place to enter someone winning the US Open without having to make them a sports team like Tiger Woods. 

Wrong thread! Over here.

Boy, do I look silly this morning.

Perhaps the explanation about my doubts on athletic events was not very clear, however, now I have done two different types:

Athletics discipline

Athletics event

I hoped to make only one, but I think that is an acceptable solution.
I tried to create a schema for championships (world and continental, indoor and outdoor, perhaps not for the national ones), even if it is almost a copy and paste from the Olympic Domain.
I would like to insert some data, but first if someone has some suggestions and proposals for changes please tell me.

You were clear. Maybe I wasn't :-)

I was hoping that we could come up with a solution for this that doesn't involve every domain having its own, basically identical, schema. At the moment, I'm essentially cloning the /olympics structure into /sport and you're cloning it into the Athletics base. Seems to me we should be able to avoid all that.

Here's a try at a general model: http://www.sandbox-freebase.com/view/sports/tournament_event_competition.

Lemme know what you think.

I prepared a my proposal, which you can see in my drafts types. With the type 'Multi-event tournament' should be possible to cover many events, similarly to the jeff's proposal. While the 'Multi-sport tournament' adds the details that I mentioned earlier. However, since I don't know whether is a good idea a so general schema, it is possibile to restrict its scope by merging these two types. A couple of examples.

Unresolved issue: it is not possible to add performance's details, for example the time that Jeremy Wariner took to complete his race.

A single event competion for teams.

@zeusi: Your schema looks pretty good, I think.  The medal/rank denormalization is too bad, but I don't really know how to do it better (short of making topics out of "fourth place", "fifth place", etc.)

Performance results are particularly tricky, for a couple reasons, and I really, really don't know what the best approach might be. One problem is that all the models only show the final rankings, rather than results for specific heats/matches/etc. The other, of course, is that the format of the results varies between competition types -- it can be a time, a number of points, or a score (the format of which can vary wildly depending on the sport). 

Isn't the defining characteristic here the fact that they're Competitors, as opposed to Athletes or Sportspeople?  That would allow you to avoid the discussion of whether golfers or skeet shooters are athletes.  It also might potentially allow you to reuse the schema in other times of competitions, e.g. team pie eating.

Can someone summarize which schema(s) is/are under consideration so I can get resynchronized with the discussion?

As for results, simple time and points cover a lot of ground.  Getting a schema which is robust enough to handle multi-set matches like tennis, would be adequate in my opinion.  If people can provide examples of sports they'd like to see covered, we can see how broad the schema needs to be.

Might be good for use with the soccer schema.

I've taken a quick look at the Multi-event Tournament schema (I think that's what's being proposed for promotion here?) and have some superficial suggestions: 

• Tournament event competition should include Event.
• Tournament event is confusingly named - I've i'm understanding the schema correctly, it's actually a discipline - should it not be called "Competition discipline" instead?
• Likewise for the "event" property on Tournament Event Competition.  This might be better renamed to "discipline" or similar.

@tfmorris: This is the base type for the schema under discussion: Multi-event tournament, although I see that there's a related Multi-sport tournament schema, which might be worth discussing (I just noticed it, so I don't know how different the two are yet).

@sprocket: I don't think "tournament event" is a discipline -- it's mimicking the Olympics type Olympic event, which represents a particular manner in which a discipline may be competed.  See Women's 400m freestyle for example -- what I think you mean by "discipline" would be the "sport" property of tournament event.

I don't think it dovetails into awards at all -- sporting medals are not awards (in the sense meant by that type, anyway).

@zeusi: I think the multi-sport vs. multi-event decision is one of the primary issues here. I rather like "multi-event" rather than "multi-sport" because it allows the same model to be used for World Aquatics Championships and World Rowing Championships.  I'm not quite sure what you mean by

"Anything not covered by more specific types (including single-event competition such as a single Slalom of Alpine Skiing World Cup)"

 Maybe you can expand on that a bit?

The Athlete question is important, too, obviously. One disadvantage of using a general "athlete" type for this is that lots of athletes won't have competed in this type of tournament, but might be involved in some other sort of competition, so a property on a general Athlete type might be confusing.

Ahh... a generic "any-sport competition" type would be the Holy Grail of sports schema modeling -- I was limiting my vision to the multi-sport/multi-event types (which is what I meant by "this type of tournament"). But if we can find a way to be more inclusive, that would be great.

In terms of having multiple types for multi-event vs. multi-sport, I like the idea of modeling these separately, but I'm not convinced that multi-sport tournament really has different properties: Competitors, Number of Competitors, Participating Countries, Number of Nations, and Venues all apply equally to multi-event tournaments (I think -- I'm open to being proven wrong). Arguably even "sport" could go on multi-event tournament, if you wanted to be able to say that the World Aquatics Championships are an aquatics tournament.

Oops. Clicked "save" too soon.  Going back to whether or not this model can generically handle single-event competitions, there are a few issues I can think of that we'd need to resolve.

1. Multi-event tournaments have an event/competition pattern that isn't replicated in single-event tournaments. E.g., it's meaningful to talk about "Men's 100m freestyle" (event) and "Men's 100m freestyle at the 2008 World Aquatics Championships" (competition), but there's no possible "event" topic for something like the Rose Bowl or PGA Masters Tournament. 

2. The various "country" properties (particularly on the Competitor/Country Relationship type) only really apply to international competitions where national teams compete. While lots of countries might be represented on the PGA Tour, the athletes aren't really representing their country the way they are in say the Davis Cup. (Hmm -- this is actually true of some multi-event tournaments, too, like many tennis championships.)  We could possibly just  document these properties as being particular to certain types of international competition.

Bump. Mikeschwe tells me that he's got a bunch of data he'd like to load into something like this schema -- he wants to put in past sporting event performances for prospective Vancouver Olympians.  If we could come to an agreement on the basic format of this schema, we could start with that to allow him to put his data somewhere, and flesh it out more fully at our leisure.  (Otherwise, he's threatening to create his own schema, which will only lead to suffering future data migrations.)

So I propose we go with "multi-event tournament" as a single type which combines the properites of zeusi's "multi-event tournament" and "multi-sport tournament" for now, and use his basic schema for events, competitions, and winners.  We could then continue to discuss whether or how to incorporate single-event tournaments and competition performances (heats, points, scores, etc.) without holding up the rest of the schema.

Thoughts? Random quibbles?

Mostly minor quibbles:

• A general lack of cotyping:
  
  • Multi-event tournament should include Event. Then "Venues" is just replaced by the "Locations" property of event, and this deals with recurring events as well.
  • Sport country should include country.
  • Tournament event competitor shoud include person.
  • Tournament team should include sports team.
• I'm unconvinced by the need to denormalise "Number of countries" and "Number of events" in the Multi-event tournament schema. "Number of competitors" may be worthwhile as it's going to be a lot harder to get the name of every competitor.
• No documentation (not really a minor quibble, but I understand it's not worth writing it docs until we've finalised the design)
• Inconsistent use of capitals ("Competitor/Country relationship" vs "Competitor/country relationship"). I know the rest of Freebase isn't very good on this either, but let's at least keep this schema consistent.
• In Sport Country, "participated" is spelt wrongly.

Included country, person and sports team in sport country, tournament event competitor and tournament team respectively. Fixed "participated". Event already included in Multi-event Tournament.

About use of capitals and names in general you can make the corrections just after the promotion (or tell me what to do).

"Number of countries" and "... events" don't particularly bother me -- they're somewhat denormalizing, but it's also certainly easier to input an integer than create all those relationships (especially for event, where new events might need to be created; countries will already exist, for the most part), and sometimes it's also much easier to find out.

I would actually recommend NOT including country (location, etc.) as included types of Sport Country. In international sports, there are occasionally non-country countries that compete (Unified Team, for example), which should not be typed as /location/country, but should still be treated as Sports Countries.

I'd recommend delegating Venues from the Locations property of "event" -- venues is fairly precise in meaning, and will encourage users to put in the names of sports facilities, rather than cities or countries. Let me know if you need help doing this.

Mere quibbles:

1. the property "Tournament Event / Tournament contested in" should be "Tournaments contested in"
2. the property "Sport Country /  Multi-event tournament participated in" should be "tournaments"

I've made the property delegated (turns out there's a bug in the schema editor, so delegation doesn't really work if you do it that way now, anyway).

Unless there are any objections, I'm going to have this schema promoted to the Sports commons. (I'll start documenting types and properties, too.)

Also, there is currently no simple way to get from "Pro Athlete" to the sport(s) they play.  And not all sports have draft picks.  We should make a pair of properties similar to the amateur one, to show pro athletes, especially where the sports in question don't have types of their own -- and there are far more of these than there are ones that *do* have types.

(Examples:  pro figure skating, skateboarding, etc.)

 This is a denormalisation, but no worse than eg. Profession vs Film Actor, Author, etc.

Not really :-) That would involve linking to a specific event, rather than the recurring events. To take the case of the FIVB, that runs 5 different indoor championships:

• Grand Champions Cup, in the year after the Olympics (male and female)
• World Championship, 2 years after the Olympics (male and female)
• World Cup, 3 years after the Olympics (male and female)
• World League, every year (male)
• Grand Prix, every year (female)

That would solve the immediate problem. On the larger scale, I still feel slightly we're jamming data into a model that doesn't really fit: eg there's no real way that that FIVB is the "league" of the World Championship, but at the moment it's the only way in the schema to note that the FIVB is the organiser of the World Championship.

This problem isn't unique to volleyball: exactly the same situation applies to say the FA Cup and the Football Association. Maybe there's just a confusion between "organising body" and "competition this is a championship of" in the Sports League Championship Event schema: for the big four American sports, this isn't a problem as (pretty much) the league is the same thing as the organising body, but I don't think this applies generally outside the USA.

All the above doesn't mean I've got a good solution to this yet, and I'm going to be off the net in a couple of hours until the 25th, so won't be coming up with anything before then...

We definitely need more flexibiity than one "league" : one championship, but I'm not sure off the top of my head the minimal set of necessary changes to propose.  I'll have a look at some of the other sports and see what I can come up with.

The tennis model is extremely minimalist (no link from tournament to sponsoring body, no use of Recurring event, etc) so I don't think it's a good one to follow.

There's a Tournament type in the Tsport domain (not sure whether the 'T' stands for 'Tournament' or 'Tadhg') which looks like it might have been the beginnings of something which would be helpful for a number of the cases that have been mentioned.

Note that it's not just 'exotic' rest-of-the-world sports which are affected.  I don't think you can accurately model standing tournaments like the Rose Bowl, Orange Bowl or NIT with the current schema.

I meant to say:

I'm loading seasonal win-loss records for NFL teams. I think it makes sense to add some schema to sports team, for wins, losses, and ties, in the form of a CVT of new type Sports Season Record, with integer properties for wins, losses, and ties, and a connection to a sports league season.

I would then migrate season records from /baseball/baseball_team/team_stats. I imagine that sports-specific team stats would go under sports specific types like /baseball/baseball_team/.

Thoughts? 

I'm sure it will. See eg http://www.sandbox-freebase.com/edit/topic/en/brazil_mens_national_volleyball_team for the first example I thought of. Also, I don't see this being a particular problem; I think it makes more sense to have this on the generic Sports Team type, rather than a new "Sports Team that plays Seasons" type.

Other than that, my only question would be whether it should be "ties" (US centric terminology) or "draws" (British/Commenwealth centric terminology).

Thanks for the comments. I went ahead and created the same schema from Sandbox on production in Sports Team.

Hopefully, we won't have to become get too synthetic to create seasons out of time periods just to fit the model.  If that becomes painful, we can revisit this discussion.

[ Cross-posting this a bit ]

Seems like a good idea to me - there's a definite disconnect at the moment between (eg) how the United States men's volleyball team are marked as the winners of the World League 2008, but not of the Olympics 2008.

Copying my comments from the bug here:

Two properties on /base/fight/sports_official_tenure should be unique: sports_official and sports_association. Otherwise the model seems pretty good, as long as the link to sports association were reciprocated.

I'm not really sure that the pro wrestling data belongs in this type, though, since pro wrestling isn't really a sport, and the job of an "offical" in pro wrestling is different than that of, say, a boxing or MMA referee.

ah, k made 'em unique.

//I'm not really sure that the pro wrestling data belongs in this type, though,

hah, ya never thought of that. agree. I'll try to move em to the wrestling base. i left dan a message.

sry, shoulda been following the jira.

cheers

There is a Competition type that I had set up for this very multi-purpose use.  It allows for simply Competitors and Winners.  Used with instances of recurring events it can capture the competetors and winners.  I've used it for Miss America, the Bassmaster Classic, the Kentucky Derby and even hot dog eating contests. 

Many competitive events will need specific modeling - the Americas Cup gets pretty complex - but with the Competition and Events types used it can start capturing the esentials on anything.

Take a look at the Tour de France now.  I added the instances from 2000 to 2009 and typed each as a Competition.  Now one can add the comepetitors and winners.

Thoughts?

Jon

That's what I was looking for!

It would be good to look at:

• Olympic Medal Winners

Agreed that may be easier approach for food vendors (with geo, can even search for restaurants contained within stadia)

As for the others, they're applicable to any size arena/stadium.  Broader set of choices available (i.e., surface can be grass, artificial turf, ice, wood, etc.).

I'm just thinking of something like the community leisure centre I used to attend back home.  It had an indoor swimming pool, indoor squash courts, outdoor tennis courts, and outdoor basketball courts.  What playing surface would you put for that?

Or the one at my school, which was also used by the public at weekends: indoor squash and basketball courts, outdoor field for football/cricket/etc, outdoor tennis courts, etc.

Many smaller sporting facilities, in my experience, support multiple sports in a mix of indoor/outdoor areas.  It's only the big stadiums where you really have a single playing field with a known surface and roof style.

Agreed ;)  I suspect this is an older type, just looking at it.

May I offer you the advice we offer most people who have suggestions/ideas for improving a model, and suggest that you create a version of it in a personal domain, and then we can review it?

The only reason there isn’t is that no one has been interested enough to make it. So go do it! Make a private domain of your own and start modeilng it. Post here and invite others to join in. When you think it’s done, ask for it to be promoted into the data commons.

You may find the data modeling mailing list helpful both in your modeing efforts and in recruiting others to help.

A golfer is not necessarily a professional athlete - there are amateur status golfers, albeit most people are probably most interested in professional golfers.  I would be inclined to say that we shouldn't have pro athlete as an included type of golfer.

Fair enough. I was under the incorrect assumptions that:

1) Only pro athletes are assigned these sports player types in Freebase, and

2) Most sports player types have "Pro Athlete" as an included type.

I can see now that both are false. So, I agree, no "Pro Athlete" as included type. :) 

Interestingly, the only type I can find that does have "Pro Athlete" as an included type is "/cricket/cricket_bowler". There are no amateur cricket bowlers? ;)