- From: Markus Lanthaler <markus.lanthaler@gmx.net>
- Date: Mon, 10 Jul 2017 21:50:13 +0200
- To: "'Hydra'" <public-hydra@w3.org>
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