See also: IRC log
<yaso_> Hi all, happy new year!
<phila> Good to see comment on the DQV antoine https://lists.w3.org/Archives/Public/public-dwbp-comments/2016Jan/0056.html
<yaso_> newton web irc is weird, sorry
<scribe> scribe: deirdrelee
<hadleybeeman> http://www.w3.org/2015/12/18-dwbp-minutes
PROPOSED: Resolve minutes of last meeting http://www.w3.org/2015/12/18-dwbp-minutes
<erikstephan> +1
<BernadetteLoscio> +1
<hadleybeeman> +0 (wasn't there)
<yaso_> +1
+1
<laufer> +1
<newton> +1
<phila> +1
RESOLUTION: Resolve minutes of last meeting http://www.w3.org/2015/12/18-dwbp-minutes
<erickauz> +1
hadley: let's start with annette's email comments on publication practices, can editors talk us through what's been happening in past week?
BernadetteLoscio: annette_g was not happy with bp on APIs. what happened was that changes were made before the voting, not after voting
the changes that were made after voting were on the html that phil suggested and newton made
scribe: the doc was frozen on
monday/tuesday and that editors were waiting for review
... during the week of the voting, there was discussion on the
api, yaso was working on this
... on thurs yaso's changes were merged. so maybe the issues
that the changes were made after frozen
... just want to make clear that no changes on text were made
after voting, just on html
annette_g: the main idea of what
went into rest api was fine, annette_g wrote it together with
yaso
... frustrating that it happened after doc was frozen, but that
is a separate issue
... didn't see this change when reviewing the doc, not sure of
exact time
... maybe changes shouldn't have been added when the doc is
frozen
... yaso sent an email around the actual text, this was very
useful,
... as soon as the google doc text was added to the actual doc,
the text was changed. probably by an editor who might not have
been aware of all the issues
... this was not necessarily inline with the final google doc
text, and actually annette_g strongly disagrees with some of
the tex
... there are different interpretations of REST, so it's
difficult to write this text and may not have been clear to the
editors that an effort to address both REST camps, both
approaches was being made
... and the final text looks like we're only addressing one
REST approach
yaso_: annette_g is right, it is
difficult to write bps on this topic as there are lots of
different opinions.
... 4 bps were added at this time, spread across the
document
... challenges and bps have to be added too. but i'd like to
separate parts of the document in the bp, and not spread the
bps from the google doc across the bp doc. but this is
difficult
... suggest that we read the modifications and try to address
them with annette_g's suggestions on the text
... keeping it as simple as possible, because there's so much
that could be said around REST
<yaso_> got it, annette_g !
annette_g: to respond to yaso_, the multiple places where apis are mentioned, that's fine with me. the part that i've a problem with, where two paragraphs were collapsed into one, is in one place in the REST API BP
BernadetteLoscio: when we were making the modifications, we were talking ot yaso, and we thought there was agreement on the modificaitons, that's why we made the merge
<annette_g> right
yaso_: there was an agreement on the text that was in the google docs, but the text is not exactly as it was in the google doc
laufer: we are talking a lot
about API style in the document, but this is one of the ways we
can access data, but there are other ways we can access datas,
like URI doc or Linked Data Documents, we don't talk about
these in the BP
... it's good to talk about APIs, but we are going too deep
into this discussion
annette_g: not sure why laufer sees a disconnect. why would a REST API not be compatible with Linked Data?
laufer: i'm not saying that it's
not compatible, but we have a Linked Data API, like to a URI
template, there are different ways to access data
... if someone wants to access a web service using soap it's
okay too
<yaso_> agree
<phila> I only hear bad things about SOAP (not RESTful and all that). People do get very upset about these things
annette_g: my opinoin is that most developers nowadays would feel that soap/rpc is not bp
<hadleybeeman> +1 to phila
newton: annette_g, are you referring to this commit? this was only to fit the content without the RFC keywords. the only change we made. the description was too long, so we adapted it to fit the bp
<yaso_> + 1 t phila
<annette_g> I don't see the change where the two paragraphs became one
phila: there is a lot to discuss, which is great. concern that a member of group is not happy with content in latest publication, that's not good, should be resolved
<phila> http://w3c.github.io/dwbp/publishing-snapshots/WD-dwbp-20160112/Overview.html#APIHttpVerbs
phila: suggest to take immediate
remedial action and then ensure that this situation doesn't
happen againg.
... talked to ralph, he suggested we immediately publish a new
version of the doc, with the following update - added an issue
that says that this bp is subject to a lot of debate and points
to annette_g's email
... annette_g is this okay with you?
<annette_g> yes
phila: I am seeking agreement
from the group
... next publication date on Tuesday
<yaso_> +1
phila: is the group happy with this suggestion?
hadleybeeman: wants to make this
work for everything and that everything we publish and put our
name on reflects the opinions of the groups. therefore i am
behind publishing this
... however also want to ensure we're abiding by procedure. in
the agenda, we didn't mention that we would take a vote today
on publication
phila: technically it is in the
agenda because link to phila's email which proposes publishing
this new draft
... right ot raise it, but think it's procedurally fine
<phila> http://w3c.github.io/dwbp/publishing-snapshots/WD-dwbp-20160112/Overview.html#APIHttpVerbs
phila: the doc is exactly the same except for the addition of the issue
PROPOSED: to publish a new version of BP doc based on http://w3c.github.io/dwbp/publishing-snapshots/WD-dwbp-20160112/Overview.html#APIHttpVerbs
<hadleybeeman> +1
<BernadetteLoscio> +1
<yaso_> +1
<annette_g> +1
<antoine> +1
<newton> +1
<erikstephan> +1
<phila> +1
<erickauz> +1
<laufer> +1
+1
RESOLUTION: to publish a new version of BP doc based on http://w3c.github.io/dwbp/publishing-snapshots/WD-dwbp-20160112/Overview.html#APIHttpVerbs
<BernadetteLoscio> +q
<annette_g> thank you for taking my concerns seriously
phila: we need to be cogniscent about this so it doesn't happen again
hadleybeeman: we do have to be
very careful about what version of text we're approving and
content changing after freezing
... also our fault as chairs, that we encourage iteration as
there is plenty of discussion :)
BernadetteLoscio: as editors, we
are trying to be very careful and follow procedures. we have
learned a lot
... in this case we opened the doc after freezing, because we
thought there was agreement, but maybe we shouldn't do this
again
<annette_g> looking at the google doc, I think it was just the collapsing of the two paragraphs into one that changed the sense of it.
BernadetteLoscio: next time, the document will not be changed after being frozen
hadleybeeman: sounds sensible, and I hope you don't feel attacked, this isn't personal
BernadetteLoscio: no, we are
trying to follow procedure
... for this case we created an exception, but we won't do this
in future
... if there is similar big issues, then we won't publish and
continue devleopment
<erikstephan> http://w3c.github.io/dwbp/vocab-du.html I have three parts to discuss: 1) December meeting follow up comments about the vocabulary 2) Public comments on the citation model 3) Vote recommendation
erikstephan: lot of things to
share :)
... there were comments from group, specific comments from
laufer,then discussion on citation
<erikstephan> ) December meeting follow up comments There were concerns expressed in the last meeting about releasing the vocabulary with some of the existing domain and range constraints we originally set as well as follow on discussion in email with Laufer: https://lists.w3.org/Archives/Public/public-dwbp-wg/2015Dec/0137.html These changes have been made to existing draft including adding vann:Usage statements and I believe we have satisfied these concerns.
erikstephan: one of the reasons
for not publishing was that we had domains and ranges on
third-party classes. we agreed in the meeting to remove these
as they may cause problems with inference, and instead would
provide guidance
... these should satisfy laufer's comments. laufer/
s///?
<phila> Example of vann:Usage
laufer: i have two main concerns.
the first is about the use of domains and ranges, and this has
been replaced by guidance
... but there is another issue, the properties of the duv
vocab, there are three properties that have the definition of
two domains and two ranges
... dcat:dataset and d cat:distribution
... would like to create two properties
<laufer> dcat:Dataser and dcat:Distribution
<laufer> dcat:Dataset and dcat:Distribution
erikstephan: so we would have to
be more explicit with the properties or remove
domain/range
... would have to discuss with BernadetteLoscio and Sumit
antoine: what is the semantics of the comma between dataset and distribtion? I assumed it was a disjunction, so was less concerned than laufer
erikstephan: if the representation is causing confusion, AND vs OR, then I'd rather remove the confusion. we could also provide description
<Zakim> phila, you wanted to talk about dact:Dataset/Distribtuon disjunction
antoine: I would strongly advise
not using the comma and instead using formal owl representation
to avoid confusion
... if it was AND and not OR, I would share laufer's
concerns
<laufer> if one defines triple "s duv:refersTo o", a reasoner will enfere that o is a dcat:Dataset and a dcat:Distribution
<laufer> infere
<phila> phila: I just said that dcat:Distribution and dcat:Dataset are not disjoint (one thing can be both)
<phila> antoine: said that didn't make any difference to his comment
antoine: question about the vann:usagenote property - is it actaully property with lowercase
<antoine> http://vocab.org/vann/#usageNote
antoine: and i can't actually fine the vann:usagenote in the vann namespace
erikstephan: i'll have to look at that
<phila> It's usageNote, not usage, so it's a typo
<erikstephan> 2) Public comments on the vocabulary
erikstephan: thanks for all the comments!
<erikstephan> Before Christmas, we had an unexpected contact from Silvio Peroni author of the SPAR ontologies http://www.sparontologies.net/ about proper usage of their classes and properties in the context of creating references and citations for FaBIO https://lists.w3.org/Archives/Public/public-dwbp-comments/2015Dec/0003.html http://www.essepuntato.it/lode/http://purl.org/spar/fabio and CiTO http://www.essepuntato.it/lode/http://purl.org/spar/cito as well a[CUT]
erikstephan: I wanted to provide a summary of what we discussed for the record
<erikstephan> Fabio is based on the Functional Requirements for Bibliographic Records (FRBR) Established In 1998 by the International Federation of Library Associations and Institutions (IFLA) an organization that was itself established in 1927. Dr Peroni had some questions about our duv:DataCitation class and offered some insights to using their classes and properties. http://bibliontology.com/ FaBIO expanded upon bibo by taking the relatively flat structure a[CUT]
erikstephan: one of the things he
talked about was proper usage of SPAR ontology and FaBIO, and
he had some questions around this
... we may be getting rid of the data citation class
... have some feedback, but still need to discuss with
BernadetteLoscio and Sumit.
... an example of using vann:usage to provide references that
describe a dataset, instead of introducing another concept
called dataset that isn't dcat:dataset
<erikstephan> 3) Recommendations on vote status
<erikstephan> Based on these conversations, adjustments are being made to the DUV such as replacing the duv:DataCitation class with classes and properties recommended by SPAR. and because of the importance of I feel reluctant about asking for a vote for additional public comments until we have incorporated these changes. I’ll need to meet with Berna and Sumit , but I believe we can provide these changes by next week.
erikstephan: since we've gotten
feedback from SPAR group, it's imperative that we take these on
board and work with them (they're enthusiasic) before going out
for further public comment
... i think we should make corrections based on SPAR feedback,
and have a vote next week
<hadleybeeman> deirdrelee: That all sounds great, Erik.
<phila> (Dee is saying what I was going to say)
<hadleybeeman> ...In context of the other conversation we've had in this meeting, maybe we should take a bit of caution with the timing.
<hadleybeeman> ...Specifically freeze the text after next week's meeting, and then have the group review it.
<phila> Robin Berjon no less!
<hadleybeeman> erikstephan: Sure. Now that we're picking up a bit of feedback, it's a priority getting things published, but --
erikstephan: agree
phila: agree, sounds like erikstephan you're working through comments, sounds on track
<hadleybeeman> deirdrelee: Where are we on the planning, phila?
phila: we discussed in SP a f2f
between14-16 march in zagreb
... we've had various conversations with zagreb, but still
ongoing
... aim is to those who can get to zagreb would do so on sunday
13th march
... dwbp would meet on monday and tue morn
... on tue afternoon we'd be joined by share-psi for group
meeting
<antoine> for the minutes: it's 14-16 march not 14-20 march isn't it?
phila: tue evening a nice meal
(last f2f )
... and wed share-psi meeting
<BernadetteLoscio> thank you!!!
<erikstephan> :-) We "chair"ish you hadleybeeman
<annette_g> :)
<annette_g> bye all!
<yaso_> bye ! :-D