Hydra W3C Community Group Telecon
Minutes for 2017-10-30
- Agenda
- https://www.w3.org/community/hydra/wiki/Conference_Calls#2017-10-30
- Topics
- Action Items
- Chair
- Markus Lanthaler
- Scribe
- elf Pavlik
- Present
- Markus Lanthaler, Tomasz Pluskiewicz, elf Pavlik, Karol Szczepański
- Audio Log
Markus Lanthaler: Meeting: Hydra W3C Community Group Conference Call
Markus Lanthaler: present+
elf Pavlik: present+
elf Pavlik is scribing.
elf Pavlik is scribing.
Topic: Add use case creating events with PUT (PR-143)
Markus Lanthaler: https://github.com/HydraCG/Specifications/pull/143
Markus Lanthaler: it already received reviews from Karol, Pavlik and me
... Tomasz can you explain the current state of this PR?
Tomasz Pluskiewicz: recent comment from Pavlik regarding advertising a regular IRI which will handle adding new members
Markus Lanthaler: you would need to communicate to client that it has to re-fetch the collection to get IRI for adding another resource
Markus Lanthaler: i would include a nonce in the request, a token that can get used once instead of messing with the IRI - currently we have no way to do that in hydra
... other option would POST to the resource to get IRI which later one can PUT to
Tomasz Pluskiewicz: in previous comment you have 1-to-1 relation with another resource, eg. private profile of a user
... it doesn't have the added complexity that you can't reuse the same IRI
Markus Lanthaler: do you think something blocks this PR?
Tomasz Pluskiewicz: i see 2 more comments which need addressing
... 1 to use `If-Match` to tell difference between create and replace
Markus Lanthaler: so you want to avoid that if resource already exists, that server will overwrite it when client attempts to create new resoruce using the same IRI
elf Pavlik: AFAIK conditional PUT works based on Etag
Markus Lanthaler: i think you would need to do PUT with `If_match: *`
Markus Lanthaler: PUT with If-Match: *
Markus Lanthaler: Server would reply with 412 Precondition Failed if it already exists
Tomasz Pluskiewicz: we still have issue that hydra doesn't provide a way to require etags
Markus Lanthaler: would be nice to have a way to instruct client to do conditional request
Markus Lanthaler: we could make it Use Case on its own and remove it from this PR
Tomasz Pluskiewicz: initially we said that this would extend UC5 but i decided to create a new file for it
Markus Lanthaler: i don't have strong opinion about that, feel free to do as it fits you
Tomasz Pluskiewicz: we also have this other comment about HTTP spec from you markus
Markus Lanthaler: it basically says that PUT practically replays that payload
Markus Lanthaler: we should address this 'indirectly' terminology
... instead have: "creating with know URL" or something like that
... we also had an example that we had unclear relationship to the collection
Markus Lanthaler: you invented those new properties http://example.com/vocab/createEvent i suggested that we may have something like hydra:memberTemplate
Tomasz Pluskiewicz: if we can stretch it to also work with concrete IRIs
elf Pavlik: i don't think we can define semantics of a property that will hold either with template or with concrete resource
... i propose to for now go with hydra:memberTemplate and then try to solve the non-template use case
Tomasz Pluskiewicz: we also have this recursive traversal issue
Karol Szczepański: i remember that we had some discussions on mailing list about which definition takes precedence over others
... so i think more loose way of getting hypermedia was always an option
... i believe that client should always be able to be more 'greedy' with lookups of hypermedias
Markus Lanthaler: what did you have in mind when you called it recursive
... did you mean following properties to other resources and fetching those resources
Tomasz Pluskiewicz: yes
... recursive means follow any link and look for operations in those linked resources
... it could have cycles actually
Markus Lanthaler: i don't see cycles a problem
... i think you can end up with some unintended operation with such traversal
Tomasz Pluskiewicz: if we go with `hydra:memberTemplate` we can just follow that link and avoid recursive this way
Markus Lanthaler: if we just follow that link and do NOT recurse i see it fine
elf Pavlik: I understand we settled on following `hydra:memberTemplate` and NOT using recursive
Karol Szczepański: one more question regarding this PR, I still don't get it this very use case
... in PR i try to separate the creation from adding it
... in this UC we combine creation with adding member
Karol Szczepański: how the client will know that create will add to collection
... maybe we should add `schema:AddAction` together with `schema:CreateAction`
Tomasz Pluskiewicz: I think `hydra:memberTemplate` implies that a resource will become member
Karol Szczepański: I'd like to have only one way to define it
elf Pavlik: in one of the issues i commented that we seem to have 'create' on template but 'add' on collection
Markus Lanthaler: for now we can just use `schema:AddAction` only if we have operation directly on collection
... but not if we use template
Tomasz Pluskiewicz: i think we still miss some pieces here
... for example like the adding existing members with PUT as in vimeo case
Markus Lanthaler: i would suggest focus on this one to make progress
elf Pavlik: let's don't see it as final design decision but as a step in iterating on the issue
Topic: Heracles.ts PR-18 "Use cases/5.creating new event"
Markus Lanthaler: https://github.com/HydraCG/Heracles.ts/pull/18
Karol Szczepański: I would wait with it and merge the other PR for use case first
... since they address the same UC
Markus Lanthaler: i would consider allowing Heracles users to create some layer on top of it
Karol Szczepański: we should at the same time not expect users to do to much before the use client
Markus Lanthaler: do you see anything as blocking or what you see need for more input from the group
Karol Szczepański: i see discussions ton tpluskiewicz's PR helpful and sufficient
Markus Lanthaler: let's iterate on github and reviewable and we don't have to wait for next telecon
Tomasz Pluskiewicz: we have some inconsistent way of using prefixes in our snippets
Markus Lanthaler: i would prefer not to use prefix for `hydra:` and only for everything else
elf Pavlik: should we remove existing prefixes for some `schema:` terms ?
Markus Lanthaler: it may help people to see what hydra provides and what not
Karol Szczepański: i would prefer to have no prefixes, especially for common predicates
Markus Lanthaler: also fine with that
elf Pavlik: maybe someone can just do PR and propose changes?
Tomasz Pluskiewicz: maybe let's make issue first and make PR after agreeing on something
Markus Lanthaler: or we can start PR with just one file
... to make it more concrete
ACTION: Pavlik to create a PR to harmonize the usage of prefixes in our use case documents