Hydra

Hydra W3C Community Group Telecon

Minutes for 2019-02-18

Karol Szczepański: Meeting: Hydra W3C Community Group Conference Call
Tomasz Pluskiewicz is scribing.

Topic: Brief update on actions from last calls

Karol Szczepański: Brecht was looking into logo alternative

Topic: API documentation limitations - PR#183

Karol Szczepański: this tries to resolve the issue, to express strongly typed collections
... and explicit targets
Tomasz Pluskiewicz: the issue is vague
Karol Szczepański: if look into the issue, there are linked issues/PRs (in heracles) which explain
... Angel had a nice idea with `hydra:Specifies`
aveltens: I'd like to see some use case
.. to find the usages and see if it fits the purpose
Tomasz Pluskiewicz: I propose same, to discuss on concrete examples
Karol Szczepański: those are tricky and I wouldn't want to spend too much time on details
... I also proivded example implementation to check
... I wanted them to spark discussion
... I want to avoid endless discussion
Tomasz Pluskiewicz: we've fallen the same trap
.. the PRs are too narrow
Karol Szczepański: I'd try to spend more time on these features
... as we can agree that those are in general good direction
Tomasz Pluskiewicz: I think angelo's examples are great in porposiing a generic solution
aventens: I can come up with SHACL examples of descriptions
... I haven't tried yet
Karol Szczepański: it will work. good think about SHACL is not OWL so that makes is simple
aveltes: yes, Solid probably will also adopt shacl
Karol Szczepański: I want to think about heracles.ts
Tomasz Pluskiewicz: maybe we should heracles to a later stage in specifying
aveltens: shacl has already been worked on
Tomasz Pluskiewicz: it should be easy to fit shacl in place of Hydra
Karol Szczepański: yes, SHACL is not different from hydra:Class
.. next step to try fit SHACL to this

Topic: Allow returns/expects to be expressed in terms of a media type PR#186

Karol Szczepański: similar, to define returns/expects instead of SHACL
aveltens: yes, if we explore #183 we will come to a joint conclusion
Karol Szczepański: so, this one is concuded

Topic: Define client-initiated pagination PR#184

Karol Szczepański: i proposed skip/take
... there was discussion about also supporting pageReference, etc
... for me, it's less understandable to the client
Tomasz Pluskiewicz: I would accept as-is and then work on IriTemplate itself
aveltens: what would make sense if the client know how to get to the next page
Karol Szczepański: the hard part is defining the meaning. for example, would the page ever not be a number?
Tomasz Pluskiewicz: I only say it should not be too constrained
Karol Szczepański: maye we could add a pageIndex, defined to take a numeric value
Tomasz Pluskiewicz: I don't think these should be properties
Karol Szczepański: the for will be an object
Tomasz Pluskiewicz: I say we finalize this and the work on template and actual usage

Topic: Add support for describing headers PR#185

Karol Szczepański: proposes letting the client know about HTTP headers
Tomasz Pluskiewicz: I lack the practical example and don't agree with the use of template
Karol Szczepański: Prefer: key=value
Tomasz Pluskiewicz: maybe this is too generic
Karol Szczepański: so you would you retract the template?
aveltens: I propose to just define hearder which the server expects
Tomasz Pluskiewicz: this is something we will expand and improve in the future

Topic: Gitbook branding #2

Tomasz Pluskiewicz: two points: 1. using the official domain; 2. subdomain name
... I think we agreed on cookbook.hydra-cg.com

Topic: Discuss to increase the use of Gitbook for drafting features

ACTION: tpluskiewicz comes with a code of conduct regarding vocabulary modifications/extensions
Tomasz Pluskiewicz: I think we need to return to using the book
aveltens: I agree that it will help us focus on the actual use cases
Karol Szczepański: I would like to provide more use cases
... of course I'd like to make it more up to date with reference client