Hydra Telecon Minutes for 2017-04-17

Thanks Ruben for scribing! I'll publish the minutes from this week's telecon
on our homepage shortly.

In the meantime you can find a full transcript of the meeting below.
Unfortunately, it seems Hangout didn't record the audio for the call so I'll
delete the video soon as well:
   https://youtu.be/PwgnmeotVk4


-------------------------------------------------------------------
Hydra W3C Community Group Telecon Minutes for 2017-04-17

Agenda:
   https://www.w3.org/community/hydra/wiki/Conference_Calls
Topics:
   1. Intros
   2. Dietrich's PR #111
   3. Ruben's architectural diagram
   4. The future of Hydra-how do we move from here?
Resolutions:
   1. Go ahead and merge Dietrich's pull request
   2. Move the architectural diagram into the main repo and keep 
      iterating on it
   3. Concentrate primarily on examples to get things moving 
      again, iterate, implement and finally update the spec
Action Items:
   1. Karol to create a first version of a markdown document 
      describing client/server interactions before next telecon
Chair:
   Markus Lanthaler
Scribe:
   Ruben Verborgh
Present:
   Ruben Verborgh, Markus Lanthaler, Tomasz Pluskiewicz, elf Pavlik, 
   Thomas Bergwinkl, Karol Szczepański, Dietrich Schulten

Ruben Verborgh is scribing.

Topic: Intros

Markus Lanthaler:  Let's start with a round of introductions.
Markus Lanthaler:  I started Hydra a couple of years ago.
Ruben Verborgh:  I'm a researcher at Gent University [scribe 
   assist by Markus Lanthaler]
Markus Lanthaler: ... working on Linked Data Fragments based on 
   Hydra
   . querying different APIs, that's why Hydra is important to 
   us.
Tomasz Pluskiewicz:  RDF background, want to move Hydra forward.
elf Pavlik:  Working with LD for quite a bit. Look forward to how 
   Hydra develops. Playing with Solid lately. Hypermedia APIs and 
   clients. Based in Mexico City.
Thomas Bergwinkl:  CTO Zazuko. Linked Data and Hydra. Implemented 
   rdf-ext. Internet of things at home is already Hydra-enabled. 
   Hoping to get Hydra more into IoT. Cool stuff with JavaScript and 
   constrained devices.
Karol Szczepański:  (audio very weak, couldn't understand)
Dietrich Schulten:  Met Markus and Pavlik in Paris 2 years ago. 
   Background in REST APIs, and frustration about lack of 
   self-describing features. Integration. Wrote pull request for 
   hypothetic client interface.

Topic: Dietrich's PR #111

Markus Lanthaler: 
   https://github.com/HydraCG/Specifications/pull/111
Dietrich Schulten:  main interest = working code, not so much how 
   interface should look like
   . pull request had been started, but minimal.
   .get some code to validate the API.
Markus Lanthaler: zakim, present+ dietrich
Markus Lanthaler: zakim, present+ Ruben
Markus Lanthaler: zakim, present+ bergi
Ruben Verborgh:  what is the end goal of #111?
Markus Lanthaler: zakim, present+ elf-pavlik
Markus Lanthaler: zakim, present+ tpluskiewicz
Dietrich Schulten:  show how application uses an API, build code 
   afterwards
Markus Lanthaler: zakim, present+ karol_szzczepanski
   .pseudo-language, try to implement
Markus Lanthaler:  There were some differing opinions on what the 
   interface should look like.
   .app or low-level library
   .both are fine, expectations of most have been low-level 
   library
   .disclaimers have been added to PR
   .we should merge and give a shot
s/clinet/client
Dietrich Schulten:  no problem if is rewritten, comments would 
   make it quite a rewrite
   .Should the client be aware of the uniform interface?
   .Abstracting it away opens a lot of new questions.
   .Bottom line: do what you want with the PR.
Thomas Bergwinkl: +q align the interface more to the fetch 
   standard API (after merging the PR)
Ruben, you wanted to suggest different repository for clinet
Ruben Verborgh:  couple of things. Great step to move forward 
   [scribe assist by Markus Lanthaler]
Markus Lanthaler: ... think that a client won't be a single issue 
   but multiple issues
Markus Lanthaler: ... may need a separate client
Karol Szczepański:  some questions related to the client would 
   make things difficult.
Markus Lanthaler:  related to spec itself, against moving it.
Thomas Bergwinkl:  fine however we handle it, we should align it 
   more to other standards
Markus Lanthaler:  what standards?
Thomas Bergwinkl:  fetch; I already implemented a client
(link?)
Thomas Bergwinkl:  align with RDF/JS spec; a lot of stuff is only 
   JSON-LD
Thomas Bergwinkl: https://github.com/rdf-ext/rdf-fetch-lite
   .already made an extension
   .to RDF/JS
Thomas Bergwinkl: extension to fetch for RDFJS
Tomasz Pluskiewicz: q?
Thomas Bergwinkl: fetch spec: https://fetch.spec.whatwg.org/
Thomas Bergwinkl:  we should maybe have something like a browser, 
   built on top of more low-level client. We should split into 
   low/high level.
Thomasz: Looking at the PR, I'm missing JSON-LD 
   examples/snippets, what client gets and what it can do with it. 
   How does the client use the controls? Hard to tell what API we 
   are looking at.
Ruben Verborgh:  maybe we need recurring use case?
Thomasz: RESTbucks
Markus Lanthaler:  makes sense, tried that from the beginning 
   with issue tracker and events API, but too hidden in an 
   implementation.
Markus Lanthaler:  good idea to document requests and responses
Markus Lanthaler:  volunteers?
Karol Szczepański:  what should be in there?
Markus Lanthaler:  let's take event API. Have markdown document 
   that lists use cases with requests and responses, dump of HTTP 
   interaction.
Tomasz Pluskiewicz:  Let's make it multiple documents. For each 
   use case a document.
   .different variants, states, etc.
Karol Szczepański:  I will give it a try.
   .let's decide on deadline.
   .I'll try to craft something ASAP, we can decide whether it 
   goes in the right direction.
   .Do we need context for this task? What kind of application 
   are we considering?
   .Calendar app?
Markus Lanthaler:  Low-hanging fruit is event app or issue 
   tracker.
   .because that's already there.
Karol Szczepański:  I'll try to craft something.
   .I assume this should be created in similar way as #111? 
   Markdown?
Markus Lanthaler:  Yes, easiest.

ACTION: Karol to create a first version of a markdown document describing
client/server interactions before next telecon


PROPOSAL: Go ahead and merge Dietrich's pull request

Markus Lanthaler: +1
elf Pavlik: +1
Tomasz Pluskiewicz: +1
Thomas Bergwinkl: +1
-0.5 I don't think it fully crystalized yet, but no strong 
   opinion

RESOLUTION: Go ahead and merge Dietrich's pull request


Topic: Ruben's architectural diagram

Markus Lanthaler: 
   https://github.com/RubenVerborgh/Hydra-Architecture-Diagram
Ruben Verborgh:  We need hypermedia controls in detail. We got 
   stuck in the discussions in the last 2 years [scribe assist by 
   Markus Lanthaler]
Markus Lanthaler: ... This is an effort to get things moving 
   again - like Dietrich's PR
Markus Lanthaler: ... it's a technical diagram but also acts as 
   organizational diagram
Markus Lanthaler: ... who wants to work on what etc.
Markus Lanthaler: ... main separation is API modeling vs. in-band 
   controls
Markus Lanthaler: ... for each we have bits and pieces but some 
   stuff is not complete (e.g. pagination)
Markus Lanthaler: ... I expect two kinds of feedback: 1) 
   specifically on the diagram itself 2) what do people think of 
   this diagram to move forward?
