W3C home > Mailing lists > Public > public-opentrack@w3.org > November 2017

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

From: Martin Alvarez-Espinar <martin.alvarez@fundacionctic.org>
Date: Fri, 24 Nov 2017 10:46:21 +0000
Message-ID: <CAL8AgZSC6jqJ_QMCKGM829OCyoN7ZrdokNm+MS0UCQk746KfZg@mail.gmail.com>
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>
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

This archive was generated by hypermail 2.3.1 : Friday, 24 November 2017 10:46:57 UTC