See also: IRC log
<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
<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
<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.
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
<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...