See also: IRC log
vivien: Hello and welcome
... Why the need for this data from W3C?
... people will be able to build more things with this data;
and also it's data we want to give back to the community
... It's a public API; tested in the last weeks/months.
... It returns data in JSON format; ready to test at
api-test.w3.org.
... Follow our project on GH; we keep track of issues
there
... The code itself is *not* on GH; as it's closely related to
some of our internal tools
vivien: You can get info about
specs, groups, orgs and users right now
... You can get information from, eg invited experts, and all
users who are participating in WGs
... http://www.w3.org/2015/10/web-api-tpac/?full#api-sample
... here's a simple example: the HTML5 spec
[vivien going through all the properties/fields on the slide]
vivien: Among other things, we have links to related versions of a spec, eg previous version
http://www.w3.org/2015/10/web-api-tpac/?full#apikey
vivien: You can create your
personal API keys from your W3C user profile page
... keys can be revoked, regenerated, etc. Also, they may or
may not be associated to a specific origin.
http://www.w3.org/2015/10/web-api-tpac/?full#apikey2
[vivien showing an example of real JSON returned by the API, and following links to new pieces of information]
[vivien following some of the links on http://www.w3.org/2015/10/web-api-tpac/?full#4 ]
vivien: name of the group, its
type, list of chairs, team contacts, participants...
... info about the charter(s) of the group: extension, IPP, URL
to join the group...
https://api-test.w3.org/domains/41381?apikey=dr7ri39me1kckkkk44sk8400sw4cgc4
vivien: Domains: page of the domain, groups it "contains", resources (repos, channels, lists)...
https://api-test.w3.org/affiliations/9826?apikey=dr7ri39me1kckkkk44sk8400sw4cgc4
vivien: Organisation: home page, participants (info that is already publicly available) groups that this company is involved on...
DavidClarke: does this allow "join" queries, eg participants of group X who are also in group Y?
vivien: Let's talk about that later
http://www.w3.org/2015/10/web-api-tpac/?full#8
vivien: Two options for authenticating users of the API.
http://www.w3.org/2015/10/web-api-tpac/?full#9
vivien: we have pagination, to
avoid answers that are too long
... More about all this on the GH site.
... Coming back to David Clarke's question...
... right now, you'd have to make 2 queries, and then merge the
results.
... For the i18n group, for example, you get a list of
participants, each with a URL with details
... if you were to follow those links, that would be already
~76 requests.
... To avoid that, and to get more information from just one
request, we have the "embed" parameter
... Also, the pagination might help to reduce the # of
requests.
... The API is JSON, so probably you want something else on top
of that
... We have written Apiary for that
vivien: It's a declarative JavaScript library; the project is on GH.
http://www.w3.org/2015/10/web-api-tpac/?full#apiary-sample
vivien: we specify our API key,
and the ID of the (group|domain|user|whatever) we need...
... then put "placeholders" where we need the actual data.
http://www.w3.org/UbiWeb/Overview_tmp.html
vivien: This example shows how to
use Apiary to populate info about a particular domain...
... on this page, the list of activities, with links, comes
from the API.
... On GH you have a link to the API documentation: parameters,
how to use the keys...
... Some people are already using the API in the real
world.
... For example, GH contributions may be checked against the ID
of the committer, using the API.
DavidClarke: I haven't seen info about translations, eg of specs.
ted: We don't have info about those translations.
DavidClarke: By definition, the i18n WG has a lot of material translated. If my preferred language were, eg, Japanese, I might want that if it's available.
vivien: All this info is coming
from our DB; all that I've shown now -- we only have the
English version; no translations.
... as far as the DB is concerned, there's only English.
DavidClarke: Too often, we present the English version and expect that to be "good enough" [for all users].
ted: I'm not against i18n, but this is an early version and...
DavidClarke: I'm fully aware. I'm saying it's easier to embed support for i18n at this early stage, as opposed to doing that later.
vivien: I'll have to look at how to do that in JSON. Any pointers?
DavidClarke: BCP-45...? BCP-64...?
vivien: Not those ones; if you
could send that to us later.
... Who would be the best person as a contact in the i18n
WG?
DavidClarke: r12a.
... I come across so many projects where encoding and language
were not taking into account from the beginning.
DavidClarke: So we don't have info about languages in the DB?
vivien: no that I'm aware of. There might be some, but we assume it's English.
ted: We'll need to keep that
information, because... well, machine translation isn't
good.
... We get people who enter their name localised, using
non-English chars, etc.
... What would be the right way to deal with those cases?
[DavidClarke going through various examples of person names that are difficult to infer, in terms of language.]
[David & Vivien looking at some localised testimonials from members; there we do know the language...]
[Vivien & David discussing the benefits of i18n in relation with the API]