Opentrack

open issues on GH

martin: I see you've replied to some of the issues -- much appreciated
... I have read your proposals
... I think it's good to have the conversation on GH
... About age categories ( https://github.com/w3c/opentrack-cg/issues/5)

Andy: It's complicated; it depends on the event.

<martin> present Andy Weir

<martin> present Andy Robinson

Andy: eg, if you're considering results *after* the event, you'd look at birth dates
... we have this extra field we introduce on our DB: "is this suitable for rankings?"
... eg, if wind is too strong, or if the measuring of the fields isn't accurate, that result would not count towards rankings
... You cannot say "this person is permanently x years old -- all the time, everywhere"
... All this is worth a little research
... If you start tagging people on DBs, that may never end
... About the process: how to suggest small changes, or comment on parts of a document?

<martin> tripu: For those small changes, I would suggest creating a new branch with all comments

martin: that's helpful
... In that way, we could have contributions from all registered members

Andy: In several places you have "more cases and examples" placeholders
... We could fill those in later; on a separate section, so we don't distract readers too much

martin: I have examples (partial, raw) on separate files
... that was my own approach, but we could improve and change that
... I'll continue, eg modelling relay races
... I want to understand what's missing from there
... Yesterday, Andy told me it's important to have all legs of relay races annotated with partial and intermediate times, and also the position
... I agree -- I'll work on that

Andy: OK. We should adapt that, and make something for splits, too.

martin: According to the model, we can represent results of relays, only not intermediate results (legs).
... It's important, and it's missing right now.
... I've been thinking about the proposal of having a subset of the vocabulary to share with organisers/partners
... There's something we call "application profiles" -- we can create those depending on your tools and your specific needs
... Is that a good approach?

Andy: Sure. It does not matter so much, because all you're writing is converging.
... As long as we're choosing sensible variable names, later in the summer we can decide "these are the ones we need for this"
... Maybe it's easier to wait and see what we are exchanging, then decide the subset.

martin: I'd like to emphasize that the goal of the model is to be both flexible and scalable
... So we'll be able to extend it, depending on needs
... Every single property is optional -- thus, very flexible.

Andy: We said the primary goal is to exchange results after the event has happened.
... But it's also important for us to describe the structure of the competition

[Andy shares his screen]

Andy: there are rules and restrictions; combination of distances, ages, organisational needs, etc.

[Andy shares the intricacies of organising a particular championship]

martin: I think this could be represented using our model, eg using iCal (iCalendar) , also schema.org:Events

Andy: About times: it's common times change because of DST happen while now and the moment of the event, or because of different TZs
... We use text fields now; it's a nightmare

martin: Anyway, this could be fixed by your tools, right?

Andy: absolutely. People would be confused, though.
... Perhaps if we add a section on "programme planning"...
... Also: who is allowed to compete in each event? Do we need to codify this?
... eg, sometimes there's a clubs championship, but guests are allowed too
... a way to say: "this competition is for X and Y"

martin: Good point.

Andy: another example of restrictions: limit to max distance per age
... eg, young children cannot run long distances
... Some of these rules are established by different bodies
... how to flag results as "organisational record", "club record", etc
... We'll do a screenshot, and try to model these too.

martin: Let's continue on GH's open issues
... These suggestions look perfect to me
... That's all from me -- anything else?

AOB

Andy: Not really. The next couple of weeks are hectic for us.
... Our most important date is May 10
... So we don't have that much time to think about documents until then
... Once that's over, we'll have plenty of results to share with you
... So if you want to slow down a bit, that's fine with us.

martin: That's fine
... We can skip the next meeting

Andy: you can keep up the rhythm.

martin: OK, so we'll keep the next meeting anyway.

[Andy & Antonio talking about modern presentation of JSON results, backend, etc]