Markus Lanthaler: ... we'll need concrete proposals for each 
   block
Markus Lanthaler: ... and maybe split into subgroups
Tomasz Pluskiewicz:  I don't like splitting, there's only a 
   handful of us anyway.
   .But in general, I like the diagram.
   .Clarifies some things.
   .Issues will likely tackle one or two blocks.
   .One more thought: currently, Hydra Core deals with 
   abstractions and concretes, like paging or filtering.
   .I don't know if you looked at the issues in the repo.
   .When we have field constraints, for instance, I'd like to 
   shrink Hydra Core, so it only describes the abstract thing.
   .We should be more open to different ways for defining 
   constraints or ways to filter.
   .So Hydra Core and missing pieces filled in by other 
   vocabulary.
Markus Lanthaler:  Would you like to see the vocab be split right 
   now, given that we don't know what the complete vocabulary will 
   end up like?
Tomasz Pluskiewicz:  I would want to split sooner rather than 
   later. There's already a number of competing ways (data shapes, 
   shaql, .)
   .We can keep fighting on how to make a field e.g., a number, 
   or we can just define some basics.
   .We should give them the smallest possible building blocks.
Ruben, you wanted to clarify splitting
Ruben Verborgh:  I agree, we are indeed only a handful of people 
   [scribe assist by Markus Lanthaler]
Markus Lanthaler: ... it's more about ownership
Markus Lanthaler: ... lots of discussions got lost in discussions 
   without having the full picture
Markus Lanthaler: ... with a group I would like people to focus 
   on a specific thing like fields e.g. for a month and then present 
   progress
Markus Lanthaler: ... I for instance would be able to get a group 
   of people at Gent University to write a spec for some subparts
Markus Lanthaler:  two things: splitting ownership, and 
   organizing how we move forward
   .Tomasz was more about technical separation, namespaces etc.
Tomasz Pluskiewicz:  Problem with ownership is that Markus is 
   viewed as oracle, everyone looking for blessing.
   .Benevolent dictator situation?
Markus Lanthaler:  I've been thinking about that.
   .This brings us to the last agenda item.
   .Let's first close up.
   .Where do we want to take the diagram?
   .Do we want to iterate? Do people think it is useful? Is the 
   representation useful?
   .Does it help us to make progress?
Markus Lanthaler: Who thinks this is useful for moving forward
elf Pavlik: +1 should we include it somewhere in 
   https://github.com/HydraCG/Specifications ?
