Re: Competition Types [was Re: Meeting 22 Nov (09:00 UTC)]

Hi Andy,


> > What about:
> > * International Area (several countries and territories)
> > * National (just one country)
> > * Regional/Local (can include all what IAAF refers to 'territory')
> > ?
>
> This geographical taxonomy seems unnecessary to me, a possibility for
> endless scope creep, and I do not believe anyone ever came up with a
> single "correct way to do it".  I worked for 6 years for Hilton group
> who had a 9-level hierarchy of tourist information that needed endless
> discussion and policing, and I don't think this will be a good use of
> our time.
>
>
But, apart from EEA, national federations follow a similar approach,
enabling filters on their calendars. For instance:
* ESP (international, national)
* IRL (international, national, provincial, county, club, open)
* FRA (international, regional, inter-regional, departamental, inter-clubs)
* CZE (foreign, national, regional…)
…


> Taking Martin's last race, I don't personally care how you describe
> "Mitcham Common, London", and whether its classified as part of
> London, or Surrey, or the "Royal and Ancient Geographical County of
> Surrey for Sporting Purposes" (yes, that exists and it matters).  When
> exchanging lists, we just want to know where it happens.  So why not
> use...
>
1. Latitude and Longitude, if we have it!
> 2. If not, A piece of text you can pass to Google Maps or other
> geocoders. An address or postcode of a track or stadium name are even
> better.  Given this info, we can derive the
> latitude/longitude/altitude
> 3. The country, which is usually fairly clear.
>

What you mention here is the *geographical location* of the venue, which is
currently described in [https://w3c.github.io/opentrack-cg/spec/model/#place].
There you can find the information you mention. See the example published
on the doc:
{
    "name": "Olympic Stadium Amsterdam",
    "geo": {
        "latitude": "52.343417",
        "longitude": "4.854192",
        "elevation": "123.93"
    },
    "map": "http://example.org/map",
    "address": {
        "streetAddress": "Olympisch Stadion 2",
        "addressLocality": "Amsterdam",
        "postalCode": "1076 DE",
        "addressCountry": "countrycode:NLD"
    }
}


> Once you have this, Google and many other OpenStreetMap tools can tell
> you the administrative boundaries, or search by proximity.  Below I
> show two lines of code to do it.  Anyone building a database of
> competitions in their country can use these libraries to "get it right
> for them".  They may be interested in political or sporting boundaries
> and they can be different.
>
> So let's publish the minimum, and maybe offer tutorials and tools on
> how to extend it.
>
>
As always, all the properties are optional, depending on the information we
manage.


> With "level of coverage" I think you are also skirting into different
> questions over jurisdiction, not location.  These are best answered
> by...
>

Right. This is the purpose of the classification based on (international,
national, regional, etc.) proposed above.


>
> 4. Who is organising it?    We are developing organisation codes, but
> an org name or link to their website would do.
>

There is a property "organizer" already (it could be a person or
organisation)


> 5. Which body or bodies are licensing it?  There may be permits from
> national body, European Athletics, IAAF
>

+1 -> I think this is what Nicolas called "label". Maybe an additional
property like 'licencedBy' or extending the one we already have,
'recognizingAuthority'.


> 6. is it part of a larger series or league?
>

This can be modeled with the types of competitions defined by the BBC
Ontology (KnockoutCompetition, Match, LeagueCompetition, etc.)


> 7. Does the event have its own website?
>

This is already included by the property 'url'.


> 8. Is there a restriction on who can enter, or is it open to anyone?

This could be descriptive text.
>
>
There is already a field for this:
* 'entryRequirements'.- Requirements to take part in a competition.


>
> Geocoding is trivial in all languages.
> >>> import geocoder
> >>> g = geocoder.google('Mountain View, CA')
> >>> g.latlng
> (37.3860517, -122.0838511)
>
>
Definitely, the most geo information we have, the better. We all know the
precision issues of geocoding when information is missing.

Best,

Martin