Hydra W3C Community Group Telecon Minutes for 2018-01-08

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

   http://www.hydra-cg.com/minutes/2018-01-08/

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


-------------------------------------------------------------------
Hydra W3C Community Group Telecon Minutes for 2018-01-08

Agenda:
  https://www.w3.org/community/hydra/wiki/Conference_Calls#2018-01-08
Topics:
  1. Use cases/7.searching events (Heracles/PR-23)
  2. Actions with explicit target (PR-154)
Chair:
  Markus Lanthaler
Scribe:
  Markus Lanthaler
Present:
  Markus Lanthaler, elf Pavlik, Karol Szczepański
Audio:
  http://www.hydra-cg.org/minutes/2018-01-08/audio.mp3


Markus Lanthaler is scribing.

Topic: Use cases/7.searching events (Heracles/PR-23)

https://github.com/HydraCG/Heracles.ts/pull/23
elf Pavlik:  I didn't have time to properly
.. review it but if you guys say it's ready I trust you
Karol Szczepański:  I'll address the comments as soon as I find 
  some time
  ... I still need to clear my mind about hydra:memberTemplate 
  etc.
  ... regarding this PR specifically I'm not blocked and will 
  address the outstanding issues shortly
Markus Lanthaler:  Anything else we should discuss related to 
  this PR?
elf Pavlik:  No, I need to review it

Topic: Actions with explicit target (PR-154)

https://github.com/HydraCG/Specifications/pull/154
elf Pavlik:  Karol, did you have time to have a look?
Karol Szczepański:  I had a glance at it but didn't think enough 
  about it yet
  ... I need to think it through to be able to properly comment 
  on it
elf Pavlik:  I took 2 use cases. The one with PUT and the search 
  one
  ... I replace the templates with two actions using 
  schema:potentialAction
  ... I'm using schema:target to make the target explicit
  ... I just realized that I could also have used the reverse of 
  hydra:operation instead of schema:target
  ... I find it nice to have all the affordances about a resource 
  in a single place
  ... which is why I proposed this design
Markus Lanthaler:  What's your take on the overlap of operations 
  and actions as commented on the PR?
elf Pavlik:  In principle I agree but in this particular case I 
  don't a see big difference between the two
Markus Lanthaler:  I didn't mean to differentiate between 
  information and non-information resources
  ... I was concerned about separation of the semantics of the 
  request (perform a search) and a description of the HTTP details 
  (make a POST, perform a GET)
elf Pavlik:  I see. So you are talking something like a handler 
  of a the action
Markus Lanthaler:  exactly
Karol Szczepański:  I fail to see why a client would need to 
  understand schema:potentialAction, isn't it like any arbitrary 
  vocabulary
Markus Lanthaler:  would the design make sense to you if 
  potentialAction was part of Hydra?
Karol Szczepański:  kinda, I still struggle to see the connection 
  between these resource and the relation to hydra:memberTemplate
  ... I don't see the purpose of this as hydra:memberTemplate 
  already solves the problem
  ... or what's the benefit?
  ... the JavaScript code actually looks exactly the same
elf Pavlik:  the advantage of this approach would be that we 
  wouldn't need to introduce lots of other properties such as 
  hydra:memberTemplate for other use cases like search etc.
  ... we could handle all of this in a uniform manner by 
  leveraging actions/operations
  ... this connects the action directly to the resource it 
  affects, instead of attaching indirectly through a template as 
  with hydra:memberTemplate
Markus Lanthaler:  I see the benefit of Pavlik's design as it 
  directly ties the action to the resource
  ... with the hydra:memberTemplate design a user would need to 
  introduce both the property and an action type
  ... if we wouldn't have it directly in Hydra, a client wouldn't 
  couldn't figure out how to add an item to the collection as it 
  wouldn't know it's relationship to the collection
Karol Szczepański:  how would a client understand with 
  potentialAction that it adds an item if the template would 
  differ?
elf Pavlik:  by the action, such as AddAction.. the IRI and thus 
  the template should be opaque
  ... if I remember correctly we actually saw an example in the 
  Vimeo API where the target (i.e., the template) differs from the 
  resource itself
Karol Szczepański:  it sounds interesting but would be quite a 
  change
Markus Lanthaler:  yep
Karol Szczepański:  are we concerned about breaking existing 
  implementations
  ... like Ruben's Linked Data Fragments
Markus Lanthaler:  I wouldn't worry too much about that
  ... but we should look for ways to make it the least disruptive 
  possible
  ... one way I could think of is keeping operation and adding 
  something like hydra:performsAction to the operation that 
  describes the semantics of the operation
  ... and then add another property which could be used to point 
  from a resource to a action if it isn't possible to point to the 
  operation directly as the target differs
  ... http://schema.org/Action
elf Pavlik:  What is missing from schema.org is a way to describe 
  that an action introduces a relationship such as in a LikeAction
  ... which direction do we want to point? From Action to 
  Operation or vice-versa?
Markus Lanthaler:  I think we'll need to point both ways
  ... anything else we should discuss in regard to this PR?
Karol Szczepański:  should introduce a new use instead of 
  changing use case 5.1?
  ... same use case but different approach
Markus Lanthaler:  I see. Would you like to keep both approaches 
  eventually or just one?
Karol Szczepański:  I don't know yet.. I see many uses for 
  Pavlik's approach
  ... but the current approach is compelling as well in a few 
  cases as it is so simple
  ... so I see benefits in both of them
Markus Lanthaler:  I don't have a strong opinion. I think we 
  should just try it out
elf Pavlik:  I completely agree. We need to explore this more
  ... I'm happy to change it to introduce alternatives instead of 
  overwriting it
Karol Szczepański:  I think we would benefit from trying to 
  describe more complex things with both approaches
  ... like having multiple search actions on a collection
  ... I see link/unlink as very good examples for this as they 
  are tricky to express
Markus Lanthaler:  I think the most efficient way forward is to 
  discuss this directly on the PR
  ... I'll leave a snippet of what I had in mind there
  ... Karol, if you have some time, please have another look at 
  the PR and leave some comments too
Karol Szczepański:  will do in the next couple of days

Received on Monday, 8 January 2018 20:09:39 UTC