Hydra W3C Community Group Telecon Minutes for 2018-04-16

The minutes from this week's telecon are now available at

   http://www.hydra-cg.com/minutes/2018-04-16/

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


-------------------------------------------------------------------
Hydra W3C Community Group Telecon Minutes for 2018-04-16

Agenda:
  https://www.w3.org/community/hydra/wiki/Conference_Calls#2018-04-16
Topics:
  1. Follow-up on ACTION items
  2. Implementation of two new API documentation use cases 2.1 
    and 2.2 (PR-30)
  3. Obtaining all collection members fixing issue 33 (PR-34)
Chair:
  Markus Lanthaler
Scribe:
  Markus Lanthaler
Present:
  Markus Lanthaler, elf Pavlik, Tomasz Pluskiewicz, Karol 
  Szczepański
Audio:
  http://www.hydra-cg.org/minutes/2018-04-16/audio.mp3


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: https://github.com/HydraCG/Specifications/issues/162
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/33ab45ae4bfbea89e
30c8c4f8df8043720d87f4b
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)

https://github.com/HydraCG/Heracles.ts/pull/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)

https://github.com/HydraCG/Heracles.ts/pull/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
https://www.iana.org/assignments/http-methods/http-methods.xhtml
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

Received on Monday, 16 April 2018 19:02:53 UTC