Dietrich Schulten:  Ruben's comments in the beginning helped me 
   with the distinction modeling and controls. We can keep it as a 
   basis.
Markus Lanthaler: +0.5 a bit too abstract for my taste, would 
   like to see it move somewhere under 
   https://github.com/HydraCG/Specifications
Thomas Bergwinkl: +1
Ruben Verborgh:  I can take the task to move it to the main repo 
   [scribe assist by Markus Lanthaler]

PROPOSAL: Move it into the main repo and keep iterating on it

Markus Lanthaler: +1
elf Pavlik: +1
Ruben Verborgh: +1
Tomasz Pluskiewicz: +1 IMO abstractness is good for general 
   discussions. aligns with my idea of smaller Core Vocab
Markus Lanthaler: dietrich: +1

RESOLUTION: Move the architectural diagram into the main repo and 
   keep iterating on it


Topic: The future of Hydra-how do we move from here?

Ruben Verborgh:  Let me be brutally honest [scribe assist by 
   Markus Lanthaler]
Markus Lanthaler: ... we need hypermedia and I'd love this to be 
   Hydra
Markus Lanthaler: ... we need this to move again or we need to 
   find something else
Markus Lanthaler: ... shouldn't be a threat
Markus Lanthaler: ... but we need things to move
Markus Lanthaler:  I have been a bottleneck because my time is 
   extremely limited at the moment, and has been the last year.
   .I'd love to see more people step forward and start working on 
   things, like Dietrich.
   .Triggered a lot of comments, good to see that people are 
   still interested.
   .I probably was looking too much for consensus. Will probably 
   proceed more strongly in the future, unless people strongly 
   disagree.
   .We can always revisit later if there are new insights.
   .We spent a lot of time getting people on the same page. But 
   we're there now.
   .I just hope that people take more initiative by themselvs.
s/themselvs/themselves/
Ruben Verborgh:  we need consensus on architectural document 
   [scribe assist by Markus Lanthaler]
Markus Lanthaler: ... want to split stuff. let's take paging
Markus Lanthaler: ... input phase: what are the use cases etc.
Markus Lanthaler: ... the group goes off and creates something
Markus Lanthaler: ... it gets presented and discussed
Dietrich Schulten:  I'm very much interested in progress. We need 
   to identify the area where we want to make progress.
Markus Lanthaler:  I'd still like to see some consensus and 
   discussions.
   .but happy with concrete proposals.
Dietrich Schulten:  Ruben, what does your team needs the most, 
   for me it's fields [scribe assist by Markus Lanthaler]
Ruben Verborgh:  filtering and fields [scribe assist by Markus 
   Lanthaler]
Markus Lanthaler: ... proposal: let's take 1 month to discuss 
   architectural diagram
Markus Lanthaler: ... and then start working on blocks
Markus Lanthaler: ... I don't want this to become a closed thing
Markus Lanthaler: ... we just have the time
Markus Lanthaler:  Do people want to iterate on specifications, 
   or would it be more productive to work together on a reference 
   implementation?
Karol Szczepański:  From my perspective (spent some time on 
   client and server implementation of Hydra): examples and living 
   code talk to people, and this is what Hydra currently lacks.
   .So maybe start from examples. The spec is okay, but the most 
   productive way is to have something working.
   .For instance, I don't know how to create an operation that 
   uses an IRITemplate.
   .I don't know how far my implementation is from being correct.
Markus Lanthaler:  I wonder if the document with the example 
   interactions would help you in that regard?
Thomas Bergwinkl:  what language? Probably JavaScript.
Tomasz Pluskiewicz:  As a comment for Karol: if you have a 
   problem with holes in the spec, this could be your focus for the 
   examples.
Thomas Bergwinkl:  I saw most activity with JavaScript.
Ruben Verborgh:  everybody can contribute what they're best at 
   (spec, example, code)?

PROPOSAL: Concentrate on examples (and perhaps code) instead of 
   spec writing to get things moving again

Tomasz Pluskiewicz: +1
Ruben Verborgh: -1 we need both, but specs can start from code
(spec just needs to move faster; it needn't be slow)
Thomas Bergwinkl: -1, +1 rubens comment
elf Pavlik: +1 examples -1 *instead of* spec writing
agree with elf-pavlik
Dietrich Schulten:  +1, make sense to me [scribe assist by Markus 
   Lanthaler]
Markus Lanthaler: +1
Ruben Verborgh:  examples are good but they don't replace the 
   rest [scribe assist by Markus Lanthaler]
Karol Szczepański:  no one says "instead of"
   .let's focus on having both, and spend extra time on examples. 
   Then go back to spec.
Dietrich Schulten:  we should find use cases to work on, and find 
   things that are not possible with the spec, then add to the spec
(we should probably close in the interest of time)
Thomas Bergwinkl:  The spec needs a lot of work. Only the 
   examples won't get us there either.
Markus Lanthaler:  once we have agreement on the examples, we 
   will move them to the spec.

RESOLUTION: Concentrate primarily on examples to get things 
   moving again, iterate, implement and finally update the spec

Received on Monday, 17 April 2017 19:49:10 UTC