- From: Markus Lanthaler <markus.lanthaler@gmx.net>
- Date: Mon, 8 Jan 2018 21:09:09 +0100
- To: <public-hydra@w3.org>
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