Data on the Web Best Practices Working Group Teleconference

<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 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 https://www.w3.org/2016/02/12-dwbp-minutes

<deirdrelee> Webex: 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> 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> 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: http://www.w3.org/2013/dwbp/track/issues/240 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> 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> http://w3c.github.io/dwbp/bp.html#dataAccess

<Caroline_> http://w3c.github.io/dwbp/bp.html#dataAccess

annette_g: This section... 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.

BernadetteLoscio: BP10

<BernadetteLoscio> 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 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 https://ffeathers.wordpress.com/2014/02/16/api-types/ is helpful

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> 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> 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

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...