Hydra W3C Community Group Telecon
Minutes for 2018-04-16
- Agenda
- https://www.w3.org/community/hydra/wiki/Conference_Calls#2018-04-16
- Topics
- Chair
- Markus Lanthaler
- Scribe
- Markus Lanthaler
- Present
- Markus Lanthaler, elf Pavlik, Tomasz Pluskiewicz, Karol Szczepański
- Audio Log
Markus Lanthaler is scribing.
Topic: Follow-up on ACTION items
Markus Lanthaler: the first AI was: Markus to write down a proposal on how a expects "request shape" could look like
Markus Lanthaler: didn't have time to get this done, will send it out the next couple of days
Markus Lanthaler: the second AI was: Karol, to extend use cases to include ApiDocumentation examples
Karol Szczepański: same here
... was busy with PRs
Markus Lanthaler: the third AI was: Pavlik, to create issue regarding subject in POSTs etc. - Issue-162: managing @id and/or @base for newly created resources / named graphs
elf Pavlik: I created ISSUE-162
... I probably tried to capture too many things in there
... I describe in there how a server can accept a POST with a blank node
... and decide which node to pick
... with multiple nodes it isn't so obvious for the server which resource to pick and assign IDs
Markus Lanthaler: did anyone have a chance to read ISSUE-162 already?
Karol Szczepański: me and Tomasz already replied
... if the server expects a single resource is it allowed to pass a graph?
Tomasz Pluskiewicz: I think it's just a serialization detail
... but there might be differences between PUT and POST
elf Pavlik: yeah, in a PUT the client knows what happens and can use full IRIs instead of blank nodes
... can a relative IRI be used in a POST?
Karol Szczepański: we discussed that before.. but I don't remember the outcome
Tomasz Pluskiewicz: if you request something and get back relative URLs
... the base is taken from the request URL
elf Pavlik: yeah, unless it is overridden in the context
Tomasz Pluskiewicz: I think that still holds for a POST
Karol Szczepański: the IRI you are POSTing to might be completely unrelated to what you are posting
Tomasz Pluskiewicz: in that case, the server should ignore the @id the client provides
elf Pavlik: when you say @id, you only mean the single, top-level node, right?
... the client could send a graph with multiple resources
Tomasz Pluskiewicz: you make a good point
... looking at it as triples it is not obvious what the "root" is
... might be worth checking what the Linked Data Platform did
elf Pavlik: I'll change my pull request to only cover the case with a single blank node which would be the root node
Tomasz Pluskiewicz: I think assigning the ID is just a subset of the problem
... the general question is what's the root resource within the client-supplied graph
elf Pavlik: for use case 5 with POST a single resource with a blank node
... don't you think it would be worthwhile clarifying that use case
Tomasz Pluskiewicz: adding a note is fine
... but I wouldn't go into too much detail just yet
Karol Szczepański: Pavlik, you could send a POST with a concrete @id
elf Pavlik: it may re-assign a different IRI then
Tomasz Pluskiewicz: maybe... or perhaps it would incorporate it as a separate resource into the graph
... or replace the IRI
... there are other options as well
elf Pavlik: I think this would be easier to discuss on GitHub
Tomasz Pluskiewicz: yeah, let's do that
elf Pavlik: I have another use case where I PUT a triple but don't want to create a new resource
Karol Szczepański: the PUT already defines the IRI
... regardless of what you put in the payload
... PUT tells the server to makes a resource out of the payload
Tomasz Pluskiewicz: are you actually talking about a PATCH?
... with a PUT you want to tell the server to replace the resource
... but the client can't make too many assumptions about what exactly the server does
... further, you are just doing a POST
... which doesn't have any semantics
... just POSTing a triple isn't enough to derive the semantics
Karol Szczepański: it would be nice to see real-world use cases for these scenarios
elf Pavlik: a use case might be to allow an attendee to be attached to an event directly, i.e., without creating an intermediary collection resource
Error: (IRC nickname not recognized)[20:26] <markus> ... that could be expressed with a single triple </event> schema:attendee </attendee>
Karol Szczepański: fair enough.. but it is a implementation detail on the server
elf Pavlik: think of it as a named graph
elf Pavlik: https://github.com/HydraCG/Specifications/pull/154/commits/33ab45ae4bfbea89e30c8c4f8df8043720d87f4b
elf Pavlik: the commit I just referenced shows how this might work
Markus Lanthaler: isn't this more of a PATCH?
... like patching the event resource to add a new attendee?
elf Pavlik: not really, the relationships here have their own URLs as you see described with the IRI template
Tomasz Pluskiewicz: this looks very complex while at the same time being very abstract
... you are adding triple patterns, adding subjects and predicates etc.
... the average Hydra consumer doesn't want to deal with this
elf Pavlik: how would it work otherwise?
... it could think of a RPC-style POST
... I'm open to alternatives
Karol Szczepański: quick idea.. the event could provide a collection for attendees
elf Pavlik: right, but then you would POST a resource with a known IRI which would then create a new resource which just points to the person attending the event
... I would like to have something which doesn't need this extra complexity
... maybe as extension for people who are more interested in the linked data
Markus Lanthaler: an alternative might be to use the LINK method
elf Pavlik: wasn't it deprecated in HTTP/1.1?
... we should look it up
Karol Szczepański: also, there's currently no way to describe the necessary HTTP headers with Hydra
Markus Lanthaler: is there anything else we want to discuss in regard to PR-154 (Actions with explicit target)
Karol Szczepański: what are the next steps
Markus Lanthaler: if no one has a more concrete idea I think we need to iterate on it further
... GitHub is probably the better place to do so
Topic: Implementation of two new API documentation use cases 2.1 and 2.2 (PR-30)
Karol Szczepański: I think the only remaining question is whether to expose the getHypermediaProcessor() method
... I think it will be useful
Markus Lanthaler: I don't think that's a blocker
... let's proceed with the PR
Karol Szczepański: I addressed all other feedback
Markus Lanthaler: cool. I'll merge it right after the call
Topic: Obtaining all collection members fixing issue 33 (PR-34)
Markus Lanthaler: it looks like no one had a chance to review it yet
Karol Szczepański: this PR updates the implementation with the correct PartialCollectionView
... so this makes the client spec conformant
... in terms of features there's a new method to get all members
Tomasz Pluskiewicz: quick question, why's there no Reviewable button?
Markus Lanthaler: might be because I haven't set it up
... I'll check
Tomasz Pluskiewicz: I think this shouldn't eagerly load the whole collection
... but do so lazily
... would be nice for things like infinite scrolling etc.
Karol Szczepański: how would the API look like?
Tomasz Pluskiewicz: it would also be nice to make it extensible
... there are different strategies on how to traverse pages
Karol Szczepański: ok, I made a note
... and will think about it
... but please let me know if you have any ideas
Tomasz Pluskiewicz: please add my comment to the PR so that we don't forget about it
... and please add a snippet on how the current feature works
Markus Lanthaler: I guess there's a test that could act as snippet
Tomasz Pluskiewicz: that's perhaps a bit too hidden. I would appreciate something in the PR description
Karol Szczepański: ok
Markus Lanthaler: anything else in regard to this PR or in general?
Karol Szczepański: I just went through the HTTP specs
... in the first version LINK was described
... later it just says they weren't frequently used
... but doesn't say they were deprecated
Markus Lanthaler: the HTTP methods were moved to a IANA registry
Markus Lanthaler: LINK is there, referencing the first HTTP spec: https://tools.ietf.org/html/rfc2068
... but as you mentioned, those methods aren't widely used
... so there might be compatibility issues in practice