Hydra W3C Community Group Telecon
Minutes for 2018-01-08
- Agenda
- https://www.w3.org/community/hydra/wiki/Conference_Calls#2018-01-08
- Topics
- Chair
- Markus Lanthaler
- Scribe
- Markus Lanthaler
- Present
- Markus Lanthaler, elf Pavlik, Karol Szczepański
- Audio Log
Markus Lanthaler is scribing.
Topic: Use cases/7.searching events (Heracles/PR-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)
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
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