- From: Phil Archer <phila@w3.org>
- Date: Fri, 19 Feb 2016 17:29:59 +0000
- To: Public DWBP WG <public-dwbp-wg@w3.org>
Today's minutes are online at https://www.w3.org/2016/02/19-dwbp-minutes.
Thanks to Dee for running an ad hoc meeting so efficiently. We're
zeroing in on the solutions...
A text version of the minutes is provided below for convenience.
Data on the Web Best Practices Working Group Teleconference
19 Feb 2016
[2]Agenda
[2] https://www.w3.org/2013/dwbp/wiki/Meetings:Telecon20160219
See also: [3]IRC log
[3] http://www.w3.org/2016/02/19-dwbp-irc
Attendees
Present
PWinstanley, Caroline_, annette_g, deirdrelee, phila,
antoine, laufer, BernadetteLoscio, RiccardoAlbertoni,
hadleybeeman
Regrets
Chair
deirdrelee
Scribe
phila
Contents
* [4]Topics
1. [5]SDW Call
2. [6]API BPs
3. [7]DQV
4. [8]Zagreb
* [9]Summary of Action Items
* [10]Summary of Resolutions
__________________________________________________________
<deirdrelee> trackbot, start meeting
<trackbot> Meeting: Data on the Web Best Practices Working
Group Teleconference
<trackbot> Date: 19 February 2016
<PWinstanley> +1 to the idea of reporting on the joint meeting
deirdrelee: Agenda bashing
<scribe> scribe: phila
<scribe> scribeNick: phila
<deirdrelee> PROPOSED: Approved last week's minutes
[11]https://www.w3.org/2016/02/12-dwbp-minutes
[11] https://www.w3.org/2016/02/12-dwbp-minutes
<deirdrelee> s/approved/approve
<annette_g> +1
<Caroline_> +1
<deirdrelee> +1
+1
<PWinstanley> +1
<antoine> +0 (was not here)
<laufer> please, could anybody print the link wo webex?
<laufer> +1
RESOLUTION: Approve last week's minutes
[12]https://www.w3.org/2016/02/12-dwbp-minutes
[12] https://www.w3.org/2016/02/12-dwbp-minutes
<deirdrelee> Webex:
[13]https://mit.webex.com/mit/j.php?MTID=m0642b1c7ce49018a07ffe
c17ea136ae6
[13]
https://mit.webex.com/mit/j.php?MTID=m0642b1c7ce49018a07ffec17ea136ae6
SDW Call
<laufer> thank you deirdre
Caroline_: recapped on the call with SDW on 17/2
... They're using our work but of course are more focussed on
spatial
... Some new issues were raised as a result, especially around
the API BP.
laufer: I have raised an issue about APIs...
<laufer> [14]https://www.w3.org/2013/dwbp/track/issues/242
[14] https://www.w3.org/2013/dwbp/track/issues/242
issue-242
<trackbot> issue-242 -- APIs on the Web (for publishing Data on
the Web) Best Practices -- raised
<trackbot> [15]http://www.w3.org/2013/dwbp/track/issues/242
[15] http://www.w3.org/2013/dwbp/track/issues/242
laufer: From the coversdation, I have a worry about how we are
doing things.
... We have a thing about the data, and anotehr about how it
will be publsihed. This sounds like 2 audiences, one is
developers
... So my issue is that as well as data on the Web, we are now
publishing BPs for developing APIs.
... They talk about osme operations that would be nice to have
in this API and so we're starting to define a profile for APIs
and I don't think that's in our scope
BernadetteLoscio: I agree that we shouldn't provide a lot of
detail about how to develope APIs, but it is in our scope to
sat that APIs are one of the possible ways to acess data,
That's why they're in the doc under data access.
... So yes, we should discuss how deep to go in this BP.
... I was thinking that in our doc, we have more general
guidelines that groups in more specialist domains can take
further
deirdrelee: How was the call overall?
<antoine> phila: it was a very useful discussion
<antoine> ... they'd like to repeat wednesday
phila: Gives general overview - v +ve. They want to repeat it
this week.
BernadetteLoscio: GOod call from the POV of the editors
... After the meeting, I was left thinkinbg that it's not
entirely clear what we should propose as a general subject.
... They were asking whether we were going to provide
guidelines about data precision or not
... So maybe we should make it clear how other groups can build
on what we've done.
<antoine> Issues about precision and granularity after the
discussion: [16]http://www.w3.org/2013/dwbp/track/issues/240
[17]http://www.w3.org/2013/dwbp/track/issues/241
[16] http://www.w3.org/2013/dwbp/track/issues/240
[17] http://www.w3.org/2013/dwbp/track/issues/241
<laufer> +1 to the idea of extending for specific domains
antoine: Something that was discussed - there was some useful
input for BPs on vocabularies
<Zakim> phila, you wanted to talk about precision
phila: Went on about precision and accuracy
... many decimals when they're not warranted.
annette_g: The accuracy/precision issue is one we come up
against. We do have data that is that accurate and precise. We
can't say don't be more accurate
... But we might consider saying that the precision should be
consistent with the accuracy of the measurememt
... But how much of this is relevant to data on the Web?
... I'm not sure whether we need to addrress it in our doc
PWinstanley: Almost as a rebuttal - when you're talking about
BPs, if you don't mention some things that may be motherhood
and applie pie, people may say it's irrelevant.
... It's a broad brush doc with a W3C hallmark. We may not want
to go on about it, but a pointer to something about accuracy
nad precision/quality is a good thing to include I'd say. Put
it on the radar for anyone new to the area
<hadleybeeman> +1 for addressing that in data quality
annette_g: I can think of putting that into the data quality
vocab, reporting the precision etc.
... We're in danger of putting in everything.
PWinstanley: So yes, I agree, put it in DQV if it's not there
already
deirdrelee: If sopmeone wants to suggest a spedcific place to
put it in gthe BP doc and/or the DQV?#
phila: I did raise it as an issue, it will return
API BPs
<annette_g> I would also say that the folks that I work with
don't generally need reminding how to use numbers correctly.
deirdrelee: We wanted to reserve some time for the DQV today -
so if you have something, we'll include that.
... But BernadetteLoscio - what shall we discuss around APIs?
BernadetteLoscio: In the current version of the doc, Annette
said we had some changes in the BP after we resolved to
publish?
... So which ones do we need to look at?
<deirdrelee> [18]http://w3c.github.io/dwbp/bp.html#dataAccess
[18] http://w3c.github.io/dwbp/bp.html#dataAccess
BernadetteLoscio: We need to have an agreement on the set of
BPs that we have now.
... We currently have 7 BPs on data access
... and 3 or 4 on APIs
... So for me the section is a little confused, and we still
don't have consensus in the WG.
... Don't know how to proceed.
<BernadetteLoscio>
[19]http://w3c.github.io/dwbp/bp.html#dataAccess
[19] http://w3c.github.io/dwbp/bp.html#dataAccess
<Caroline_> [20]http://w3c.github.io/dwbp/bp.html#dataAccess
[20] http://w3c.github.io/dwbp/bp.html#dataAccess
annette_g: This section...
[21]http://w3c.github.io/dwbp/bp.html#dataAccess I was going to
suggest that it would be better if BPs were more gathered
together on this.
[21] http://w3c.github.io/dwbp/bp.html#dataAccess
BernadetteLoscio: BP10
<BernadetteLoscio>
[22]http://w3c.github.io/dwbp/bp.html#provideVersioningInfo
[22] http://w3c.github.io/dwbp/bp.html#provideVersioningInfo
BernadetteLoscio: Shouold be about versioning of APIs
<deirdrelee> Data Access BPs: Best Practice 20: Provide bulk
download Best Practice 21: Use Web Standardized Interfaces Best
Practice 22: Serving data and resources with different formats
Best Practice 23: Provide real-time access Best Practice 24:
Provide data up to date Best Practice 25: Document your API
Best Practice 26: Use an API
BernadetteLoscio: I'm not sure why this one is here...
annette_g: versioning is not only about APIs
BernadetteLoscio: We have BP8 on data versions, 9 on version
history, and then the one on API versioning
<hadleybeeman> q later
BernadetteLoscio: So maybe this is weird. Not sure why this BP
is here.
<Zakim> hadleybeeman, you wanted to talk about (at some point)
device APIs, browser APIs and language confusion
laufer: This is what I was talking about. We have 3 Bps for
APIs
... BP25 says document your API. So we're talking about
metadata for APIs, so it's an instance of our document for
documenting our document
... BP10 is about versioning APIs, it's similar to versioning
data. I think we have a lot of things to say about APIs. My
worry is that we'll try and cover too much.
<BernadetteLoscio> BP about APIs: Best Practice 10: Avoid
Breaking Changes to Your API, Communicate Changes to
Developers, Best Practice 25: Document your API Best and
Practice 26: Use an API
annette_g: I wanted to touch on the mention of API
documentation as just anotehr kind of metadata that we need to
do. I'd say it's different as an API needs infor for a user to
know what to do
... So there's this extra info that's needed about the calls
you need to make. That's not metadata, tjat's info about the
API's behaviour
BernadetteLoscio: I was taking a look in the doc. We have 3 Bps
10, 25 and 26 about APIs. Versioning, documentation and generic
"use an API"
<annette_g> there are four: 10, 21, 25, 26
BernadetteLoscio: So first we need to decide whether or not we
agree with these Bps, and then move to the issue of subsetting
data.
... So decision one - are those BPs right, if not, should we
add new ones.
<Zakim> deirdrelee, you wanted to say APIs are really key to
data on the web..
<laufer> +1 to annete to...
deirdrelee: I agree with what Annette was saying. It's
different from data about a dataset.
... Years ago we were talking about decribing a dataset and a
vocab and they're basically the same. An API is different, so
yes, an API is different from a SPARQL endpoint
... What you need for SPARQL is the URI nad the data structure.
For a restful API you need the call details.
<laufer> I was just comparing that we have to give information
abou data and information about apis... including the info
about datqa that is returned by the api
deirdrelee: They're important and need their own BPs in their
own right, I'd say
annette_g: /me yay!
laufer: I agree... it's data about the API, which could include
the structure of hte data that is returned, how it is called.
That's not metadata.
<BernadetteLoscio> other one: Best Practice 21: Use Web
Standardized Interfaces
laufer: But we need just one ref to APIs in our doc, whichis to
use APIs. We could have - USe an API, and say that it needs to
be documented, take care of versioning etc.
... I don't think we have to split it into different BPs
annette_g: NThe point about APIs being aimed at a different
audience - it's important that we do address that partof our
audience.
... developers work on behalf of publishers
... Developers are a big part of our audience.
... The discussions we've had with Erik W are really only being
addressed through that discussion. I'm anxious to try and get
together with him and talk more about that. He said he was glad
that we're talking about augmenting that.
... I don't think his concerns will be addressed if we reduce
the BPs.
deirdrelee: So we need to make a decision.
... We could merge the BPs or keep them separate
<annette_g> I have an idea for scoping this
<annette_g> +100 to Phila
deirdrelee: I'm hearinf laufer in favour of merghing, Annette
not
<laufer> I do not disagree on the phil, but I think it will be
a extensive section and we do not have to that...
BernadetteLoscio: Just to say that before we vote, it would be
nice if we try to do something first. I'm not sure ... I think
it's a good idea gto merge, as Laufer says, but it might be
confused.
... So maybe we can try to reorganise and show what it would be
like. And then maybe vote next week
... Difficult to vote and then act in the abstract.
annette_g: There's a lot of stuff written about publishing a
good API. Can we find the gap in documentation between how to
do rest, what APIs are etc.
... What do people need to know that they're not already
getting
... WE should probably avoid publishing info on stuff for which
there is already a lot.
<riccardoAlbertoni_> About DQV, we have issue-231 but i have
notice that the discussion is continuing in via email and
people that are involved in the email discussion are not in the
call so I do not know if it make sense to discuss it or
continue by email
deirdrelee: I'd like to close the topic off.
<laufer> I think that talking about Best Practices of APIs is
talk about how to do q good interface for an application and I
do not think it is a trivial thing...
deirdrelee: Our Zagreb meeting is only a month away. Between
now and next friday, can we get some concrete suggestions,
merging, moving etc.
... And then we can vote next week
... So that's to the editors
+1
<annette_g> I didn't answer Berna's question, either
hadleybeeman: This caused a lot of trouble on the TAG. WE have
a lot of definitions of APIs. Everyone assumes we talk about
the same thing. But they're not
... JS/browser APIs, then device APIs, and then data APIs, rest
over HTTP. I'd like to plead to the editors to be clear what
kind of APIs we're talking about.
<BernadetteLoscio> thanks Hadley ;)
phila: Thanks Hadley, that's v helpful
annette_g: We started with Berna asking which ones I disagree
with. I don't disagree with any of them. BP21, the change that
I was suggesting wasn't in there, it just a matter of putting
in a line return. It's been that way for a while.
... I want to improve the distinction between a hypermedia API
that is HATEOS rest and one that isn't.
... Right now those 2 approaches are tangled up with heach
other and need untangling.
BernadetteLoscio: Can you rewrite that part, please Annette?
annette_g: That's what I was hoping to do with Erik.
DQV
riccardoAlbertoni_: This mornign we discussed terminology...
referring to the value resulting from a measure as a measure as
a measurement
<antoine> question at is at
[23]http://lists.w3.org/Archives/Public/public-dwbp-wg/2016Feb/
0056.html
[23]
http://lists.w3.org/Archives/Public/public-dwbp-wg/2016Feb/0056.html
riccardoAlbertoni_: The result of the process of a measurement
- is that a measure or a measurement.
phila: Would say measurement, but would defer to annette_g
<deirdrelee> +1
<PWinstanley> I don't see a classification of APIs, but
[24]https://ffeathers.wordpress.com/2014/02/16/api-types/ is
helpful
[24] https://ffeathers.wordpress.com/2014/02/16/api-types/
riccardoAlbertoni_: So we'll rename quality measure to
measurement
... I don't know if it's fair to close issue 231
issue-231
<trackbot> issue-231 -- metric, hasMetric, something else --
open
<trackbot> [25]http://www.w3.org/2013/dwbp/track/issues/231
[25] http://www.w3.org/2013/dwbp/track/issues/231
riccardoAlbertoni_: What do you think Antoine?
deirdrelee: I'd send an e-mail and if no objections, close it
<antoine> we can close it next time?
riccardoAlbertoni_: There are some technical Qs. Jeremy isn't
here, so not sure if we can discuss that here.
... Most of the dicussion now is pretty technical, about
modelling etc. The people discussing that are not usually on
the calls, so how can we close them.
... we can voite by e-mail?
deirdrelee: Can we facilitate people being on a call at a
different time if needs be? Would that help? Or is e-mail
sufficient?
phila: Decision by e-mail is fine as long as it is recorded
Zagreb
<laufer> [26]http://w3c.github.io/dwbp/bp-status.html
[26] http://w3c.github.io/dwbp/bp-status.html
laufer: Today was the date for BP review, is it postponed?
<BernadetteLoscio> thanks Laufer!
deirdrelee: Yep. This week was a little up in the air. Good
news - you get another week. Next week's agenda will be going
through that
<PWinstanley> early apologies for next week: ICEGOV 2016
[27]https://www.w3.org/2013/share-psi/wiki/Zagreb/social
[27] https://www.w3.org/2013/share-psi/wiki/Zagreb/social
<BernadetteLoscio> yes!
<BernadetteLoscio> thanks Deirdre!
<BernadetteLoscio> Happy Birthday Phil!!!
<hadleybeeman> Yes, happy birthday Phila!
<laufer> wow... long happy life, phil!!
<Caroline_> Happy Birthday phila!! :)
<annette_g> Happy birthday, Phil, you magnificent person!
<riccardoAlbertoni_> buon compleanno!
<annette_g> <(8^)
<laufer> bye all... nice weekend...
Summary of Action Items
Summary of Resolutions
1. [28]Approve last week's minutes
https://www.w3.org/2016/02/12-dwbp-minutes
[End of minutes]
__________________________________________________________
Received on Friday, 19 February 2016 17:30:53 UTC