Hydra

Hydra W3C Community Group Telecon

Minutes for 2017-07-10

Karol Szczepański is scribing.
Ruben Verborgh: present+
Markus Lanthaler: elf-pavlik, should we wait for you?
elf Pavlik: no, please start i will follow on IRC and should have possibility to join audio in about 15min

Topic: Follow-up on action items

Markus Lanthaler: The first action item was "Markus will try to find a tool which will help us with PR reviews; it's currently difficult to keep track what has been addressed and what hasn't"
Markus Lanthaler: reviewed code review tools
Markus Lanthaler: https://reviewable.io/
Markus Lanthaler: Reviwable was found and used in the last R
... in the last PR
... Markus is pleased with how it works
... Suggestion is to use it unless better tools are found
Karol Szczepański: From my perspective there are 2 concerns [scribe assist by Markus Lanthaler]
Markus Lanthaler: ... one was security: Reviewable required quite some permissions on GitHub
... the other thing is that it creates quite some long, ugly comments in GitHub
... they are difficult to review in GitHub
... other than that it was quite useful.. may need some time to get used to it
Markus Lanthaler: did you use GitHub or Reviewable to read comments? [scribe assist by Markus Lanthaler]
Karol Szczepański: Both... I'm probably used to read GitHub [scribe assist by Markus Lanthaler]
PROPOSAL: Use reviewable.io for code reviews going forward
Markus Lanthaler: +1
Karol Szczepański: +0.5
Tomasz Pluskiewicz: +1
elf Pavlik: +1
Ruben Verborgh: +1
RESOLUTION: Use reviewable.io for code reviews going forward
Markus Lanthaler: The second action item was "Markus to rename issue #126 to not suggest a solution"
Markus Lanthaler: #126 is about linking to collections of specific type
Markus Lanthaler: Renamed it to "Simplify discovery of collections that contain resources of a certain type"
Markus Lanthaler: The third action item was "Pavlik to drive discussion regarding #126 after the issue has been renamed"
elf Pavlik: can we wait 5 more min so i can join voice?
Markus Lanthaler: Yes, we I just said we will wait for you on that

