Hydra W3C Community Group Telecon
Minutes for 2017-04-17
- Agenda
- https://www.w3.org/community/hydra/wiki/Conference_Calls
- Topics
- Resolutions
- Action Items
- 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
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 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