Hydra W3C Community Group Telecon Minutes for 2017-07-10

Thanks Karol for scribing. The minutes from this week's telecon are
now available at

   http://www.hydra-cg.com/minutes/2017-07-10/

The full text of the discussion is below, including a link to the audio
transcript.


-------------------------------------------------------------------
Hydra W3C Community Group Telecon Minutes for 2017-07-10

Agenda:
  https://www.w3.org/community/hydra/wiki/Conference_Calls
Topics:
  1. Follow-up on action items
  2. License of reference client (issue #4)
  3. Status update on architectural diagram
  4. Simplify discovery of collections that contain resources of 
    a certain type (#126)
  5. Decide on "hypermedia removal"
  6. How should Heracle's internal data model look like?
Resolutions:
  1. Use reviewable.io for code reviews going forward
  2. Use MIT license for Heracles.ts (issue #4)
  3. Merge Ruben's "Hydra architectural diagram" PR #128 (will be 
    used to organize our work)
  4. 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.
Action Items:
  1. Pavlik, to expand use cases to make it clear why we need a 
    solution to issue #126
Chair:
  Markus Lanthaler
Scribe:
  Karol Szczepański
Present:
  Markus Lanthaler, Karol Szczepański, Ruben Verborgh, elf Pavlik, 
  Tomasz Pluskiewicz
Audio:
  http://www.hydra-cg.org/minutes/2017-07-10/audio.mp3


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: 
  https://reviewable.io/reviews/hydracg/heracles.ts/3
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
+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: 
  https://github.com/HydraCG/Specifications/issues/126
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: https://github.com/HydraCG/Heracles.ts/issues/4
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: 
  https://github.com/RubenVerborgh/Hydra-Architecture-Diagram
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: 
  https://github.com/RubenVerborgh/Hydra-Architecture-Diagram/issues
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)

Markus Lanthaler: 
  https://github.com/HydraCG/Specifications/issues/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
Tomasz Pluskiewicz: 
  https://github.com/blog/1184-contributing-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: https://github.com/HydraCG/Heracles.ts/issues/7
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]
Markus Lanthaler: 
  https://json-ld.org/spec/latest/json-ld-framing/#object-embed-flag
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: https://github.com/HydraCG/Heracles.ts/issues/8
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

Received on Monday, 10 July 2017 19:50:49 UTC