Topic: License of reference client (issue #4)

elf Pavlik: w could do license on Heracles.ts first
Markus Lanthaler: Suggestion is to use MIT
... Karol has some experience with BSD3, but MIT is OK
PROPOSAL: Use MIT license for Heracles.ts (issue #4)
Ruben Verborgh: +1
Karol Szczepański: +1
Markus Lanthaler: +1
Tomasz Pluskiewicz: +
Tomasz Pluskiewicz: +1
elf Pavlik: +1
RESOLUTION: Use MIT license for Heracles.ts (issue #4)

Topic: Status update on architectural diagram

Ruben Verborgh: Architecture diagram was discussed already during first or second call
... There is already a PR ready for the diagram so it can be merged
Markus Lanthaler: Markus raised a question on how we can use it
Ruben Verborgh: Diagram is still a proposal as it doesn't reflect a consensus
Ruben Verborgh: Diagram could an organizational tool to move forward
... As it divides what can be included as a Hydra core and what would be outside
... There are several points of interest thus diagram could help with arranging those various requirements
... Also it addresses dependencies between components
PROPOSAL: Merge Ruben's "Hydra architectural diagram" PR #128 (will be used to organize our work)
elf Pavlik: +1
Markus Lanthaler: +1
Ruben Verborgh: +1
Karol Szczepański: +1
Tomasz Pluskiewicz: +1
RESOLUTION: Merge Ruben's "Hydra architectural diagram" PR #128 (will be used to organize our work)
Markus Lanthaler: What would be the immediate next step regarding the diagram
Ruben Verborgh: There are couple of issues: critical review of what is missing
elf Pavlik: present+
... Another would be: Divide what needs to be done between attendees

Topic: Simplify discovery of collections that contain resources of a certain type (#126)

elf Pavlik: have impression that until we are sure whether to use something existing or define it on our own is a subject for further discussion
... Question is whether to do it in the same issue or create another one
... Some people hesitated with reusing other vocabularies
Ruben Verborgh: it is easy to create something different, but reusing should be our default approach
... We should then have a process rooted with reusing something
Tomasz Pluskiewicz: reusing may lead to unexpected behavior, but still we shall start with a process reusing something existing
Markus Lanthaler: We should reuse but not single properties or classes but some chunks of existing vocabularies
Tomasz Pluskiewicz: +1 on using more then single properties. good rules of thumb
Markus Lanthaler: Unless we reuse a big chunk we may need to create something independent
elf Pavlik: LDF uses void thus it could be natural to reuse it
elf Pavlik: a possibility of having something temporary which could be replaced in future by something more suitable
Markus Lanthaler: agree with that approach
Ruben Verborgh: we could make an issue out of it as an action point
Tomasz Pluskiewicz: we could create a place with guidelines
PROPOSAL: As a guiding principle, we will start designing/defining new concepts in Hydra instead of trying to reuse bits and pieces of various vocabularies from the get-go. If we later discover that there's a considerable overlap with an existing vocabulary we may decide to use it instead of our own solution.
Ruben Verborgh: +1
elf Pavlik: +1
Tomasz Pluskiewicz: +1
Karol Szczepański: +1
Markus Lanthaler: +1
RESOLUTION: As a guiding principle, we will start designing/defining new concepts in Hydra instead of trying to reuse bits and pieces of various vocabularies from the get-go. If we later discover that there's a considerable overlap with an existing vocabulary we may decide to use it instead of our own solution.
Ruben Verborgh: (have to move locations, will try to get back online after that)
Karol Szczepański: we should have some real use cases for those possibly new features
elf Pavlik: this actually was triggered by a use case (the #events property) [scribe assist by Markus Lanthaler]
elf Pavlik: use case came from events - question was how we can create a new event
elf Pavlik: could prepare a PR for the use case related to strongly typed collections and their discoverability
ACTION: Pavlik, to expand use cases to make it clear why we need a solution to issue #126

Topic: Decide on "hypermedia removal"

Markus Lanthaler: currently Heracles.ts tries to separate hypermedia from the raw data
... Question is: do we want that behavior inside or should it be on top of the client
Tomasz Pluskiewicz: agreed on separation from the data
elf Pavlik: i have to leave :( will read the minutes later today...
Tomasz Pluskiewicz: hypermedia controls from various sources i.e. api documentation and the current resource
Markus Lanthaler: Issue is about whether to provide an original resource untouched or shall it be cleaned of the hypermedia controls
Markus Lanthaler: should there be a method getData that could provide a raw data without hypermedia controls
Tomasz Pluskiewicz: JSON-LD framing to strip of unneeded content with custom context
Markus Lanthaler: it wouldn't do that
Tomasz Pluskiewicz: I wouldn't use the raw triples but reframe the data to use a dot notation
Tomasz Pluskiewicz: so the data are more accessible
Karol Szczepański: If I understood you correctly, you wouldn't strip the data but reframe it [scribe assist by Markus Lanthaler]
... the client doesn't know what is using it
... so it would need to be something on top of it
Tomasz Pluskiewicz: Right [scribe assist by Markus Lanthaler]
... what I did was to objectify it
... so you get a graph of objects
... and not a JSON tree
Karol Szczepański: You can make framing embed the data [scribe assist by Markus Lanthaler]
Tomasz Pluskiewicz: Karol should describe on what's currently implemented
Markus Lanthaler: Heracles.ts shouldn't modify the payload

Topic: How should Heracle's internal data model look like?

Markus Lanthaler: I think we will quickly hit the limits if we work with a framed JSON-LD doc internally [scribe assist by Markus Lanthaler]
... we could use flattened JSON-LD
... or probably even better triples as they are most flexible
Karol Szczepański: Agree, triples are the most flexible but definitely not the easiest option [scribe assist by Markus Lanthaler]
... I had, for instance, issues when working with subclassing
... it lead to manz if/else statements
... with framing we will hit the wall pretty soon though
... I used custom object hierarchies in another project
... but I'm not sure what we should use here
Karol Szczepański: The most important thing is to not leak the RDF details through the interface [scribe assist by Markus Lanthaler]
Tomasz Pluskiewicz: we shall give JS objects in the public API
Karol Szczepański: ... even if we use triples internally [scribe assist by Markus Lanthaler]
Markus Lanthaler: completely agree [scribe assist by Markus Lanthaler]
Tomasz Pluskiewicz: got some experience with RDFext but it was very heavy
... it was quite difficult to work with thus plain RDF under the hood may require good tooling
Markus Lanthaler: we may store triples in an array but let's push the limits with framing
... no more topics in the agenda
the conference has ended
Markus Lanthaler: what I said was that we could start with a simple array of triples that we filter etc. as I don't expect us to have millions of triples in a single response and see how far that brings us before we hit performance issues
Markus Lanthaler: I didn't suggest to push the limits of framing... if we want to go that route, I would suggest to use flattened JSON-LD internally instead