- From: Martin Alvarez-Espinar <martin.alvarez@fundacionctic.org>
- Date: Fri, 24 Nov 2017 10:46:21 +0000
- To: Ivan Kachkivskyi <ivan.work.mail@gmail.com>
- Cc: Andy Robinson <andy@reportlab.com>, Martin Alvarez-Espinar <martin@w3.org>, Nicolas Launois <nicolas.launois@european-athletics.org>, public-opentrack <public-opentrack@w3.org>
- Message-ID: <CAL8AgZSC6jqJ_QMCKGM829OCyoN7ZrdokNm+MS0UCQk746KfZg@mail.gmail.com>
Hi Ivan, Although we use this approach, we still would need a common taxonomy that maps all terms to guarantee interoperability. So we could be able to design *universal* tools to search/filter/aggregate/manage competition calendars automatically. Best, Martin On Fri, Nov 24, 2017 at 9:55 AM Ivan Kachkivskyi <ivan.work.mail@gmail.com> wrote: > Hi all, > > Maybe it is possible to benefit when each National Federation could > describe it’s own local structure under some section. This can be an > example of decentralized structure maintained by local representatives. So > this is left on local level, and no need to spend time for describing it by > EA. How do you think? > > > > *--------------------------------* > > *Ivan Kachkivskyi* > *Official Ukrainian Statistician, **ATFS Member* > E-mail:* ivan.work.mail@gmail.com <ivan.work.mail@gmail.com>* > E-mail:* ivan@ivan.org.ua <ivan@ivan.org.ua>* > *www.ivan.org.ua <http://www.ivan.org.ua> * > > > > *From:* Martin Alvarez-Espinar [mailto:martin.alvarez@fundacionctic.org] > *Sent:* Thursday, November 23, 2017 12:21 PM > *To:* Andy Robinson <andy@reportlab.com> > *Cc:* Martin Alvarez-Espinar <martin@w3.org>; Nicolas Launois < > nicolas.launois@european-athletics.org>; public-opentrack < > public-opentrack@w3.org> > *Subject:* 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 > <https://maps.google.com/?q=Olympisch+Stadion+2&entry=gmail&source=g>", > > "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 > > >
Received on Friday, 24 November 2017 10:46:56 UTC