Re: Hydra Telecon Minutes for 2017-04-17

Hi Hydranians

I’ve just published a hint of how I see the use-cases I volunteered to
write. These are available at my HydraGC fork:

https://github.com/alien-mcl/Specifications/tree/master/drafts/use-cases

Please share your thoughts so the whole job goes in the right direction.

Regards
Karol Szczepański

2017-04-17 21:48 GMT+02:00 Markus Lanthaler <markus.lanthaler@gmx.net>:
> 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 Tuesday, 18 April 2017 20:40:40 UTC